OLAP-CUBE (dynamische managementrapportage). Inleiding tot OLAP en multidimensionale databases

Gegevens zijn doorgaans schaars en worden voor lange termijn opgeslagen. Het kan worden geïmplementeerd op basis van universeel relationeel DBMS of gespecialiseerde software (zie ook OLAP). SAP-softwareproducten gebruiken de term “infocube”.

Array-indices komen overeen met afmetingen (afmetingen) of assen van de kubus, en waarden van array-elementen komen overeen met afmetingen (metingen) van de kubus.

Waar X, j, z- metingen, w- meeteenheid.

In tegenstelling tot een gewone array in een programmeertaal kan toegang tot de elementen van een OLAP-kubus worden uitgevoerd via de volledige set indexdimensies of via hun subset, en dan zal het resultaat niet één element zijn, maar veel ervan.

Ook bekende omschrijving OLAP-kubus het gebruik van relationele algebra-terminologie als een projectie van relaties.

Zie ook

Wikimedia Stichting.

• 2010.
• Sterdiagram

Ons huis is Rusland (factie)

Kijk wat een "OLAP-kubus" is in andere woordenboeken: OLAP-kubus

- ... Wikipedia OLAP

- (eng. online analytische verwerking, analytische verwerking in realtime) gegevensverwerkingstechnologie, die bestaat uit de voorbereiding van samenvattende (geaggregeerde) informatie op basis van grote hoeveelheden gegevens, gestructureerd door ... ... Wikipedia Kubus (het ondubbelzinnig maken)

- Kubus is een polysemantische term: In de wiskunde In stereometrie is een kubus een zeshoekig regelmatig veelvlak In de algebra de derde macht van een getal Filmserie met sciencefictionfilms: “Cube” “Cube 2: Hypercube” “Cube Zero” Slang en medisch jargon... ... Wikipedia Kubus

- Deze term heeft andere betekenissen, zie Kubus (betekenissen). Kubustype Regelmatig veelvlak Gezicht vierkant ... Wikipedia Mondriaan

- OLAP-servertype OLAP-server Ontwikkelaar Pentaho Besturingssysteem platformonafhankelijke software Nieuwste versie 3.4.1 (2012 05 07) Licentievrije software ... Wikipedia - Informatieanalytisch systeem een ​​geautomatiseerd systeem waarmee experts snel grote hoeveelheden gegevens kunnen analyseren, meestal een van de elementen van situationele centra. Soms bevat de IAS ook een verzamelsysteem... ...Wikipedia Annotatie:

Deze lezing behandelt de basisprincipes van het ontwerpen van datakubussen voor OLAP-datawarehouses. Het voorbeeld toont de methode voor het construeren van een datakubus met behulp van de CASE-tool.

Doel van de lezing

• Na het bestuderen van de stof uit deze lezing weet je: waar zit een datakubus in? ;
• hoe u een datakubus ontwerpt OLAP-datawarehouses ;
• wat is een datakubusdimensie;
• hoe een feit gerelateerd is aan een datakubus;
• wat zijn dimensieattributen;
• wat is hiërarchie;
• wat is een datakubusmetriek;

en leer:

• bouwen multidimensionale grafieken ;
• ontwerp eenvoudig multidimensionale grafieken.

Invoering

OLAP-technologie is niet één softwareproduct, Niet programmeertaal. Als we OLAP in al zijn verschijningsvormen proberen te beschrijven, dan is het een reeks concepten, principes en vereisten die ten grondslag liggen aan softwareproducten die het voor analisten gemakkelijker maken om toegang te krijgen tot gegevens.

Analisten zijn de belangrijkste consumenten van bedrijfsinformatie. Het is de taak van de analist om patronen te vinden in grote hoeveelheden gegevens. Daarom zal de analist geen aandacht besteden aan het individuele feit dat op een bepaalde dag een partij balpennen werd verkocht aan koper Ivanov - hij heeft informatie nodig over honderden en duizenden soortgelijke gebeurtenissen. Afzonderlijke feiten in het datawarehouse kunnen bijvoorbeeld van belang zijn voor een accountant of het hoofd van de verkoopafdeling, wiens competentie het ondersteunen van een bepaald contract is. Voor een analist is één record niet genoeg; hij heeft bijvoorbeeld informatie nodig over alle contracten van een verkooppunt voor een maand, kwartaal of jaar. De analist is misschien niet geïnteresseerd in het TIN van de koper of zijn telefoonnummer - hij werkt met specifieke numerieke gegevens, wat de essentie is van zijn professionele activiteit.

Centralisatie en handige structurering zijn niet alles wat een analist nodig heeft. Hij heeft een hulpmiddel nodig om informatie te bekijken en te visualiseren. Traditionele rapporten, zelfs die gebouwd op basis van één datawarehouse, missen echter een zekere flexibiliteit. Ze kunnen niet worden ‘verdraaid’, ‘uitgebreid’ of ‘samengevouwen’ om het gewenste beeld van de gegevens te krijgen. Hoe meer ‘segmenten’ en ‘secties’ data een analist kan verkennen, hoe meer ideeën hij heeft, die op hun beurt steeds meer ‘segmenten’ vereisen voor verificatie. OLAP dient als zo’n tool voor data-analyse door een analist.

Hoewel OLAP geen noodzakelijk kenmerk van een datawarehouse is, wordt het steeds vaker gebruikt om de informatie die in dit datawarehouse is verzameld te analyseren.

Operationele gegevens worden uit verschillende bronnen verzameld, opgeschoond, geïntegreerd en opgeslagen in een datawarehouse. Bovendien zijn ze al beschikbaar voor analyse met behulp van verschillende rapportagetools. Vervolgens worden de gegevens (geheel of gedeeltelijk) voorbereid voor OLAP-analyse. Ze kunnen in een speciale OLAP-database worden geladen of in een relationele database worden achtergelaten. Het belangrijkste element bij het gebruik van OLAP zijn metadata, d.w.z. informatie over de structuur, plaatsing en datatransformatie. Dankzij hen is een effectieve interactie van verschillende opslagcomponenten verzekerd.

Dus, OLAP kan worden gedefinieerd als een set tools voor multidimensionale data-analyse, verzameld in een datawarehouse. Theoretisch kunnen OLAP-tools rechtstreeks op operationele gegevens of hun exacte kopieën worden toegepast. Het risico bestaat echter dat gegevens worden onderworpen aan analyses die niet geschikt zijn voor deze analyse.

OLAP op client en server

OLAP is gebaseerd op multidimensionale data-analyse. Het kan worden geproduceerd met behulp van verschillende tools, die kunnen worden onderverdeeld in client- en server-OLAP-tools.

OLAP-clienttools zijn toepassingen die geaggregeerde gegevens (sommen, gemiddelden, maximale of minimale waarden) berekenen en weergeven, terwijl de geaggregeerde gegevens zelf in een cache binnen de adresruimte van een dergelijke OLAP-tool zijn opgeslagen.

Als de brongegevens zich in een desktop-DBMS bevinden, wordt de berekening van de geaggregeerde gegevens uitgevoerd door de OLAP-tool zelf. Als de bron van de initiële gegevens een server-DBMS is, sturen veel van de client-OLAP-tools SQL-query's met de GROUP BY-operator naar de server, en ontvangen als resultaat geaggregeerde gegevens die op de server zijn berekend.

In de regel wordt de OLAP-functionaliteit geïmplementeerd in tools voor de verwerking van statistische gegevens (van producten van deze klasse worden producten van Stat Soft en SPSS veel gebruikt op de Russische markt) en in sommige spreadsheets. Met name Microsoft Excel 2000 beschikt over goede multidimensionale analysehulpmiddelen. Met dit product kunt u een kleine lokale multidimensionale OLAP-kubus maken en als bestand opslaan en de twee- of driedimensionale secties ervan weergeven.

