OLAP is geen afzonderlijk softwareproduct, geen programmeertaal of zelfs geen specifieke technologie. 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. Laten we het uitzoeken Waarvoor analisten hebben iets speciaals nodig vergemakkelijken toegang tot gegevens.

Feit is dat analisten bijzondere consumenten van bedrijfsinformatie zijn. De taak van de analist is om patronen te vinden in grote hoeveelheden gegevens. Daarom zal de analist geen aandacht besteden aan het afzonderlijke feit dat donderdag de vierde een partij zwarte inkt is verkocht aan tegenpartij Chernov - hij heeft informatie nodig ongeveer honderden en duizenden soortgelijke evenementen. Enkele feiten in de database kunnen bijvoorbeeld interessant zijn voor een accountant of het hoofd van de verkoopafdeling, die verantwoordelijk is voor de transactie. Voor een analist is één record niet genoeg; hij heeft bijvoorbeeld alle transacties van een bepaald filiaal of vertegenwoordigingskantoor nodig voor een maand of een jaar. Tegelijkertijd analist weggooit onnodige gegevens zoals het TIN van de koper, zijn exacte adres en telefoonnummer, contractindex en dergelijke. Tegelijkertijd bevatten de gegevens die een analist voor zijn werk nodig heeft noodzakelijkerwijs numerieke waarden - dit komt door de essentie van zijn activiteit.

De analist heeft dus veel data nodig, deze data zijn selectief en ook van de aard van ‘ attribuutset - nummer Dat laatste houdt in dat de analist werkt met tabellen van het volgende type:

Hier " Land", "Product", "Jaar" zijn attributen of metingen, A " Verkoopvolume" - daarbij de numerieke waarde of meeteenheid. De taak van de analist, herhalen we, is het identificeren van sterke relaties tussen attributen en numerieke parameters. Als u naar de tabel kijkt, zult u merken dat deze gemakkelijk in drie dimensies kan worden omgezet: we plaatsen landen op een van de assen, goederen op de andere en jaren op de derde. En de waarden in deze driedimensionale array zijn de overeenkomstige verkoopvolumes.

Driedimensionale weergave van de tafel. Het grijze segment laat zien dat er geen gegevens zijn voor Argentinië in 1988

Het is precies deze driedimensionale array die in OLAP-termen een kubus wordt genoemd. Vanuit het oogpunt van strikte wiskunde zal zo'n array niet altijd een kubus zijn: een echte kubus moet in alle dimensies hetzelfde aantal elementen hebben, maar OLAP-kubussen hebben zo'n beperking niet. Ondanks deze details is de term ‘OLAP-kubussen’ vanwege zijn beknoptheid en figurativiteit algemeen aanvaard geworden. Een OLAP-kubus hoeft niet driedimensionaal te zijn. Het kan zowel twee- als multidimensionaal zijn, afhankelijk van het probleem dat wordt opgelost. Vooral doorgewinterde analisten hebben mogelijk ongeveer twintig dimensies nodig - en serieuze OLAP-producten zijn precies voor dit bedrag ontworpen. Eenvoudigere desktopapplicaties ondersteunen ongeveer 6 dimensies.

Afmetingen OLAP-kubussen bestaan ​​uit zogenaamde merken of leden. De dimensie Land bestaat bijvoorbeeld uit de labels Argentinië, Brazilië, Venezuela, enzovoort.

Niet alle elementen van de kubus hoeven te worden ingevuld: als er geen informatie is over de verkoop van rubberproducten in Argentinië in 1988, wordt de waarde in de overeenkomstige cel eenvoudigweg niet bepaald. Het is ook helemaal niet nodig dat een OLAP-applicatie noodzakelijkerwijs gegevens in een multidimensionale structuur opslaat - het belangrijkste is dat deze gegevens er voor de gebruiker precies zo uitzien. Het zijn trouwens juist de speciale methoden voor compacte opslag van multidimensionale gegevens die ervoor zorgen dat “vacuüm” (ongevulde elementen) in kubussen niet tot geheugenverspilling leidt.

De kubus zelf is echter niet geschikt voor analyse. Als het nog steeds mogelijk is om een ​​driedimensionale kubus adequaat voor te stellen of af te beelden, dan is de situatie met een zes- of negentiendimensionale kubus veel erger. Dat is waarom vóór gebruik gewone worden uit een multidimensionale kubus gehaald tweedimensionale tabellen. Deze bewerking wordt het "snijden" van de kubus genoemd. Deze term is wederom figuurlijk. De analist neemt als het ware de afmetingen van de kubus en ‘snijdt’ deze volgens de kenmerken die voor hem van belang zijn. Op deze manier krijgt de analist een tweedimensionaal deel van de kubus en gaat ermee aan de slag. Op vrijwel dezelfde manier tellen houthakkers de jaarringen van een gekapte boom.

Dienovereenkomstig blijven in de regel slechts twee dimensies "ongesneden" - afhankelijk van het aantal dimensies in de tabel. Het komt voor dat alleen een dimensie “ongesneden” blijft - als een kubus verschillende soorten numerieke waarden bevat, kunnen deze langs een van de tabeldimensies worden uitgezet.