Veel ontwikkelingshulpmiddelen bevatten bibliotheken met klassen of componenten waarmee u toepassingen kunt maken die eenvoudige OLAP-functionaliteit implementeren (zoals bijvoorbeeld Decision Cube-componenten in Borland Delphi en Borland C++Builder). Daarnaast bieden veel bedrijven aan controles ActiveX en andere bibliotheken die vergelijkbare functionaliteit implementeren.

Houd er rekening mee dat client-OLAP-tools in de regel worden gebruikt met een klein aantal dimensies (meestal worden er niet meer dan zes aanbevolen) en een kleine verscheidenheid aan waarden voor deze parameters - de resulterende geaggregeerde gegevens moeten immers passen in de adresruimte van een dergelijk hulpmiddel, en hun aantal groeit exponentieel naarmate het aantal metingen toeneemt Daarom kunt u zelfs met de meest primitieve client-OLAP-tools in de regel een voorlopige berekening maken van de hoeveelheid vereist RAM om er een multidimensionale kubus in te creëren.

Met veel (maar niet alle) OLAP-clienthulpmiddelen kunt u de inhoud van de cache met verzamelde gegevens als een bestand opslaan, waardoor u deze opnieuw kunt berekenen. Merk op dat deze mogelijkheid vaak wordt gebruikt om geaggregeerde gegevens te vervreemden met als doel deze over te dragen aan andere organisaties of voor publicatie. Een typisch voorbeeld van dergelijke vervreemdbare geaggregeerde gegevens zijn de morbiditeitsstatistieken in verschillende regio's en in verschillende leeftijdsgroepen, wat open informatie is die wordt gepubliceerd door de ministeries van Volksgezondheid van verschillende landen en de Wereldgezondheidsorganisatie. Tegelijkertijd zijn de originele gegevens zelf, die informatie over specifieke ziektegevallen vertegenwoordigen, vertrouwelijke gegevens van medische instellingen en mogen in geen geval in handen van verzekeringsmaatschappijen vallen, laat staan ​​publieke kennis worden.

Het idee om een ​​cache van geaggregeerde gegevens in een bestand op te slaan, werd verder ontwikkeld in server-OLAP-tools, waarbij het opslaan en wijzigen van geaggregeerde gegevens, evenals het onderhouden van de opslag die deze bevat, wordt uitgevoerd door een afzonderlijke applicatie of proces, een zogenaamde OLAP-server. Clientapplicaties kunnen dergelijke multidimensionale opslag aanvragen en als reactie daarop bepaalde gegevens ontvangen. Sommige clienttoepassingen kunnen ook dergelijke winkels creëren of deze bijwerken op basis van gewijzigde brongegevens.

De voordelen van het gebruik van server-OLAP-tools in vergelijking met client-OLAP-tools zijn vergelijkbaar met de voordelen van het gebruik van server-DBMS's in vergelijking met desktop-tools: in het geval van het gebruik van servertools vindt de berekening en opslag van geaggregeerde gegevens plaats op de server en de clienttoepassing. ontvangt alleen de resultaten van zoekopdrachten tegen hen, waardoor het netwerkverkeer in het algemeen kan worden verminderd, doorlooptijd aanvragen en resourcevereisten die door de clienttoepassing worden verbruikt. Houd er rekening mee dat tools voor gegevensanalyse en -verwerking op bedrijfsschaal in de regel gebaseerd zijn op server-OLAP-tools, bijvoorbeeld Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, producten van Crystal Decisions, Business Objects, Cognos, SAS Instituut.

Omdat alle toonaangevende fabrikanten van server-DBMS's een of andere OLAP-servertools produceren (of in licentie hebben gegeven bij andere bedrijven), is de keuze vrij breed en in bijna alle gevallen kunt u een OLAP-server kopen van dezelfde fabrikant als de databaseserver zelf. .

Houd er rekening mee dat veel client-OLAP-hulpprogramma's (met name Microsoft Excel 2003, Seagate Analysis, etc.) u toegang geven tot OLAP-serveropslagruimten, die in dit geval fungeren als clienttoepassingen die dergelijke zoekopdrachten uitvoeren. Daarnaast zijn er veel producten die clientapplicaties zijn voor OLAP-tools van verschillende fabrikanten.

Technische aspecten van multidimensionale dataopslag doorlooptijd Multidimensionale datawarehouses bevatten geaggregeerde gegevens met verschillende mate van detail, bijvoorbeeld verkoopvolumes per dag, maand, jaar, per productcategorie, enz. Het doel van het opslaan van geaggregeerde gegevens is het verminderen

verzoeken, omdat het voor analyses en prognoses in de meeste gevallen niet gaat om gedetailleerde, maar om samenvattende gegevens die van belang zijn. Daarom worden bij het maken van een multidimensionale database altijd bepaalde geaggregeerde gegevens berekend en opgeslagen.

Houd er rekening mee dat het opslaan van alle geaggregeerde gegevens niet altijd gerechtvaardigd is. Het is een feit dat wanneer er nieuwe dimensies worden toegevoegd, het gegevensvolume waaruit de kubus bestaat exponentieel groeit (soms spreken ze van “explosieve groei” van het gegevensvolume). Preciezer gezegd, de mate van groei in het volume van de geaggregeerde gegevens hangt af van het aantal dimensies van de kubus en de leden van de dimensies op verschillende niveaus van de hiërarchieën van deze dimensies. Om het probleem van de “explosieve groei” op te lossen, worden verschillende schema’s gebruikt die het mogelijk maken om een ​​acceptabele snelheid van de uitvoering van zoekopdrachten te bereiken bij het berekenen van niet alle mogelijke geaggregeerde gegevens.

• Zowel ruwe als geaggregeerde gegevens kunnen worden opgeslagen in relationele of multidimensionale structuren. Daarom worden momenteel drie methoden voor gegevensopslag gebruikt.(Multidimensional OLAP) - bron- en geaggregeerde gegevens worden opgeslagen in een multidimensionale database. Door gegevens in multidimensionale structuren op te slaan, kunt u de gegevens manipuleren als een multidimensionale array, waardoor de snelheid van het berekenen van de geaggregeerde waarden voor elk van de dimensies hetzelfde is. In dit geval is de multidimensionale database echter redundant, aangezien de multidimensionale gegevens volledig de oorspronkelijke relationele gegevens bevatten.
• ROLAP(Relationele OLAP) - de originele gegevens blijven in dezelfde relationele database waar deze zich oorspronkelijk bevonden. Geaggregeerde gegevens worden in servicetabellen geplaatst die speciaal zijn gemaakt om deze in dezelfde database op te slaan.
• HOLAP(Hybride OLAP) - de originele gegevens blijven in dezelfde relationele database waar deze zich oorspronkelijk bevonden, en de verzamelde gegevens worden opgeslagen in een multidimensionale database.

Sommige OLAP-tools ondersteunen het opslaan van gegevens alleen in relationele structuren, andere alleen in multidimensionale structuren. De meeste moderne OLAP-servertools ondersteunen echter alle drie de methoden voor gegevensopslag. De keuze van de opslagmethode hangt af van het volume en de structuur van de brongegevens, vereisten voor de snelheid van de uitvoering van query's en de frequentie van het bijwerken van OLAP-kubussen.

Merk ook op dat de overgrote meerderheid van de moderne OLAP-tools geen “lege” waarden opslaan (een voorbeeld van een “lege” waarde zou de afwezigheid van verkoop van een seizoensproduct buiten het seizoen zijn).

Basis OLAP-concepten

FAMSI-test

De technologie voor complexe multidimensionale data-analyse heet OLAP (On-Line Analytical Processing). OLAP is een belangrijk onderdeel van een datawarehouse-organisatie. Het concept van OLAP werd in 1993 beschreven door Edgar Codd, een beroemde databaseonderzoeker en auteur van het relationele datamodel. In 1995 werden op basis van de door Codd gestelde eisen de zogenaamde FASMI-test(Snelle analyse van gedeelde multidimensionale informatie) - snelle analyse van gedeelde multidimensionale informatie, inclusief de volgende vereisten voor toepassingen voor multidimensionale analyse:

• Snel(Snel) - de gebruiker voorzien van analyseresultaten binnen een acceptabele tijd (meestal niet meer dan 5 s), zelfs ten koste van een minder gedetailleerde analyse;
• Analyse(Analyse) - de mogelijkheid om elke logische en statistische analyse uit te voeren die specifiek is voor een bepaalde applicatie en deze op te slaan in een vorm die toegankelijk is voor de eindgebruiker;
• Gedeeld(Gedeeld) - toegang voor meerdere gebruikers tot gegevens met ondersteuning voor geschikte vergrendelingsmechanismen en geautoriseerde toegangsmiddelen;
• Multidimensionaal(Multidimensionaal) - multidimensionale conceptuele representatie van gegevens, inclusief volledige ondersteuning voor hiërarchieën en meerdere hiërarchieën (dit is een belangrijke vereiste van OLAP);
• Informatie(Informatie) - de applicatie moet toegang hebben tot alle noodzakelijke informatie, ongeacht het volume en de opslaglocatie.

Opgemerkt moet worden dat de OLAP-functionaliteit op verschillende manieren kan worden geïmplementeerd, van de eenvoudigste tools voor gegevensanalyse in kantoortoepassingen tot gedistribueerde analysesystemen op basis van serverproducten.

Multidimensionale representatie van informatie

kubussen

OLAP biedt handige, snelle middelen voor het openen, bekijken en analyseren van bedrijfsinformatie. De gebruiker krijgt een natuurlijke, intuïtieve datamodel, organiseren in de vorm van multidimensionale kubussen (Cubes). De assen van het multidimensionale coördinatensysteem zijn de belangrijkste kenmerken van het geanalyseerde bedrijfsproces. Voor verkoop kan dit bijvoorbeeld het product, de regio of het type koper zijn. Tijd wordt gebruikt als een van de dimensies. Op de snijpunten van de meetassen (Dimensies) bevinden zich gegevens die het proces kwantitatief karakteriseren - metingen (Maatregelen). Dit kunnen verkoopvolumes zijn in stukjes of in geld, voorraadsaldi, kosten, enz. Een gebruiker die de informatie analyseert, kan de kubus in verschillende richtingen ‘knippen’, een samenvatting verkrijgen (bijvoorbeeld per jaar) of, omgekeerd, gedetailleerd (per jaar). week) informatie en voer andere manipulaties uit die in hem opkomen tijdens het analyseproces.

Zoals metingen in de driedimensionale kubus getoond in Fig.

26.1 worden verkoopbedragen gebruikt en worden tijd, product en winkel als dimensies gebruikt. Metingen worden gepresenteerd op specifieke groeperingsniveaus: producten worden gegroepeerd op categorie, winkels op land en transactietiminggegevens op maand. Even later zullen we de niveaus van groepering (hiërarchie) in meer detail bekijken.

Rijst. 26.1.

Een kubus "snijden".

Een tweedimensionale weergave van een kubus kan worden verkregen door deze kruislings langs een of meer assen (afmetingen) te “snijden”: we leggen de waarden van alle dimensies vast, behalve twee, en we krijgen een gewone tweedimensionale tabel. De horizontale as van de tabel (kolomkoppen) vertegenwoordigt één dimensie, de verticale as (rijkoppen) vertegenwoordigt een andere, en de tabelcellen vertegenwoordigen de waarden van de metingen. In dit geval wordt een reeks metingen feitelijk beschouwd als een van de dimensies: we selecteren óf één maatstaf om weer te geven (en dan kunnen we twee dimensies in de rij- en kolomkoppen plaatsen), óf we geven meerdere metingen weer (en vervolgens een van de tabelassen worden ingenomen door de namen van metingen, en de andere door waarden van de enige "ongesneden" dimensie).

Architectuur van OLAP-applicaties

Alles wat hierboven over OLAP is gezegd, had in wezen betrekking op de multidimensionale presentatie van gegevens. Hoe de data worden opgeslagen, gaat in grote lijnen noch de eindgebruiker, noch de ontwikkelaars van de tool die de klant gebruikt aan.

Multidimensionaliteit in OLAP-toepassingen kan worden onderverdeeld in drie niveaus.

• Multidimensionale gegevensrepresentatie - tools voor eindgebruikers die multidimensionale visualisatie en manipulatie van gegevens bieden; De multidimensionale representatielaag abstraheert van de fysieke structuur van de gegevens en behandelt de gegevens als multidimensionaal.
• Multidimensionale verwerking is een middel (taal) voor het formuleren van multidimensionale queries (de traditionele relationele taal SQL is hier niet geschikt) en een processor die een dergelijke query kan verwerken en uitvoeren.
• Multidimensionale opslag is een manier om gegevens fysiek te organiseren en zorgt voor een efficiënte uitvoering van multidimensionale zoekopdrachten.

De eerste twee niveaus zijn verplicht in alle OLAP-tools. Het derde niveau, hoewel wijdverspreid, is niet nodig, omdat gegevens voor een multidimensionale representatie uit gewone relationele structuren kunnen worden gehaald; De multidimensionale queryprocessor vertaalt in dit geval multidimensionale query's in SQL-query's die worden uitgevoerd door het relationele DBMS.

Specifieke OLAP-producten zijn in de regel ofwel een multidimensionaal hulpmiddel voor gegevenspresentatie (OLAP-client - bijvoorbeeld draaitabellen in Excel 2000 van Microsoft of ProClarity van Knosys) of een multidimensionale server DBMS (OLAP-server - bijvoorbeeld Oracle Express Server of Microsoft OLAP-services).

De multidimensionale verwerkingslaag is meestal ingebouwd in de OLAP-client en/of OLAP-server, maar kan in zijn pure vorm worden geïsoleerd, zoals de Pivot Table Service-component van Microsoft.

Het is zelfs erg handig om een ​​multidimensionale CUBE te gebruiken bij het werken met managementrapportages. Bij het ontwikkelen van budgetformaten kunt u het probleem van multivariate formulieren tegenkomen (u kunt hierover meer lezen in Boek 8, ‘Technologie voor het opzetten van budgettering in een bedrijf’, en in het boek ‘Managementboekhouding opzetten en automatiseren’).

Dit is te wijten aan het feit dat effectief bestuur van een onderneming steeds gedetailleerdere managementrapportages vereist. Dat wil zeggen dat het systeem steeds meer verschillende analytische secties gebruikt (in informatiesystemen worden analyses bepaald door een reeks naslagwerken).

Dit leidt er uiteraard toe dat managers rapportages willen ontvangen in alle analytische secties die hen interesseren. Dit betekent dat de rapporten op de een of andere manier moeten ‘ademen’. Met andere woorden, we kunnen zeggen dat we het in dit geval hebben over het feit dat hetzelfde rapport informatie moet verschaffen over verschillende analytische aspecten. Daarom passen statische rapporten niet langer bij veel moderne managers. Ze hebben de dynamiek nodig die een multidimensionale CUBE kan bieden.

OLAP-technologie is dus al een verplicht element geworden in moderne en toekomstige informatiesystemen. Daarom moet u er bij het kiezen van een softwareproduct op letten of het OLAP-technologie gebruikt.