Als je nog beter naar de tabel kijkt die we als eerste hebben afgebeeld, zul je merken dat de gegevens daarin hoogstwaarschijnlijk niet primair zijn, maar als resultaat zijn verkregen sommatie op kleinere elementen. Een jaar is bijvoorbeeld verdeeld in kwartalen, kwartalen in maanden, maanden in weken, weken in dagen. Een land bestaat uit regio’s en regio’s uit bevolkte gebieden. Ten slotte kunnen in de steden zelf wijken en specifieke winkels worden geïdentificeerd. Producten kunnen worden gecombineerd in productgroepen enzovoort. In OLAP-termen worden dergelijke associaties op meerdere niveaus vrij logisch genoemd hiërarchieën. OLAP-tools maken het mogelijk om op elk moment naar het gewenste hiërarchieniveau te gaan. Bovendien worden in de regel verschillende soorten hiërarchieën ondersteund voor dezelfde elementen: bijvoorbeeld dag-week-maand of dag-decennium-kwartaal. Brongegevens worden uit lagere hiërarchieniveaus gehaald en vervolgens opgeteld om waarden op hogere niveaus te verkrijgen. Om het transitieproces te versnellen, worden de opgetelde waarden voor verschillende niveaus opgeslagen in een kubus. Dus wat er aan de kant van de gebruiker uitziet als één kubus, bestaat grofweg uit veel meer primitieve kubussen.

Hiërarchie voorbeeld

Dit is een van de essentiële punten die hebben geleid tot de opkomst van OLAP: productiviteit en efficiëntie. Laten we ons eens voorstellen wat er gebeurt als een analist informatie moet verkrijgen, maar er geen OLAP-tools in de onderneming zijn. De analist maakt zelfstandig (wat onwaarschijnlijk is) of met de hulp van een programmeur de juiste SQL-query en ontvangt de relevante gegevens in de vorm van een rapport of exporteert deze naar een spreadsheet. In dit geval doen zich een groot aantal problemen voor. Ten eerste wordt de analist gedwongen iets anders te doen dan zijn werk (SQL-programmeren) of te wachten tot programmeurs de taak voor hem hebben voltooid - dit alles heeft een negatieve invloed op de arbeidsproductiviteit, het aantal aanvallen, hartaanvallen en beroertes neemt toe, en spoedig. Ten tweede redt een enkel rapport of een enkele tabel in de regel de reuzen van het denken en de vaders van de Russische analyse niet - en de hele procedure zal keer op keer moeten worden herhaald. Ten derde, zoals we al hebben ontdekt, vragen analisten niet naar kleinigheden - ze hebben alles tegelijk nodig. Dit betekent (hoewel de technologie met grote sprongen vooruitgaat) dat de relationele DBMS-server waartoe de analist toegang heeft, diep en langdurig kan nadenken en andere transacties kan blokkeren.

Het concept van OLAP leek juist dergelijke problemen op te lossen. OLAP-kubussen zijn in wezen metarapporten. Door metarapporten (dat wil zeggen kubussen) langs dimensies te knippen, ontvangt de analist feitelijk de ‘gewone’ tweedimensionale rapporten die hem interesseren (dit zijn niet noodzakelijkerwijs rapporten in de gebruikelijke zin van het woord – we hebben het over datastructuren met dezelfde functies). De voordelen van kubussen liggen voor de hand: bij het bouwen van een kubus hoeven gegevens slechts één keer uit een relationeel DBMS te worden opgevraagd. Omdat analisten in de regel niet werken met informatie die ‘on the fly’ wordt aangevuld en gewijzigd, is de gegenereerde kubus lange tijd relevant. Hierdoor worden niet alleen onderbrekingen in de werking van de relationele DBMS-server geëlimineerd (er zijn geen vragen met duizenden en miljoenen antwoordlijnen), maar neemt ook de snelheid van toegang tot gegevens voor de analist zelf sterk toe. Bovendien wordt, zoals reeds opgemerkt, de productiviteit ook verbeterd door subsommen van hiërarchieën en andere geaggregeerde waarden te berekenen op het moment dat de kubus wordt gebouwd. Dat wil zeggen: als onze gegevens aanvankelijk informatie bevatten over de dagelijkse omzet voor een specifiek product in een enkele winkel, berekent de OLAP-applicatie bij het vormen van een kubus de totalen voor verschillende hiërarchieniveaus (weken en maanden, steden en landen).

Natuurlijk moet je betalen om de productiviteit op deze manier te verhogen. Soms zeggen ze dat de datastructuur eenvoudigweg "explodeert" - een OLAP-kubus kan tientallen of zelfs honderden keren meer ruimte in beslag nemen dan de originele gegevens.

Beantwoord de vragen:

Wat is er gebeurd kubus OLAP?

Wat is er gebeurd labels specifieke meting? Geef voorbeelden.

Kunnen ze maatregelen in een OLAP-kubus niet-numerieke waarden bevatten.

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? OLAP-datawarehouse ;
• 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’ gegevens een analist kan verkennen, hoe meer ideeën hij heeft, die op hun beurt steeds meer ‘segmenten’ nodig hebben 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 oorspronkelijke 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 gevolg daarvan 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 ​​openbaar 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 ondernemingsniveau meestal gebaseerd zijn op OLAP-servertools, bijvoorbeeld Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, producten van Crystal Decisions, Business Objects, Cognos en SAS Institute.

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, bij het berekenen van niet alle mogelijke geaggregeerde gegevens, een aanvaardbare snelheid van de uitvoering van zoekopdrachten te bereiken.

• 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 op te slaan in multidimensionale structuren 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 metingen. 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 de metingen, en de andere door waarden van de enige "ongesneden" dimensie).

(niveaus). De labels die in worden weergegeven, worden bijvoorbeeld niet door alle OLAP-hulpmiddelen ondersteund. Microsoft Analysis Services 2000 ondersteunt bijvoorbeeld beide typen hiërarchie, maar Microsoft OLAP Services 7.0 ondersteunt alleen gebalanceerde typen. Het aantal hiërarchieniveaus, het maximaal toegestane aantal leden van één niveau en het maximaal mogelijke aantal dimensies zelf kunnen in verschillende OLAP-tools verschillend zijn.

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 ook uit gewone relationele structuren kunnen worden gehaald; De multidimensionale queryprocessor vertaalt in dit geval multidimensionale query's naar SQL-query's die worden uitgevoerd door een relationeel 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.

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

Laten we de mogelijkheden van OLAP-kubussen dus wat gedetailleerder bekijken.

Nog even over de mogelijkheden

Snelle toegang tot gegevens
Eigenlijk is snelle toegang tot gegevens, ongeacht de grootte van de array, de basis van OLAP-systemen. Omdat dit de belangrijkste focus is, is een datawarehouse meestal gebouwd op andere principes dan die van relationele databases.
Hier wordt de tijd voor het ophalen van eenvoudige gegevens gemeten in fracties van een seconde, en een zoekopdracht die langer duurt dan een paar seconden vereist hoogstwaarschijnlijk optimalisatie.

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 hoeveelheden gegevens.
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 winkel 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

Dus wat zijn deze multidimensionale kubussen precies?
Laten we ons een driedimensionale ruimte voorstellen waarvan de assen tijd, producten en klanten zijn.
Een punt in een dergelijke ruimte geeft aan dat een van de kopers in een bepaalde maand een specifiek product heeft gekocht.

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

Dus wat is het mooie van MDX? Hoogstwaarschijnlijk is het dat we niet moeten beschrijven hoe we gegevens willen selecteren, maar Wat precies wij willen.
Bijvoorbeeld,

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

In feite behandelt dit artikel heel weinig, zelfs niet de basisconcepten; ik zou het een “voorgerecht” willen noemen - een kans om de Habra-gemeenschap voor dit onderwerp te interesseren en het verder te ontwikkelen. Wat de ontwikkeling betreft, er is hier een enorm, ongeploegd veld en ik beantwoord graag al uw vragen.

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

In een standaard draaitabel worden de brongegevens op uw lokale harde schijf opgeslagen. Zo kun je ze altijd beheren en reorganiseren, ook zonder toegang tot het netwerk. Maar dit is op geen enkele manier van toepassing op OLAP-draaitabellen. In OLAP-draaitabellen wordt de cache nooit op de lokale harde schijf opgeslagen. Daarom zal uw draaitabel onmiddellijk na het verbreken van de verbinding met het lokale netwerk niet meer werken. Je kunt er geen enkel veld in verplaatsen.

Als u nog steeds OLAP-gegevens moet analyseren nadat u offline bent gegaan, maakt u een offline gegevenskubus. Een offline gegevenskubus is een afzonderlijk bestand dat een draaitabelcache is en OLAP-gegevens opslaat die worden bekeken nadat de verbinding met het lokale netwerk is verbroken. OLAP-gegevens die naar een draaitabel zijn gekopieerd, kunnen worden afgedrukt; dit wordt gedetailleerd beschreven op de website http://everest.ua.

Als u een zelfstandige gegevenskubus wilt maken, maakt u eerst een OLAP-draaitabel. Plaats de cursor in de draaitabel en klik op de knop OLAP-hulpmiddelen op het contextuele tabblad Hulpmiddelen, dat deel uitmaakt van de contextuele tabbladgroep Draaitabelhulpmiddelen. Selecteer de Offline OLAP-opdracht (Fig. 9.8).

Het dialoogvenster Offline OLAP Data Cube-instellingen verschijnt op het scherm. Klik op de knop Offline gegevensbestand maken. U hebt de wizard Gegevenskubusbestand maken gestart. Klik op de knop Volgende om door te gaan met de procedure.