Bovendien moet je echte CUBES van imitatie kunnen onderscheiden. Een voorbeeld van zo'n simulatie zijn draaitabellen in MS Excel. Ja, deze tool lijkt op een CUBE, maar is dat in feite niet, aangezien dit statische en geen dynamische tabellen zijn. Bovendien hebben ze een veel slechtere implementatie van de mogelijkheid om rapporten samen te stellen met behulp van elementen uit hiërarchische mappen.

Om de relevantie van het gebruik van CUBE bij het opstellen van managementrapportages te bevestigen, kunnen we een eenvoudig voorbeeld geven met een verkoopbudget. In het beschouwde voorbeeld zijn de volgende analytische secties relevant voor het bedrijf: producten, branches en verkoopkanalen. Als deze drie analyses belangrijk zijn voor het bedrijf, kan het verkoopbudget (of rapport) in verschillende versies worden weergegeven.

Opgemerkt moet worden dat als u budgetlijnen maakt op basis van drie analytische secties (zoals in het beschouwde voorbeeld), u hiermee vrij complexe budgetmodellen kunt maken en gedetailleerde rapporten kunt maken met behulp van CUBE.

Een verkoopbudget kan bijvoorbeeld worden samengesteld met behulp van slechts één analyse (directory). Een voorbeeld van een verkoopbudget gebouwd op basis van één analyse "Producten" wordt gepresenteerd op Figuur 1.

Rijst. 1. Een voorbeeld van een verkoopbudget gebouwd op basis van één analyse “Producten” in OLAP-CUBE

Hetzelfde verkoopbudget kan worden samengesteld met behulp van twee analyses (directories). Een voorbeeld van een verkoopbudget dat is opgebouwd op basis van de twee analyses ‘Producten’ en ‘filialen’ wordt gepresenteerd op Figuur 2.

Rijst. 2. Een voorbeeld van een verkoopbudget gebouwd op basis van twee analyses “Producten” en “Branches” in de OLAP-CUBE van het INTEGRAL softwarepakket

.

Als het nodig is om meer gedetailleerde rapporten op te stellen, kan hetzelfde verkoopbudget worden samengesteld met behulp van drie analyses (directories). Een voorbeeld van een verkoopbudget dat is opgebouwd op basis van de drie analyses ‘Producten’, ‘Branches’ en ‘Verkoopkanalen’ wordt gepresenteerd op Figuur 3.

Rijst. 3. Een voorbeeld van een verkoopbudget gebouwd op basis van drie analyses “Producten”, “Branches” en “Verkoopkanalen” in de OLAP-CUBE van het INTEGRAL softwarepakket

Houd er rekening mee dat u met de CUBE die wordt gebruikt om rapporten te genereren, gegevens in verschillende volgorden kunt weergeven. Op Figuur 3 Het verkoopbudget wordt eerst “uitgebreid” per product, vervolgens per branche en vervolgens per verkoopkanaal.

Dezelfde gegevens kunnen in een andere volgorde worden gepresenteerd. Op Figuur 4 hetzelfde verkoopbudget wordt eerst “uitgebreid” per product, vervolgens per verkoopkanaal en vervolgens per branche.

Rijst. 4. Een voorbeeld van een verkoopbudget gebouwd op basis van drie analyses “Producten”, “Distributiekanalen” en “Branches” in de OLAP-CUBE van het INTEGRAL softwarepakket

Op Figuur 5 hetzelfde verkoopbudget wordt eerst ‘ontvouwd’ door filialen, vervolgens door producten en vervolgens door verkoopkanalen.

Rijst. 5. Een voorbeeld van een verkoopbudget gebouwd op basis van drie analyses “Branches”, “Producten” en “Verkoopkanalen” in het OLAP-CUBE-softwarepakket “INTEGRAL”

In feite zijn dit niet alle mogelijke opties om het verkoopbudget in te trekken.

Bovendien moet u erop letten dat KUB u in staat stelt om met de hiërarchische structuur van mappen te werken. In de gepresenteerde voorbeelden zijn de hiërarchische mappen “Producten” en “Distributiekanalen”.

Vanuit het oogpunt van de gebruiker ontvangt hij in dit voorbeeld verschillende managementrapporten (zie. Rijst. 1-5), en vanuit het oogpunt van instellingen in het softwareproduct is dit één rapport. Door simpelweg de CUBE te gebruiken, kunt u deze op verschillende manieren bekijken.

Uiteraard zijn er in de praktijk zeer veel mogelijkheden voor het uitbrengen van diverse managementrapportages als de artikelen gebaseerd zijn op één of meer analisten. En de reeks analyses zelf hangt af van de behoefte aan details van de gebruikers. Het is waar dat we aan de ene kant niet mogen vergeten dat hoe groter de analist is, hoe gedetailleerder de rapporten kunnen worden opgesteld. Maar aan de andere kant betekent dit dat het financiële budgetteringsmodel complexer zal zijn. Als er een KUB is, zal het bedrijf in ieder geval de mogelijkheid hebben om de nodige rapportering in verschillende versies in te zien, in overeenstemming met de analytische secties die van belang zijn.

Het is noodzakelijk om nog een aantal kenmerken van de OLAP-CUBE te noemen.

In een multidimensionale hiërarchische OLAP-CUBE zijn er verschillende dimensies: rijtype, datum, rijen, map 1, map 2 en map 3 (zie. Rijst. 6). Uiteraard toont het rapport net zoveel knoppen met mappen als er zijn op de budgetregel met het maximale aantal mappen. Als er op geen enkele budgetlijn één naslagwerk aanwezig is, zal het rapport geen enkele knop met naslagwerken bevatten.

In eerste instantie wordt de OLAP-CUBE langs alle dimensies gebouwd. Wanneer het rapport voor het eerst wordt samengesteld, bevinden de dimensies zich standaard in precies de gebieden die worden weergegeven Figuur 6. Dat wil zeggen dat een dimensie zoals "Datum" zich bevindt in het gebied van verticale dimensies (dimensies in het kolomgebied), afmetingen "Rijen", "Directory 1", "Directory 2" en "Directory 3" - in de gebied met horizontale afmetingen (afmetingen in de gebiedsrijen) en de dimensie “Rijtype” bevindt zich in het gebied van “niet-uitgebreide” afmetingen (afmetingen in het paginagebied). Als een dimensie zich in het laatste gebied bevindt, worden de gegevens in het rapport niet "uitgevouwen" voor die dimensie.

Elk van deze dimensies kan in elk van de drie gebieden worden geplaatst. Zodra de metingen zijn overgedragen, wordt het rapport onmiddellijk opnieuw opgebouwd zodat het overeenkomt met de nieuwe meetconfiguratie. U kunt bijvoorbeeld de datum en regels verwisselen met naslagwerken. Of u kunt een van de naslagwerken naar het verticale meetgebied verplaatsen (zie. Rijst. 7). Met andere woorden, u kunt het rapport in de OLAP-CUBE “draaien” en de rapportuitvoeroptie selecteren die het handigst is voor de gebruiker.

Rijst. 7. Een voorbeeld van het opnieuw opbouwen van een rapport na het wijzigen van de meetconfiguratie van het INTEGRAL softwarepakket

De meetconfiguratie kan worden gewijzigd in het hoofd-CUBE-formulier of in de wijzigingskaarteditor (zie. Rijst. 8). In deze editor kunt u metingen ook met de muis van het ene gebied naar het andere slepen. Bovendien kunt u metingen in hetzelfde gebied uitwisselen.