Eerst moet u de dimensies en niveaus opgeven die in de gegevenskubus worden opgenomen. In het dialoogvenster moet u de gegevens selecteren die uit de OLAP-database worden geïmporteerd. Het idee is om alleen die afmetingen op te geven die nodig zijn nadat de computer is losgekoppeld van het lokale netwerk. Hoe meer dimensies u opgeeft, hoe groter de autonome datakubus zal zijn.

Klik op de knop Volgende om naar het volgende dialoogvenster van de wizard te gaan. Dit geeft u de mogelijkheid om leden of gegevenselementen op te geven die niet in de kubus worden opgenomen. In het bijzonder hebt u de maatregel Internetverkoop - Uitgebreid bedrag niet nodig, dus het selectievakje in de lijst wordt leeggemaakt. Een uitgeschakeld selectievakje geeft aan dat het opgegeven item niet wordt geïmporteerd en onnodige ruimte in beslag neemt op uw lokale harde schijf.

Geef in de laatste stap de locatie en naam van de gegevenskubus op. In ons geval krijgt het kubusbestand de naam MyOfflineCube.cub en bevindt het zich in de map Werk.

Datakubusbestanden hebben de extensie .welp

Na enige tijd slaat Excel de offline gegevenskubus op in de opgegeven map. Om het te testen, dubbelklikt u op het bestand, waardoor automatisch een Excel-werkmap wordt gegenereerd met een draaitabel die is gekoppeld aan de geselecteerde gegevenskubus. Eenmaal gemaakt, kunt u de offline datakubus distribueren naar alle geïnteresseerde gebruikers die in de offline LAN-modus werken.

Eenmaal verbonden met het lokale netwerk, kunt u het offline datakubusbestand openen en dit en de bijbehorende gegevenstabel bijwerken. Het hoofdprincipe houdt in dat de offline datakubus alleen wordt gebruikt als het lokale netwerk is verbroken, maar dat deze moet worden bijgewerkt nadat de verbinding is hersteld. Als u probeert een offline datakubus bij te werken nadat de verbinding is mislukt, resulteert dit in een fout.

Informatiesystemen van een serieuze onderneming bevatten in de regel applicaties die zijn ontworpen voor complexe analyse van gegevens, hun dynamiek, trends, enz. Dienovereenkomstig wordt het topmanagement de belangrijkste consumenten van de analyseresultaten. Een dergelijke analyse is uiteindelijk bedoeld om de besluitvorming te ondersteunen. En om een ​​managementbeslissing te kunnen nemen, is het noodzakelijk om over de noodzakelijke informatie te beschikken, meestal kwantitatief. Om dit te doen, is het noodzakelijk om deze gegevens uit alle informatiesystemen van de onderneming te verzamelen, in een gemeenschappelijk formaat te brengen en pas daarna te analyseren. Voor dit doel worden datawarehouses gecreëerd.

Wat is een datawarehouse?

Meestal - de plaats waar alle informatie van analytische waarde wordt verzameld. De vereisten voor dergelijke winkels komen overeen met de klassieke definitie van OLAP en zullen hieronder worden uitgelegd.

Soms heeft het Warehouse een ander doel: de integratie van alle bedrijfsgegevens, om de integriteit en relevantie van informatie binnen alle informatiesystemen te behouden. Dat. de repository verzamelt niet alleen analytische, maar bijna alle informatie, en kan deze in de vorm van mappen terugsturen naar andere systemen.

Een typisch datawarehouse verschilt doorgaans van een typische relationele database. Ten eerste zijn reguliere databases ontworpen om gebruikers te helpen bij het dagelijkse werk, terwijl datawarehouses zijn ontworpen voor besluitvorming. De verkoop van goederen en de uitgifte van facturen worden bijvoorbeeld uitgevoerd met behulp van een database die is ontworpen voor het verwerken van transacties, en de analyse van de verkoopdynamiek over meerdere jaren, waardoor planningswerk met leveranciers mogelijk is, wordt uitgevoerd met behulp van een datawarehouse.

Ten tweede zijn traditionele databases onderhevig aan voortdurende veranderingen terwijl gebruikers werken, maar een datawarehouse is relatief stabiel: de gegevens daarin worden doorgaans volgens een schema bijgewerkt (bijvoorbeeld wekelijks, dagelijks of elk uur, afhankelijk van de behoeften). Idealiter bestaat het verrijkingsproces simpelweg uit het toevoegen van nieuwe gegevens over een bepaalde periode, zonder dat de eerdere informatie die zich al in de repository bevindt, wordt gewijzigd.

En ten derde zijn reguliere databases meestal de bron van gegevens die in het magazijn terechtkomen. Bovendien kan de repository worden aangevuld vanuit externe bronnen, zoals statistische rapporten.

Hoe wordt een opslagruimte gebouwd?

ETL– basisconcept: drie fasen:

• Extractie – gegevens uit externe bronnen extraheren in een begrijpelijk formaat;
• Transformatie – transformatie van de structuur van de brongegevens in structuren die handig zijn voor het bouwen van een analytisch systeem;