Bovendien kunt u in hetzelfde formulier enkele meetparameters configureren. Voor elke dimensie kunt u de locatie van de totalen, de sorteervolgorde van de elementen en de namen van de elementen aanpassen (zie. Rijst. 8). U kunt ook opgeven welke elementnaam in het rapport moet worden weergegeven: afgekort (Name) of volledig (FullName).

Rijst. 8. Meetkaarteditor van het INTEGRAL softwarepakket

U kunt meetparameters rechtstreeks in elk ervan bewerken (zie. Rijst. 9). Om dit te doen, klikt u op het pictogram op de knop naast de naam van de meting.

Rijst. 9. Voorbeeld van het bewerken van directory 1 Producten en diensten in

Met deze editor kunt u de elementen selecteren die u in het rapport wilt weergeven. Standaard worden alle elementen in het rapport weergegeven, maar indien nodig kunnen sommige elementen of mappen worden weggelaten. Als u bijvoorbeeld slechts één productgroep in een rapport wilt weergeven, moet u alle andere productgroepen in de metingeneditor uitschakelen. Daarna bevat het rapport nog maar één productgroep (zie. Rijst. 10).

In deze editor kunt u ook elementen sorteren. Bovendien kunnen elementen op verschillende manieren worden herschikt. Na een dergelijke hergroepering wordt het rapport onmiddellijk opnieuw opgebouwd.

Rijst. 10. Voorbeeld van uitvoer in een rapport van slechts één productgroep (map) in het INTEGRAL softwarepakket

In de dimensie-editor kunt u snel uw eigen groepen maken, elementen uit mappen daarheen slepen en neerzetten, enz. Standaard wordt alleen de groep Overige automatisch aangemaakt, maar er kunnen ook andere groepen worden aangemaakt. Zo kunt u met behulp van de dimensie-editor configureren welke elementen van de naslagwerken en in welke volgorde in het rapport moeten worden weergegeven.

In feite hadden al deze veranderingen in eerste instantie bij het opzetten van de lijnen kunnen worden aangebracht.

Met behulp van beperkingen kunt u bijvoorbeeld ook opgeven welke elementen of groepen mappen in het rapport moeten worden weergegeven en welke niet.

Opmerking: het onderwerp van dit artikel wordt tijdens workshops nader besproken "Budgetbeheer van een onderneming" En "Organisatie en automatisering van management accounting" uitgevoerd door de auteur van dit artikel, Alexander Karpov.

Als de gebruiker vrijwel regelmatig alleen bepaalde elementen of directorymappen in het rapport moet weergeven, is het beter om dergelijke instellingen vooraf te maken bij het maken van rapportregels. Als verschillende combinaties van directory-elementen in rapporten belangrijk zijn voor de gebruiker, hoeven er geen beperkingen te worden gesteld bij het opzetten van de methodiek. Al dergelijke beperkingen kunnen snel worden geconfigureerd met behulp van de meeteditor.

Over het algemeen weet elke specialist wat OLAP tegenwoordig is. In ieder geval zijn de concepten ‘OLAP’ en ‘multidimensionale gegevens’ in onze geest stevig met elkaar verbonden. Niettemin zal het feit dat dit onderwerp opnieuw ter sprake wordt gebracht, naar ik hoop, door de meerderheid van de lezers worden goedgekeurd, want om ervoor te zorgen dat het idee van iets in de loop van de tijd niet verouderd raakt, moet je periodiek communiceren met slimme mensen of lees artikelen in een goede publicatie ...

Datawarehouses (plaats van OLAP in de informatiestructuur van de onderneming)

De term "OLAP" is onlosmakelijk verbonden met de term "datawarehouse" (Data Warehouse).

Hier is de definitie geformuleerd door de ‘grondlegger’ van datawarehousing, Bill Inmon: ‘Een datawarehouse is een domeinspecifieke, tijdsgebonden, onveranderlijke verzameling gegevens om de besluitvorming van het management te ondersteunen.’

De gegevens in het magazijn zijn afkomstig van operationele systemen (OLTP-systemen), die zijn ontworpen om bedrijfsprocessen te automatiseren. Bovendien kan de repository worden aangevuld vanuit externe bronnen, zoals statistische rapporten.

Waarom datawarehouses bouwen - deze bevatten tenslotte duidelijk overtollige informatie die al in databases of besturingssysteembestanden 'leeft'? Het antwoord kan kort zijn: het is onmogelijk of zeer moeilijk om gegevens uit besturingssystemen rechtstreeks te analyseren. Dit heeft verschillende redenen, waaronder de fragmentatie van gegevens, de opslag ervan in verschillende DBMS-formaten en in verschillende “hoeken” van het bedrijfsnetwerk. Maar zelfs als een onderneming al haar gegevens op een centrale databaseserver opslaat (wat uiterst zeldzaam is), zal een analist vrijwel zeker de complexe, soms verwarrende structuren ervan niet begrijpen. De auteur heeft een nogal trieste ervaring met het proberen hongerige analisten te 'voeden' met 'ruwe' gegevens uit operationele systemen - het bleek 'te veel voor hen' te zijn.

Het doel van de repository is dus om de ‘grondstoffen’ voor analyse op één plek en in een eenvoudige, begrijpelijke structuur te leveren. Ralph Kimball schrijft in het voorwoord van zijn boek "The Data Warehouse Toolkit" dat als de lezer, na het hele boek gelezen te hebben, slechts één ding begrijpt - namelijk dat de structuur van het magazijn eenvoudig moet zijn - de auteur zijn overwegingen zal overwegen taak voltooid.

Er is nog een reden die de verschijning van een aparte opslagfaciliteit rechtvaardigt: complexe analytische vragen naar operationele informatie vertragen het huidige werk van het bedrijf, blokkeren tabellen voor een lange tijd en nemen serverbronnen in beslag.

Naar mijn mening betekent een repository niet noodzakelijkerwijs een gigantische opeenstapeling van gegevens - het belangrijkste is dat het handig is voor analyse. Over het algemeen is er een aparte term voor kleine opslagfaciliteiten: Data Marts (datakiosken), maar in onze Russische praktijk hoor je deze niet vaak.

OLAP - een handig analysehulpmiddel

Centralisatie en handige structurering zijn niet alles wat een analist nodig heeft. Hij heeft nog steeds een hulpmiddel nodig om informatie te bekijken en te visualiseren. Traditionele rapporten, zelfs rapporten die op één enkele repository zijn gebouwd, missen één ding: flexibiliteit. Ze kunnen niet worden "verdraaid", "uitgevouwen" of "samengevouwen" om het gewenste beeld van de gegevens te krijgen. Je kunt natuurlijk een programmeur bellen (als hij wil komen), en hij (als hij het niet druk heeft) zal snel genoeg een nieuw rapport maken - bijvoorbeeld binnen een uur (ik ben dit aan het schrijven en ik geloof niet dat ik doe het zelf - het gebeurt niet zo snel in het leven; laten we hem drie uur geven). Het blijkt dat een analist niet meer dan twee ideeën per dag kan testen. En hij (als hij een goede analist is) kan meerdere van dergelijke ideeën per uur bedenken. En hoe meer ‘segmenten’ en ‘secties’ gegevens de analist ziet, hoe meer ideeën hij heeft, die op hun beurt steeds meer ‘segmenten’ vereisen voor verificatie. Had hij maar een hulpmiddel waarmee hij gegevens eenvoudig en gemakkelijk kon uit- en samenvouwen! OLAP fungeert als een dergelijk hulpmiddel.

Hoewel OLAP geen noodzakelijk kenmerk van een datawarehouse is, wordt het steeds vaker gebruikt om de in het magazijn verzamelde informatie te analyseren.

De componenten in een typische repository worden getoond in Fig. 1.

Rijst. 1. Datawarehouse-structuur