Laten we nog een fase toevoegen: gegevens opschonen ( Schoonmaak) – het proces van het uitfilteren van irrelevante of het corrigeren van foutieve gegevens op basis van statistische of deskundige methoden. Om later geen rapporten als “Verkoop voor 20011” te genereren.

Laten we terugkeren naar de analyse.

Wat is analyse en waarom is het nodig?

Analyse is het bestuderen van gegevens met als doel het nemen van beslissingen. Analytische systemen worden beslissingsondersteunende systemen genoemd ( DSS).

Hier is het de moeite waard om te wijzen op het verschil tussen het werken met DSS en een eenvoudige set gereguleerde en niet-gereguleerde rapporten. Analyse in DSS is vrijwel altijd interactief en iteratief. Die. de analist graaft in de data, stelt analytische queries samen en past deze aan, en ontvangt rapporten waarvan de structuur op voorhand wellicht onbekend is. We komen hier hieronder meer in detail op terug als we de querytaal bespreken. MDX.

OLAP

Beslissingsondersteunende systemen beschikken doorgaans over de middelen om de gebruiker te voorzien van geaggregeerde gegevens voor verschillende voorbeelden uit de oorspronkelijke set in een vorm die handig is voor perceptie en analyse (tabellen, grafieken, enz.). De traditionele benadering voor het segmenteren van brongegevens omvat het extraheren uit de brongegevens van een of meer multidimensionale gegevenssets (vaak een hyperkubus of metacube genoemd), waarvan de assen attributen bevatten en de cellen geaggregeerde kwantitatieve gegevens bevatten. (Dergelijke gegevens kunnen ook worden opgeslagen in relationele tabellen, maar in dit geval hebben we het over de logische organisatie van gegevens, en niet over de fysieke implementatie van hun opslag.) Langs elke as kunnen attributen worden georganiseerd in de vorm van hiërarchieën, die verschillende niveaus van hun detail vertegenwoordigen. Dankzij dit datamodel kunnen gebruikers complexe zoekopdrachten formuleren, rapporten genereren en subsets van gegevens verkrijgen.

De technologie voor complexe multidimensionale data-analyse heet OLAP (On-Line Analytical Processing). OLAP is een belangrijk onderdeel van traditionele datawarehousing. Het concept van OLAP werd in 1993 beschreven door Edgar Codd, een gerenommeerd databaseonderzoeker en auteur van het relationele datamodel. In 1995 werd op basis van de eisen van Codd de zogenaamde FASMI-test (Fast Analysis of Shared Multidimensional Information) geformuleerd, die de volgende eisen omvat voor toepassingen voor multidimensionale analyse:

• de gebruiker voorzien van analyseresultaten binnen een aanvaardbare tijd (meestal niet meer dan 5 s), zelfs ten koste van een minder gedetailleerde 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;
• toegang voor meerdere gebruikers tot gegevens met ondersteuning voor passende vergrendelingsmechanismen en geautoriseerde toegangsmiddelen;
• multidimensionale conceptuele representatie van gegevens, inclusief volledige ondersteuning voor hiërarchieën en meerdere hiërarchieën (dit is een belangrijke vereiste van OLAP);
• de mogelijkheid om toegang te krijgen 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. Die. OLAP is geen technologie, maar ideologie.

Voordat we het hebben over de verschillende OLAP-implementaties, gaan we eerst eens nader bekijken wat kubussen zijn vanuit logisch oogpunt.

Multidimensionale concepten

Om de principes van OLAP te illustreren, zullen we de Northwind-database gebruiken, die deel uitmaakt van Microsoft SQL Server en een typische database is die handelsinformatie opslaat voor een groothandel in voedseldistributie. Dergelijke gegevens omvatten informatie over leveranciers, klanten, een lijst met geleverde goederen en hun categorieën, gegevens over bestellingen en bestelde goederen, een lijst met bedrijfsmedewerkers.

Kubus

Laten we bijvoorbeeld de tabel Facturen1 nemen, die de orders van het bedrijf bevat. De velden in deze tabel zijn als volgt:

• Besteldatum
• Land
• Stad
• Klantnaam
• Bezorgbedrijf
• Productnaam
• Producthoeveelheid
• Bestelbedrag

Welke geaggregeerde gegevens kunnen we uit deze weergave halen? Meestal zijn dit antwoorden op vragen als:

• Wat is de totale waarde van bestellingen geplaatst door klanten uit een bepaald land?
• Wat is de totale waarde van bestellingen die door klanten in een bepaald land zijn geplaatst en door een bepaald bedrijf zijn geleverd?
• Wat is de totale waarde van bestellingen die in een bepaald jaar door klanten in een bepaald land zijn geplaatst en door een bepaald bedrijf zijn geleverd?

Al deze gegevens kunnen uit deze tabel worden verkregen met behulp van voor de hand liggende SQL-query's met groepering.

Het resultaat van deze zoekopdracht zal altijd een kolom met cijfers zijn en een lijst met attributen die deze beschrijven (bijvoorbeeld land) - dit is een eendimensionale gegevensset of, in wiskundige taal, een vector.

Laten we ons voorstellen dat we informatie moeten verkrijgen over de totale kosten van bestellingen uit alle landen en hun verdeling over bezorgbedrijven - we krijgen een tabel (matrix) met getallen, waarin bezorgbedrijven worden vermeld in de kolomkoppen, landen in de rij rubrieken, en in de cellen zal het aantal bestellingen staan. Dit is een tweedimensionale gegevensarray. Deze set gegevens wordt een draaitabel genoemd ( draaitabel) of kruistabel.

Als we dezelfde gegevens willen krijgen, maar ook per jaar, zal er een andere wijziging optreden, namelijk de dataset wordt driedimensionaal (een voorwaardelijke tensor van de derde orde of een driedimensionale “kubus”).

Uiteraard is het maximale aantal dimensies het aantal van alle attributen (Datum, Land, Klant, enz.) die onze geaggregeerde gegevens beschrijven (aantal bestellingen, aantal producten, enz.).

Dit is hoe we tot het concept van multidimensionaliteit en de belichaming ervan komen - multidimensionale kubus. Zo’n tafel noemen we “ feiten tabel" Afmetingen of kubusassen ( afmetingen) zijn attributen waarvan de coördinaten worden uitgedrukt door de individuele waarden van deze attributen die aanwezig zijn in de feitentabel. Die. Als bijvoorbeeld informatie over bestellingen in het systeem werd bijgehouden van 2003 tot 2010, dan zal de as van dit jaar uit 8 overeenkomstige punten bestaan. Als bestellingen uit drie landen komen, bevat de landenas 3 punten, enz. Ongeacht hoeveel landen er in de landenlijst zijn opgenomen. Punten op een as worden de “leden” genoemd ( Leden).

In dit geval worden de geaggregeerde gegevens zelf “maatregelen” genoemd ( Meeteenheid). Om verwarring met ‘afmetingen’ te voorkomen worden deze laatste bij voorkeur ‘assen’ genoemd. De reeks metingen vormt een andere "Maatregelen"-as ( Maatregelen). Het heeft evenveel leden (punten) als er metingen (geaggregeerde kolommen) in de feitentabel zijn.

Leden van dimensies of assen kunnen worden gecombineerd door een of meer hiërarchieën ( hiërarchie). Laten we met een voorbeeld uitleggen wat hiërarchie is: steden uit orden kunnen verenigd worden in districten, districten in regio's, regio's van een land, landen in continenten of andere entiteiten. Die. er is een hiërarchische structuur - continent- land-regio-district-stad– 5 niveaus ( Niveau). Voor een regio worden gegevens verzameld voor alle steden die erin zijn opgenomen. Voor een regio over alle districten die alle steden bevatten, enz. Waarom hebben we meerdere hiërarchieën nodig? Op de orderdatumas willen we bijvoorbeeld punten (d.w.z. dagen) in een hiërarchie groeperen Jaar-maand-dag of door Jaar-Week-Dag: in beide gevallen zijn er drie niveaus. Uiteraard groeperen Week en Maand de dagen anders. Er zijn ook hiërarchieën, waarbij het aantal niveaus niet deterministisch is en afhankelijk is van de gegevens. Bijvoorbeeld mappen op een computerschijf.

Gegevensaggregatie kan plaatsvinden met behulp van verschillende standaardfuncties: som, minimum, maximum, gemiddelde, aantal.

MDX

Laten we verder gaan met de querytaal in multidimensionale gegevens.
De SQL-taal is oorspronkelijk niet ontworpen voor programmeurs, maar voor analisten (en heeft daarom een ​​syntaxis die lijkt op natuurlijke taal). Maar na verloop van tijd werd het steeds ingewikkelder en nu weten maar weinig analisten hoe ze het goed moeten gebruiken, of helemaal niet. Het is een hulpmiddel voor programmeurs geworden. De MDX-querytaal, waarvan wordt beweerd dat deze door onze voormalige landgenoot Mosha (of Mosha) Posumansky in de wildernis van Microsoft Corporation is ontwikkeld, was aanvankelijk ook bedoeld om op analisten te zijn gericht, maar de concepten en syntaxis ervan (die vaag op SQL lijkt, en volkomen tevergeefs, d.w.z. omdat het alleen maar verwart), zelfs ingewikkelder dan SQL. De basisprincipes zijn echter nog steeds gemakkelijk te begrijpen.

We zullen er in detail naar kijken omdat het de enige taal is die de standaardstatus heeft gekregen binnen het raamwerk van de algemene XMLA-protocolstandaard, en ten tweede omdat er een open source-implementatie van is in de vorm van het Mondriaan-project van het bedrijf Pentaho. Andere OLAP-analysesystemen (bijvoorbeeld Oracle OLAP Option) gebruiken meestal hun eigen SQL-syntaxisextensies, maar ze verklaren ook ondersteuning voor MDX.

Werken met analytische datasets betekent alleen dat je ze leest en niet dat je ze schrijft. Dat. MDX heeft geen clausules voor het wijzigen van gegevens, maar slechts één selectieclausule: select.