Operationele gegevens worden uit verschillende bronnen verzameld, opgeschoond, geïntegreerd en opgeslagen in een relationele winkel. Bovendien zijn ze al beschikbaar voor analyse met behulp van verschillende rapportagetools. Vervolgens worden de gegevens (geheel of gedeeltelijk) voorbereid voor OLAP-analyse. Ze kunnen in een speciale OLAP-database worden geladen of in relationele opslag worden opgeslagen. Het belangrijkste element is metadata, d.w.z. informatie over de structuur, plaatsing en transformatie van gegevens. Dankzij hen is een effectieve interactie van verschillende opslagcomponenten verzekerd.

Samenvattend kunnen we OLAP definiëren als een set hulpmiddelen voor multidimensionale analyse van gegevens die in een magazijn zijn verzameld. Theoretisch kunnen OLAP-tools rechtstreeks worden toegepast op operationele gegevens of hun exacte kopieën (zodat operationele gebruikers er niet door worden gehinderd). Maar we lopen daardoor het risico op de hierboven beschreven hark te stappen, dat wil zeggen dat we operationele gegevens gaan analyseren die niet direct geschikt zijn voor analyse.

Definitie en basisconcepten van OLAP

Laten we eerst ontcijferen: OLAP is Online Analytical Processing, dat wil zeggen operationele gegevensanalyse. De twaalf bepalende principes van OLAP werden in 1993 geformuleerd door E.F. Codd, de ‘uitvinder’ van relationele databases. Later werd de definitie ervan herwerkt tot de zogenaamde FASMI-test, die vereist dat de OLAP-applicatie de mogelijkheid biedt om snel gedeelde multidimensionale informatie te analyseren ().

FASMI-test

Snel(Snel) - analyse moet even snel worden uitgevoerd op alle aspecten van de informatie. De aanvaardbare responstijd is 5 seconden of minder.

Analyse(Analyse) - het moet mogelijk zijn om basistypen numerieke en statistische analyses uit te voeren, vooraf gedefinieerd door de applicatie-ontwikkelaar of vrij gedefinieerd door de gebruiker.

Gedeeld(Gedeeld) - veel gebruikers moeten toegang hebben tot gegevens, terwijl het noodzakelijk is om de toegang tot vertrouwelijke informatie te controleren.

Multidimensionaal(Multidimensionaal) is het belangrijkste, meest essentiële kenmerk van OLAP.

Informatie(Informatie) - de applicatie moet toegang hebben tot alle noodzakelijke informatie, ongeacht het volume en de opslaglocatie.

OLAP = Multidimensionale weergave = Kubus

OLAP biedt handige, snelle middelen voor het openen, bekijken en analyseren van bedrijfsinformatie. De gebruiker krijgt een natuurlijk, intuïtief datamodel, dat deze organiseert in de vorm van multidimensionale kubussen (Cubes). De assen van het multidimensionale coördinatensysteem zijn de belangrijkste kenmerken van het geanalyseerde bedrijfsproces. Voor verkoop kan dit bijvoorbeeld het product, de regio of het type koper zijn. Tijd wordt gebruikt als een van de dimensies. Op de snijpunten van de assen - dimensies (Dimensies) - zijn er gegevens die het proces kwantitatief karakteriseren - metingen (Maatregelen). Dit kunnen verkoopvolumes zijn in stukjes of in geld, voorraadsaldi, kosten, enz. Een gebruiker die de informatie analyseert, kan de kubus in verschillende richtingen ‘knippen’, een samenvatting verkrijgen (bijvoorbeeld per jaar) of, omgekeerd, gedetailleerd (per jaar). week) informatie en voer andere manipulaties uit die in hem opkomen tijdens het analyseproces.

Zoals metingen in de driedimensionale kubus getoond in Fig. 2, er worden verkoopbedragen gebruikt, en tijd, product en winkel worden als dimensies gebruikt. Metingen worden gepresenteerd op specifieke groeperingsniveaus: producten worden gegroepeerd op categorie, winkels op land en transactietiminggegevens op maand. Even later zullen we de niveaus van groepering (hiërarchie) in meer detail bekijken.

Rijst. 2. Kubusvoorbeeld

Een kubus "snijden".

Zelfs een driedimensionale kubus is moeilijk weer te geven op een computerscherm, zodat de waarden van de betreffende maatregelen zichtbaar zijn. Wat kunnen we zeggen over kubussen met meer dan drie dimensies? Om gegevens die in een kubus zijn opgeslagen te visualiseren, worden in de regel bekende tweedimensionale, dat wil zeggen tabellarische weergaven met complexe hiërarchische rij- en kolomkoppen gebruikt.

Een tweedimensionale weergave van een kubus kan worden verkregen door deze over een of meer assen (dimensies) te ‘snijden’: we leggen de waarden van alle dimensies vast, behalve twee, en we krijgen een gewone tweedimensionale tabel. De horizontale as van de tabel (kolomkoppen) vertegenwoordigt één dimensie, de verticale as (rijkoppen) vertegenwoordigt een andere, en de tabelcellen vertegenwoordigen de waarden van de metingen. In dit geval wordt een reeks metingen feitelijk beschouwd als een van de dimensies. We selecteren ofwel één meting om weer te geven (en dan kunnen we twee dimensies in de rij- en kolomkoppen plaatsen), of we tonen meerdere metingen (en vervolgens een van de dimensies). de tabelassen worden ingenomen door de namen van metingen, en de andere - waarden van de enige "ongesneden" dimensie).

Kijk eens naar afb. 3 - hier is een tweedimensionaal deel van de kubus voor één maat - Verkoop per eenheid (verkochte stuks) en twee "ongesneden" dimensies - Winkel (Winkel) en Tijd (Tijd).

Rijst. 3. 2D-kubussegment voor één maat

In afb. Figuur 4 toont slechts één “ongesneden” dimensie: Winkel, maar toont de waarden van verschillende metingen: Verkoopeenheden (verkochte eenheden), Winkelverkoop (verkoopbedrag) en Winkelkosten (winkelkosten).

Rijst. 4. 2D-kubussegment voor meerdere metingen

Een tweedimensionale weergave van een kubus is ook mogelijk wanneer meer dan twee dimensies “ongesneden” blijven. In dit geval worden twee of meer dimensies van de "gesneden" kubus op de snijassen (rijen en kolommen) geplaatst - zie Fig. 5.

Rijst. 5. 2D-kubusplak met meerdere dimensies op één as

Labels

De waarden die langs dimensies worden "gelegd", worden leden of labels genoemd. Labels worden zowel gebruikt om de kubus te ‘knippen’ als om de geselecteerde gegevens te beperken (filteren). Wanneer we in een dimensie die ‘ongesneden’ blijft, niet geïnteresseerd zijn in alle waarden, maar in een subset daarvan, bijvoorbeeld drie steden uit enkele tientallen. Labelwaarden verschijnen in de 2D-kubusweergave als rij- en kolomkoppen.

Hiërarchieën en niveaus

Labels kunnen worden gecombineerd tot hiërarchieën die uit één of meer niveaus bestaan. De labels van de dimensie Winkel zijn bijvoorbeeld op natuurlijke wijze gegroepeerd in een hiërarchie met niveaus:

Land

Staat

Stad

Winkel.

Geaggregeerde waarden worden berekend op basis van de hiërarchieniveaus, bijvoorbeeld het verkoopvolume voor de VS ("Land"-niveau) of voor Californië ("Staat"-niveau). Het is mogelijk om meer dan één hiërarchie in één dimensie te implementeren, bijvoorbeeld voor tijd: (Jaar, Kwartaal, Maand, Dag) en (Jaar, Week, Dag).

Architectuur van OLAP-applicaties

Alles wat hierboven over OLAP is gezegd, had in wezen betrekking op de multidimensionale presentatie van gegevens. Hoe de data worden opgeslagen, gaat in grote lijnen noch de eindgebruiker, noch de ontwikkelaars van de tool die de klant gebruikt aan.

Multidimensionaliteit in OLAP-toepassingen kan worden onderverdeeld in drie niveaus:

• Multidimensionale gegevensrepresentatie - tools voor eindgebruikers die multidimensionale visualisatie en manipulatie van gegevens bieden; De multidimensionale representatielaag abstraheert van de fysieke structuur van de gegevens en behandelt de gegevens als multidimensionaal.
• Multidimensionale verwerking is een middel (taal) voor het formuleren van multidimensionale queries (de traditionele relationele taal SQL is hier niet geschikt) en een processor die een dergelijke query kan verwerken en uitvoeren.
• Multidimensionale opslag is een manier om gegevens fysiek te organiseren en zorgt voor een efficiënte uitvoering van multidimensionale zoekopdrachten.

De eerste twee niveaus zijn verplicht in alle OLAP-tools. Het derde niveau, hoewel wijdverspreid, is niet nodig, omdat gegevens voor een multidimensionale representatie uit gewone relationele structuren kunnen worden gehaald; De multidimensionale queryprocessor vertaalt in dit geval multidimensionale query's in SQL-query's die worden uitgevoerd door het relationele DBMS.

Specifieke OLAP-producten zijn in de regel ofwel een multidimensionaal hulpmiddel voor gegevensrepresentatie, een OLAP-client (bijvoorbeeld draaitabellen in Excel 2000 van Microsoft of ProClarity van Knosys), of een multidimensionale server DBMS, een OLAP-server (bijvoorbeeld Oracle Express Server of Microsoft OLAP-services).

De multidimensionale verwerkingslaag is meestal ingebouwd in de OLAP-client en/of OLAP-server, maar kan in zijn pure vorm worden geïsoleerd, zoals de Pivot Table Service-component van Microsoft.

Technische aspecten van multidimensionale dataopslag

Zoals hierboven vermeld, kunnen OLAP-analysetools ook gegevens rechtstreeks uit relationele systemen extraheren. Deze aanpak was aantrekkelijker in de tijd dat OLAP-servers nog niet waren opgenomen in de prijslijsten van toonaangevende DBMS-fabrikanten. Maar tegenwoordig bieden Oracle, Informix en Microsoft volwaardige OLAP-servers, en zelfs die IT-managers die er niet van houden om een ​​‘dierentuin’ van software van verschillende fabrikanten in hun netwerken te creëren, kunnen deze kopen (of beter gezegd, een overeenkomstig verzoek indienen bij het bedrijfsmanagement) OLAP-server van hetzelfde merk als de hoofddatabaseserver.

OLAP-servers, of multidimensionale databaseservers, kunnen hun multidimensionale gegevens op verschillende manieren opslaan. Voordat we deze methoden overwegen, moeten we het hebben over zo'n belangrijk aspect als het opslaan van eenheden. Feit is dat in elk datawarehouse - zowel gewoon als multidimensionaal - naast gedetailleerde gegevens uit operationele systemen, ook samenvattende indicatoren (geaggregeerde indicatoren, aggregaties) worden opgeslagen, zoals de som van de verkoopvolumes per maand, per categorie goederen, enz. Aggregaten worden expliciet opgeslagen met als enig doel de uitvoering van zoekopdrachten te versnellen. Aan de ene kant wordt immers in de regel een zeer grote hoeveelheid gegevens verzameld in het magazijn, en aan de andere kant zijn analisten in de meeste gevallen niet geïnteresseerd in gedetailleerde, maar in algemene indicatoren. En als elke keer miljoenen individuele verkopen bij elkaar zouden moeten worden opgeteld om de totale omzet voor het jaar te berekenen, zou de snelheid hoogstwaarschijnlijk onaanvaardbaar zijn. Daarom worden bij het laden van gegevens in een multidimensionale database alle totale indicatoren of een deel ervan berekend en opgeslagen.

Maar zoals je weet, moet je voor alles betalen. En u moet betalen voor de snelheid van het verwerken van verzoeken om samenvattende gegevens door het volume aan gegevens en de tijd die het kost om deze te laden te vergroten. Bovendien kan een volumetoename letterlijk catastrofaal zijn: in een van de gepubliceerde standaardtests was voor een volledige berekening van de aggregaten voor 10 MB aan brongegevens 2,4 GB nodig, d.w.z. de gegevens groeiden 240 keer! De mate waarin gegevens ‘opzwellen’ bij het berekenen van aggregaten hangt af van het aantal dimensies van de kubus en de structuur van deze dimensies, dat wil zeggen de verhouding tussen het aantal ‘vaders’ en ‘kinderen’ op verschillende meetniveaus. Om het probleem van het opslaan van aggregaten op te lossen, worden soms complexe schema's gebruikt, die het mogelijk maken om een ​​aanzienlijke verbetering van de queryprestaties te bereiken bij het berekenen van niet alle mogelijke aggregaten.

Nu over de verschillende opties voor het opslaan van informatie. Zowel gedetailleerde gegevens als aggregaten kunnen worden opgeslagen in relationele of multidimensionale structuren. Met multidimensionale opslag kunt u gegevens behandelen als een multidimensionale array, wat zorgt voor even snelle berekeningen van totaalindicatoren als verschillende multidimensionale transformaties langs alle dimensies. Enige tijd geleden ondersteunden OLAP-producten relationele of multidimensionale opslag. Tegenwoordig biedt hetzelfde product in de regel beide soorten opslag, evenals een derde type: gemengd. De volgende voorwaarden zijn van toepassing:

• Zowel ruwe als geaggregeerde gegevens kunnen worden opgeslagen in relationele of multidimensionale structuren. Daarom worden momenteel drie methoden voor gegevensopslag gebruikt.(Multidimensional OLAP) - zowel gedetailleerde gegevens als aggregaten worden opgeslagen in een multidimensionale database. In dit geval wordt de grootste redundantie verkregen, aangezien multidimensionale gegevens volledig relationele gegevens bevatten.
• ROLAP(Relationele OLAP) - gedetailleerde gegevens blijven waar ze oorspronkelijk "woonden" - in de relationele database; aggregaten worden opgeslagen in dezelfde database in speciaal gemaakte servicetabellen.
• HOLAP(Hybride OLAP) - gedetailleerde gegevens blijven op hun plaats (in een relationele database) en aggregaten worden opgeslagen in een multidimensionale database.

Elk van deze methoden heeft zijn eigen voor- en nadelen en moet worden gebruikt afhankelijk van de omstandigheden: de hoeveelheid gegevens, de kracht van het relationele DBMS, enz.

Bij het opslaan van gegevens in multidimensionale structuren is er een potentieel probleem van "bloat" als gevolg van het opslaan van lege waarden. Als in een multidimensionale array ruimte is gereserveerd voor alle mogelijke combinaties van dimensielabels, maar slechts een klein deel daadwerkelijk wordt gevuld (een aantal producten wordt bijvoorbeeld slechts in een klein aantal regio’s verkocht), dan zal het grootste deel van de kubus zal leeg zijn, hoewel de ruimte bezet zal zijn. Moderne OLAP-producten kunnen dit probleem aan.

Wordt vervolgd. In de toekomst zullen we het hebben over specifieke OLAP-producten geproduceerd door toonaangevende fabrikanten.