In OLAP kun je multidimensionale kubussen maken plakjes– d.w.z. wanneer gegevens langs een of meer assen worden gefilterd, of projecties– wanneer de kubus langs een of meer assen “instort”, waardoor gegevens worden samengevoegd. Ons eerste voorbeeld met het aantal bestellingen uit landen is bijvoorbeeld een projectie van de kubus op de landenas. De MDX-query voor dit geval ziet er als volgt uit:

Selecteer ...Kinderen op rijen van
Wat is wat hier?

Selecteer– het sleutelwoord is uitsluitend voor schoonheid in de syntaxis opgenomen.
is de naam van de as. Alle eigennamen in MDX worden tussen vierkante haakjes geschreven.
is de naam van de hiërarchie. In ons geval is dit de hiërarchie Land-Stad
– dit is de naam van het aslid op het eerste niveau van de hiërarchie (d.w.z. land). Alles – dit is een metalid dat alle leden van de as verenigt. Er is zo'n metaterm in elke as. Op de jaaras staat bijvoorbeeld “Alle jaren”, enz.
Kinderen is een ledenfunctie. Elk lid heeft verschillende functies beschikbaar. Zoals Ouder. Niveau, Hiërarchie, waarbij respectievelijk de voorloper, het niveau in de hiërarchie en de hiërarchie zelf waartoe het lid behoort in dit geval worden geretourneerd. Kinderen: retourneert een reeks onderliggende leden van dit lid. Die. in ons geval – landen.
op rijen– Specificeert hoe deze gegevens in de resulterende tabel moeten worden gerangschikt. In dit geval - in de koptekst van de regels. Mogelijke waarden hier: op kolommen, op pagina's, op alinea's, etc. Het is ook mogelijk om eenvoudig aan te geven per index, beginnend vanaf 0.
van– dit is een aanduiding van de kubus waaruit de selectie wordt gemaakt.

Wat als we niet alle landen nodig hebben, maar slechts een paar specifieke landen? Om dit te doen, kunnen we in de aanvraag expliciet de landen specificeren die we nodig hebben, in plaats van alles te selecteren met de functie Kinderen.

Selecteer ( ..., ... ) op rijen uit
De accolades zijn in dit geval de declaratie van de set ( Set). Een set is een lijst, een opsomming van leden vanuit één as.

Laten we nu een vraag schrijven voor ons tweede voorbeeld: uitvoer in de context van een bezorger:

Selecteer ...Kinderen op rijen.Leden op kolommen uit
Hier toegevoegd:
– as;
.Leden– een asfunctie die alle termen erop retourneert. Hiërarchie en niveau hebben dezelfde functie. Omdat Er is slechts één hiërarchie op deze as, en de aanduiding ervan kan worden weggelaten, omdat het niveau en de hiërarchie zijn ook hetzelfde, dan kunt u alle leden in één lijst weergeven.

Ik denk dat het al duidelijk is hoe we dit kunnen voortzetten met ons derde voorbeeld, gedetailleerd per jaar. Maar laten we beter niet op jaartal inzoomen, maar filteren – d.w.z. bouw een stukje Om dit te doen, zullen we de volgende query schrijven:

Selecteer ..Kinderen op rijen .Leden op kolommen van waar (.)
Waar is hier de filtratie?

waar– trefwoord
is een lid van de hiërarchie . De volledige naam, inclusief alle termen, zou zijn: .. , maar omdat Omdat de naam van dit lid uniek is binnen de as, kunnen alle tussenliggende verduidelijkingen van de naam worden weggelaten.

Waarom staat de datumterm tussen haakjes? De haakjes zijn een tupel ( tupel). Een tupel is één of meerdere coördinaten mee verscheidene bijlen Om bijvoorbeeld langs twee assen tegelijk tussen haakjes te filteren, vermelden we twee termen uit verschillend metingen gescheiden door komma's. Dat wil zeggen, de tuple definieert een “deel” van de kubus (of “filtering”, als een dergelijke terminologie dichterbij komt).

De tupel wordt voor meer dan alleen filteren gebruikt. Tupels kunnen ook voorkomen in rij-/kolom-/paginakoppen, enz.

Dit is bijvoorbeeld nodig om het resultaat van een driedimensionale zoekopdracht in een tweedimensionale tabel weer te geven.

Selecteer crossjoin(...Children, ..Children) op rijen. Leden op kolommen van waar (.)
Dwarsverbinding is een functie. Het retourneert een set tupels (ja, een set kan tupels bevatten!) die voortvloeit uit het Cartesiaanse product van twee sets. Die. de resulterende set bevat alle mogelijke combinaties van landen en jaren. De rijkoppen bevatten dus een paar waarden: Land-jaar.

De vraag is: waar wordt aangegeven welke numerieke kenmerken moeten worden weergegeven? In dit geval wordt de standaardmaat gebruikt die voor deze kubus is gedefinieerd, d.w.z. Bestelbedrag. Als we een andere maat willen afleiden, onthouden we dat maten lid zijn van een dimensie Maatregelen. En we handelen op precies dezelfde manier als bij de andere assen. Die. Als u een zoekopdracht filtert op een van de meetwaarden, wordt precies deze meetwaarde in de cellen weergegeven.