Ik woon al geruime tijd in Habr, maar heb nog nooit artikelen gelezen over het onderwerp multidimensionale kubussen, OLAP en MDX, hoewel het onderwerp erg interessant is en elke dag steeds relevanter wordt.
Het is geen geheim dat er in die korte periode van de ontwikkeling van databases, elektronische boekhouding en onlinesystemen veel gegevens zijn verzameld. Nu is een volledige analyse van de archieven, en misschien een poging om situaties voor soortgelijke modellen in de toekomst te voorspellen, ook van belang.
Aan de andere kant kunnen grote bedrijven, zelfs in de loop van meerdere jaren, maanden of zelfs weken, zulke grote hoeveelheden gegevens verzamelen dat zelfs hun basisanalyse een buitengewone aanpak en strenge hardwarevereisten vereist. Dit kunnen systemen voor de verwerking van banktransacties, effectenagenten, telefoonoperatoren, enz. zijn.
Ik denk dat iedereen zich goed bewust is van twee verschillende benaderingen van databaseontwerp: OLTP en OLAP. De eerste benadering (Online Transaction Processing - realtime transactieverwerking) is ontworpen voor efficiënte gegevensverzameling in realtime, terwijl de tweede (Online Analytical Processing - realtime analytische verwerking) specifiek gericht is op het op de meest efficiënte manier bemonsteren en verwerken van gegevens. manier.

Laten we eens kijken naar de belangrijkste mogelijkheden van moderne OLAP-kubussen en welke problemen ze oplossen (Analysis Services 2005/2008 wordt als basis genomen):

• snelle toegang tot gegevens
• vooraggregatie
• hiërarchie
• werken met de tijd
• multidimensionale taal voor gegevenstoegang
• KPI (Key Performance Indicators)
• datum mijnbouw
• caching op meerdere niveaus
• meertalige ondersteuning

Nog even over de mogelijkheden

Pre-aggregatie
Naast het snel ophalen van bestaande gegevens, biedt het ook de mogelijkheid om de “meest waarschijnlijk gebruikte” waarden vooraf te aggregeren. Als we bijvoorbeeld dagelijkse verkoopgegevens van een bepaald product hebben, kan het systeem Misschien We kunnen ook de maandelijkse en driemaandelijkse verkoopbedragen vooraf aggregeren, wat betekent dat als we maandelijks of driemaandelijks gegevens opvragen, het systeem ons onmiddellijk het resultaat zal geven. Waarom vindt pre-aggregatie niet altijd plaats - omdat theoretisch mogelijke combinaties van goederen/tijd/etc. het kan een groot aantal zijn, wat betekent dat u duidelijke regels moet hebben voor welke elementen de aggregatie zal worden gebouwd en voor welke niet. Over het algemeen is het onderwerp van het rekening houden met deze regels en het daadwerkelijke ontwerp van aggregaties vrij uitgebreid en verdient het op zichzelf een apart artikel.

Hiërarchieën
Het is logisch dat bij het analyseren van gegevens en het opstellen van eindrapporten rekening moet worden gehouden met het feit dat maanden uit dagen bestaan, en dat zij zelf wijken vormen, en dat steden deel uitmaken van gebieden die op hun beurt deel uitmaken van regio's of landen. . Het goede nieuws is dat OLAP-kubussen gegevens in eerste instantie bekijken in termen van hiërarchieën en relaties met andere parameters van dezelfde entiteit, waardoor het bouwen en gebruiken van hiërarchieën in kubussen heel eenvoudig is.

Werken met de tijd
Omdat data-analyse voornamelijk plaatsvindt in tijdgebieden, krijgt tijd een speciaal belang in OLAP-systemen, wat betekent dat door simpelweg te definiëren voor het systeem waar we hier tijd hebben, u in de toekomst eenvoudig functies kunt gebruiken zoals Year To Date, Month To Date (de periode vanaf het begin van het jaar/de maand tot de huidige datum), parallelle periode (op dezelfde dag of maand, maar vorig jaar), enz.

Multidimensionale taal voor gegevenstoegang
MDX(Multidimensional Expressions) - een zoektaal voor eenvoudige en efficiënte toegang tot multidimensionale datastructuren. En dat zegt alles: hieronder volgen enkele voorbeelden.

Key Performance Indicatoren (KPI)
Belangrijkste prestatie-indicatoren is een financieel en niet-financieel meetsysteem dat een organisatie helpt bij het bepalen van het behalen van strategische doelen. Key performance indicators kunnen heel eenvoudig in OLAP-systemen worden gedefinieerd en in rapporten worden gebruikt.

Mijndatum
Datamining(Datamining) - in wezen het identificeren van verborgen patronen of relaties tussen variabelen in grote datasets.
De Engelse term “Data Mining” heeft geen eenduidige vertaling in het Russisch (datamining, datamining, informatiemining, data/informatie-extractie) en wordt daarom in de meeste gevallen in het origineel gebruikt. De meest succesvolle indirecte vertaling is de term ‘datamining’ (DMA). Dit is echter een apart, niet minder interessant onderwerp om over na te denken.

Caching op meerdere niveaus
Om de hoogste snelheid van gegevenstoegang te garanderen, ondersteunen OLAP-systemen, naast lastige gegevensstructuren en pre-aggregaties, caching op meerdere niveaus. Naast het cachen van eenvoudige zoekopdrachten worden ook delen van gegevens die uit de opslag worden gelezen, geaggregeerde waarden en berekende waarden in de cache opgeslagen. Hoe langer u dus met een OLAP-kubus werkt, hoe sneller deze in feite begint te werken. Er is ook het concept van "het opwarmen van de cache" - een bewerking die het OLAP-systeem voorbereidt op het werken met specifieke rapporten, query's of alles gecombineerd.

Meertalige ondersteuning
Ja, ja, ja. Op zijn minst ondersteunt Analysis Services 2005/2008 (hoewel Enterprise Edition) native meertaligheid. Het is voldoende om een ​​vertaling van de stringparameters van uw gegevens te geven, en de klant die zijn taal heeft opgegeven, ontvangt gelokaliseerde gegevens.

Multidimensionale kubussen

In feite zal het vlak (of de verzameling van al deze punten) de kubus zijn, en dienovereenkomstig zullen Tijd, Producten en Klanten de dimensies ervan zijn.
Het is iets moeilijker om een ​​vierdimensionale of meer kubus voor te stellen (en te tekenen), maar de essentie verandert niet, en het allerbelangrijkste: voor OLAP-systemen maakt het helemaal niet uit in hoeveel dimensies je gaat werken (binnen redelijke grenzen). grenzen uiteraard).

Een beetje MDX

SELECTEER
(.) OP KOLOMMEN,
( ., . ) OP RIJEN
VAN
WAAR (., .)

Dat betekent dat ik het aantal verkochte iPhones in juni en juli in Mozambique wil hebben.
Tegelijkertijd beschrijf ik welke dit zijn de gegevens die ik wil en Hoe Ik wil ze in het rapport zien.
Prachtig, nietwaar?

Hier is het iets ingewikkelder:

MET LID AverageSpend AS
. / .
SELECTEER
( AverageSpend ) OP KOLOMMEN,
( .., .. ) OP RIJEN
VAN
WAAR(.)

* Deze broncode is gemarkeerd met Source Code Highlighter.

In feite bepalen we eerst de formule voor het berekenen van de "gemiddelde aankoopomvang" en proberen we te vergelijken wie (welk geslacht) meer geld uitgeeft tijdens één bezoek aan de Apple Store.

De taal zelf is buitengewoon interessant, zowel om te bestuderen als om te gebruiken, en verdient misschien veel discussie.

Conclusie

P.S. Dit is mijn eerste bericht over OLAP en de eerste publicatie over Habré. Ik zou zeer dankbaar zijn voor constructieve feedback.
Update: Ik heb het naar SQL overgebracht, ik zal het naar OLAP overbrengen zodra ik nieuwe blogs kan maken.

Tags: tags toevoegen