Vraag: Wat is het verschil tussen filteren op waar en filteren door asleden op te geven in rijen. Antwoord: vrijwel niets. Gewoon waar een segment wordt aangegeven voor die assen die niet deelnemen aan de vorming van koppen. Die. dezelfde as kan niet tegelijk aanwezig zijn op rijen, en binnen waar.

Berekende leden

Voor complexere query's kunt u berekende leden declareren. Leden van zowel de attribuut- als de meetwaarde-as. Die. U kunt bijvoorbeeld een nieuwe maatregel declareren die de bijdrage van elk land aan het totale aantal bestellingen weergeeft:

Met lid. als '.CurrentMember / ..', FORMAT_STRING='0.00%' selecteer ...Kinderen op rijen van waar .
De berekening vindt plaats in de context van een cel waarin alle coördinaatattributen bekend zijn. De corresponderende coördinaten (leden) kunnen worden verkregen door de functie CurrentMember voor elk van de kubusassen. Hier moeten we begrijpen dat de uitdrukking .Huidig ​​lid/..’ verdeelt niet de ene term door de andere, maar verdeelt relevante geaggregeerde gegevens kubus plakjes! Die. het segment voor het huidige territorium wordt verdeeld in een segment voor alle territoria, d.w.z. de totale waarde van alle bestellingen. FORMAT_STRING – stelt het formaat in voor het weergeven van waarden, d.w.z. %.

Nog een voorbeeld van een berekend lid, maar dan op de jarenas:

Met lid. als '. - .’
Uiteraard zal het rapport geen eenheid bevatten, maar het verschil tussen de overeenkomstige secties, d.w.z. het verschil in het aantal bestellingen in deze twee jaar.

Weergave in ROLAP

OLAP-systemen zijn op de een of andere manier gebaseerd op een soort gegevensopslag- en organisatiesysteem. Als we het over RDBMS hebben, hebben we het over ROLAP (we laten MOLAP en HOLAP over voor onafhankelijk onderzoek). ROLAP – OLAP op een relationele database, d.w.z. beschreven in de vorm van gewone tweedimensionale tabellen. ROLAP-systemen zetten MDX-query's om in SQL. Het belangrijkste computerprobleem voor databases is snelle aggregatie. Om sneller te kunnen aggregeren, zijn de gegevens in de database meestal sterk gedenormaliseerd, d.w.z. worden niet erg efficiënt opgeslagen in termen van ingenomen schijfruimte en monitoring van de database-integriteit. Bovendien bevatten ze bovendien hulptabellen waarin gedeeltelijk geaggregeerde gegevens worden opgeslagen. Daarom wordt voor OLAP meestal een apart databaseschema gemaakt, dat de structuur van de oorspronkelijke transactionele databases in termen van mappen slechts gedeeltelijk repliceert.

Navigatie

Veel OLAP-systemen bieden interactieve navigatiehulpmiddelen voor een reeds gegenereerde zoekopdracht (en dienovereenkomstig geselecteerde gegevens). In dit geval wordt het zogenaamde "boren" of "boren" gebruikt. Een adequatere vertaling in het Russisch zou het woord ‘verdieping’ zijn. Maar dit is een kwestie van smaak, in sommige omgevingen is het woord ‘boren’ blijven hangen.

Oefening– dit is de detaillering van het rapport door de mate van gegevensaggregatie te verminderen, gecombineerd met filtering langs een andere as (of meerdere assen). Er zijn verschillende soorten boren:

• inzoomen– filteren langs een van de bronassen van het rapport met weergave van gedetailleerde informatie over nakomelingen binnen de hiërarchie van het geselecteerde filterlid. Als er bijvoorbeeld een rapport is over de verdeling van bestellingen, uitgesplitst naar landen en jaren, dan wordt door op het jaar 2007 te klikken een rapport weergegeven, uitgesplitst naar dezelfde landen en maanden van 2007.
• boorzijde– filteren onder een of meer geselecteerde assen en aggregatie langs een of meer andere assen verwijderen. Als er bijvoorbeeld een rapport is over de verdeling van bestellingen, uitgesplitst naar landen en jaren, zal een klik op het jaar 2007 een ander rapport weergeven, bijvoorbeeld uitgesplitst naar landen en leveranciers, met filtering op 2007.
• boor-goot– het verwijderen van aggregatie langs alle assen en het gelijktijdig filteren ervan – stelt u in staat de brongegevens te zien uit de feitentabel waaruit de waarde in het rapport is verkregen. Die. Wanneer u op een celwaarde klikt, wordt een rapport weergegeven met alle bestellingen die dit bedrag hebben opgeleverd. Een soort instant boren in de “diepte” van de kubus.

Dat is alles. Als u besluit u te wijden aan Business Intelligence en OLAP, is het tijd om serieuze literatuur te gaan lezen.

Tags: tags toevoegen