Naar een doorgedreven integratie van OLAP in de BI-omgeving

Beleidsinformatica Tijdschrift

Volume 30 Nummer 2 (2004)

Naar een doorgedreven integratie van OLAP in de BI-omgeving Stijn Goedertier 1 [email protected]

Abstract OnLine Analytical Processing (OLAP) speelt al jaren een prominente rol bij de analyse van de steeds groter wordende hoeveelheden cijfermateriaal waar bedrijven heden ten dage mee geconfronteerd worden. Deze populariteit heeft OLAP vooral te danken aan de eenvoud en de snelle responstijd waarmee alledaagse cijferanalyses uitgevoerd kunnen worden. Toch hangt het succes van OLAP niet alleen af van diens eigen functionaliteit, maar ook van de mate waarin OLAP zich integreert met de andere componenten van de Business Intelligence-omgeving (BI). In dit artikel worden drie aspecten van deze integratie behandeld. Een eerste aspect is de evolutie naar een ge¨ıntegreerd metamodel, dat de duplicatie van metadata binnen de componenten van een BI-suite moet voorkomen. Daarnaast is er de ontwikkeling van een universele OLAP-API, die een uniforme toegang tot OLAP-bronnen moet bewerkstelligen. Een laatste, zeer interessant aspect, zijn de integratiemogelijkheden tussen OLAP en data mining, die het onderscheid tussen verificatiegebaseerde en ontdekkingsgebaseerde analysestrategie¨en doet vervagen.2

1

De auteur is heden ten dage tewerkgesteld aan het Departement Toegepaste Economische Wetenschappen (FLOF-mandaat) en verricht onder leiding van Prof. Dr. J. Vanthienen onderzoek rond de zogenaamde ‘‘Business Rules”-benadering in systeemanalyse en -ontwikkeling. 2

Dit artikel is geschreven op basis van de eindverhandeling van de auteur: Naar een integratie van OLAP en data mining, Faculteit ETEW, 2004 (Promotor: Prof. Dr. J. Vandenbulcke).

Inhoudsopgave 1

Inleiding 1.1 Definitie van OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Situering van OLAP in de BI-omgeving . . . . . . . . . . . . . . . 1.3 Naar een doorgedreven integratie . . . . . . . . . . . . . . . . . . .

3 3 4 5

2

Het multidimensionaal gegevensmodel 2.1 Dimensies en cellen . . . . . . . . 2.2 Hi¨erarchie¨en . . . . . . . . . . . . 2.3 Eigenschappen . . . . . . . . . . 2.4 Aggregatiefunctie . . . . . . . . .

6 6 7 7 8

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3

Multidimensionale analyse 8 3.1 Query-talen uit de database-theorie . . . . . . . . . . . . . . . . . . 9 3.2 De basis-operaties van OLAP . . . . . . . . . . . . . . . . . . . . . 10 3.3 OLAP-navigatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4

Naar ge¨ıntegreerde metamodellen 4.1 Onnodige duplicatie van metadata . . . . . . 4.2 Het Common Warehouse Metamodel (CWM) 4.2.1 OMG’s metadata-architectuur . . . . 4.2.2 CWM’s metamodellen . . . . . . . . 4.2.3 OLAP-metadata in CWM . . . . . . 4.2.4 Evaluatie van CWM . . . . . . . . .

5

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Naar universele query-talen en OLAP-API’s 5.1 De OLE DB for OLAP- (ODBO) en de XML for Analysis-API (XMLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Multidimensional Expressions (MDX) . . . . . . . . . . . 5.1.2 Vergelijking tussen ODBO en XMLA . . . . . . . . . . . 5.2 Java OLAP (JOLAP) . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

13 13 14 14 15 16 17 17

. . . .

18 18 20 20

6

Naar een integratie van OLAP en data mining 6.1 Situering van OLAP en data mining . . . . . . . . . . . . . . . . . 6.2 Het terugkoppelen van data mining-patronen als business rules . . . 6.3 Ontdekkingsgedreven multidimensionale analyse . . . . . . . . . .

21 21 22 24

7

Conclusie

25

2

1

Inleiding

Dat bedrijven heden ten dage gebukt gaan onder enorme informatiestromen is genoegzaam bekend. Automatisering en telecommunicatie, maar ook fusies en overnames hebben deze informatiestromen de laatste jaren alleen maar doen aanzwellen. Het mag dan ook geen verwondering wekken dat vooral grote bedrijven de laatste jaren aanzienlijke inspanningen geleverd hebben op het vlak van data-integratie en data warehousing – getting the data – en in Business Intelligence – analysing the data –, om deze gegevensstromen beheersbaar te houden en te kunnen aanwenden bij het nemen van tactische en strategische beslissingen. OnLine Analytical Processing (OLAP) is e´ e´ n van de de meest populaire analysemethoden voor grote hoeveelheden cijfermateriaal is. Het doel van OLAP is het uitvoeren van multidimensionale analyses. Kort gezegd laat OLAP toe de meetwaarden in een multidimensionale database vanuit verschillende dimensies en op een verschillend aggregatieniveau te belichten. OLAP-analyses bestaan uit zeer eenvoudige query’s en berekeningen. Desalniettemin is OLAP zonder twijfel de killer application van de BI-software industrie te noemen. Argumenten hiervoor zijn de expansieve groei die de OLAP-markt de laatste jaren gekenmerkt heeft [13] en de vele afgeleide software-producten die rond OLAP ontstaan zijn.

1.1

Definitie van OLAP

Hoewel multidimensionale analyse teruggaat tot de jaren 1960 met de mathematische programmeertaal APL, kan men stellen dat OLAP pas in de jaren 1990 een rol van betekenis is gaan spelen in de bedrijfswereld. De term OLAP werd in 1993 door Codd ge¨ıntroduceerd in een commerci¨ele whitepaper [4], en was bedoeld om gegevensanalyses in contrast te stellen met OnLine Transaction Processing (OLTP). De FASMI-test van Pendse [13] geeft echter beter weer wat in het algemeen met OLAP bedoeld wordt. FASMI staat voor: • Fast. Daar waar query’s in operationele systemen voor OnLine Transaction Processing (OLTP) hooguit enkele records beslaan, is het niet uitzonderlijk dat OLAP-query’s praktisch alle records in de OLAP-database beslaan. Desondanks moeten OLAP-query’s op snelle, interactieve wijze uitgevoerd kunnen worden. • Analysis. Het doel van OLAP is in de eerste plaats het uitvoeren van ad hoc, multidimensionale gegevensanalyses. OLAP is in principe minder geschikt voor het maken van lange en gedetailleerde rapporten. In sectie 3 wordt verder toegelicht uit welke basisoperaties multidimensionale analyse bestaat. • of Shared. De gegevens in OLAP-systemen zijn voor meerdere gebruikers toegankelijk. Daarom moet OLAP zorgen voor authentificatie, autorisatie en

3

confidentialiteit. • Multidimensional. Multidimensionaal is het kernwoord in OLAP. Dit begrip verwijst naar de multidimensionale gegevensstructuur van een OLAP-kubus. In de volgende sectie wordt deze gegevensstructuur in detail toegelicht. • Information. Deze informatie bestaat uit numerieke gegevens, cijfermateriaal, die afkomstig zijn van operationele systemen en die via OLAP aan een multidimensionale analyse onderworpen worden. De hoeveelheid cijfermateriaal die een OLAP-systeem aankan, is een belangrijk kenmerk van dit systeem.

1.2

Situering van OLAP in de BI-omgeving

Hoewel het er nauw mee verbonden is, onderscheidt OLAP zich van het data warehousing-, rapportering- en balanced scorecard-gebeuren. Inmon definieert een data warehouse als een subjectgeori¨enteerde, ge¨ıntegreerde, niet-volatiele, tijdsafhankelijke gegevensbron [7]. Een data warehouse integreert aldus de gegevens uit meerdere operationele databronnen in een consistent geheel. Hoewel data warehouses vaak een multidimensionale structuur hebben, in de vorm van sterschema’s, is multidimensionaliteit geen defini¨erende voorwaarde, zoals dat wel het geval is voor OLAP. Daarnaast is ook de snelheid waarmee data warehouse met query’s omgaat van secundair belang, terwijl dit voor OLAP van primair belang is. OLAP-kubussen worden vaak aangemaakt op basis van de gegevens die zich in data warehouses bevinden. Daar waar OLAP ontwikkeld is voor het uitvoeren van eenvoudige, ad hoc analyses door hoofdzakelijk business users worden rapporteringsomgevingen in BI gebruikt voor het aanmaken van gedetailleerde en complexe rapporten, die weliswaar bedoeld zijn voor business users maar die door IT-experten gedefinieerd moeten worden. In een BI-context worden rapporterings-query’s vaak rechtstreeks op de data warehouse uitgevoerd. Een balanced scorecard is een gepersonaliseerde lijst van zogenaamde Key Performance Indicators die een werknemer van een bedrijf toelaten zich een beeld te vormen van die deelaspecten van de bedrijfsvoering waar hij medeverantwoordelijk voor is. Balanced scorcard-applicaties helpen in de eerste plaats bij de communicatie van bedrijfsstrategie, omdat ze aan werknemers duidelijk maken welke meetwaarden relevant zijn voor het realiseren van een bepaalde strategie – in deze context hoort men vaak het devies: what gets measured, gets managed. De meetwaarden van balanced scorecards worden vaak gehaald uit vooraf aangemaakte OLAPkubussen. In figuur 1 zijn de gegevensstromen voor een typische BI-omgeving

4

weergegeven. Data warehousing-, rapportering- en balanced scorecard-applicaties worden door vendors vaak gebundeld in zogenaamde BI-suites. MD analysis

balanced scorecarding

management cockpit

A A A

A

OLAP CUBE

A

REPORT

Patterns

data mining

cube building

reporting

data warehouse ETL spread sheets

...

flat files OLTP databases

Figuur 1: De gegevensstromen in een typische BI-omgeving

1.3

Naar een doorgedreven integratie

Uit bovenstaande situering, blijkt hoe OLAP zich onderscheidt van de andere componenten die deel kunnen uitmaken van BI-suites. Toch hangt het succes van OLAP niet zozeer af van diens eigen functionaliteit, maar ook van de mate waarin OLAP zich integreert met deze andere componenten. Het mag dan ook geen verwondering wekken dat deze componenten steeds beter naar elkaar toegroeien. In dit artikel worden drie aspecten beschreven die wijzen op deze tendens naar een doorgedreven integratie. Een eerste aspect is de evolutie naar een gemeenschappelijk metadatabeheer, dat de duplicatie van metadata in BI-suites moet tegengaan. Vervolgens wordt ingegaan op de universele OLAP-query-talen en API’s die de laatste jaren gespecificeerd werden. Een laatste aspect zijn de integratiemogelijkheden tussen data mining en OLAP.

5

2

Het multidimensionaal gegevensmodel

Hoewel de eerste OLAP-implementaties reeds dateren uit het begin van de jaren negentig, bestaat er tot op heden geen algemeen aanvaard logisch OLAP-gegevensmodel. Wat er wel bestaat, is een populaire metafoor voor OLAP waar vele gegevensmodellen naar verwijzen. Deze metafoor is de (hyper)kubusmetafoor. In deze sectie wordt de intu¨ıtie van OLAP-gegevensmodellen aangereikt via de bespreking van de bouwstenen van deze metafoor.

2.1

Dimensies en cellen

Multidimensionale gegevensverzamelingen laten toe meetwaarden voor te stellen volgens verschillende dimensies en op verschillende niveaus van detail. De logische structuur van deze gegevensverzamelingen is opgebouwd uit cellen met numerieke attributen die de meetwaarden voorstellen en ribben met groepen van categorieattributen die de dimensies voorstellen. Op basis van de categorieattributen van de dimensies kunnen de meetwaarden dan geselecteerd en gegroepeerd worden. Het geheel van cellen en hun verschillende dimensies vormt op deze manier een (hyper)kubus. De voorbeelden in dit artikel hebben betrekking op een multidimensionale analyse van omzetcijfers. Figuur 2 geeft de kubus SalesCube weer. Deze heeft kubus drie dimensies: Time, Product en Customer. De cellen in deze kubus bevatten het gerealiseerde omzetcijfer voor een bepaalde maand, product en klant. Het schema van deze kubus zou men als volgt kunnen voorstellen. SalesCube(Time,Product,Customer):h Turnoveri

... ... ... .... ..... ..... ..... ... ...... ..... ..... ..... ..... ..... ..... . . . . . . . . . . . . . .... .. ..... ..... ..... ..... ..... ..... ..... ..... 19 ... ..... ..... ..... ..... ..... ..... ..... ..... ..... Customer1......................... .... ..... ..... ..... . . . . . . . . . . . . . . . . ... .. ... ... ... ... ..... ..... 342 ... ..... ..... ..... ..... . . 97 76 F renchF ries................. 104 . . . . . . .. . .... ..... ..... 2......... . ..... . ..... ..... Carpet.................. 3456 3457 3461 ..... ..... . . . . . . . . ... .... ..... .... ..... 245 .... ... ..... ......... ..... .... .. ..... 3 5 Chocolate................ ..... ..... . . . ..... .... . . . ..... ... ... ..... ... 9457 9261 ..... Beer................ 9656 ... ..... .... .... .... .... . . . ... ... ........ ........ ........ . . . .... Dec N ov Oct ... .. ... ... . ............. ... ...... ... ..... ... ..... . . . . ... .. ... ......... ... ....... .. ... ........................................................................................................................

Customer2..........................

P roduct

Customer

T ime Figuur 2: De OLAP-kubus SalesCube

6

Het multidimensionale gegevensmodel is echter zeer algemeen en leent zich tot de analyse van allerhande cijfermateriaal, dat vanwege diens hoge dimensionaliteit snel onoverzichtelijk wordt. Grote ondernemingen gebruiken OLAP bijvoorbeeld voor de planning, budgettering en analyse van de boekhoudkundige cijfergegevens – voor inter-groepstransacties gecorrigeerd – van al hun dochterondernemingen. Dergelijke OLAP-kubussen hebben het volgende schema. BalanceSheets(BalanceSheetItem,FinancialUnit,Time):h Realized,Projectedi. IncomeSheets(IncomeSheetItem,FinancialUnit,Period):h Realized,Budgetedi.

Ook bij het meten en beheersen van allerhande kosten kan OLAP goede diensten bewijzen. Onderstaande kubus is een schema voor de analyse van loonkosten. SalaryCosts(SalaryItem,BusinessUnit,Employee,Period):h Costi.

Een ander voorbeeld is de analyse van de opbrengsten en verliezen van allerhande portefeuilles zoals beleggingen en verzekeringscontracten. InsuranceContracts(Policy,Customer,Period):h Premia,Claimsi.

2.2

Hi¨erarchie¨en

De dimensies van een dergelijke kubus zijn geassocieerd met een hi¨erarchie die het aggregatieniveau of de granulariteit van de meetwaarden in een dimensie bepalen. Om van een hi¨erarchie te kunnen spreken moet deze minstens bestaan uit twee of meerdere niveaus. Elk niveau bestaat uit juist e´ e´ n categorieattribuut dat de categorie¨en van dit niveau aangeeft. Omdat de bladknooppuntcategorie¨en van een dimensie op meerdere manieren kunnen worden gegroepeerd, is het niet ondenkbaar dat met een dimensie meerdere drill-down-paden zijn geassocieerd. Merk overigens ook op dat een categorie van een subniveau niet noodzakelijk moet overeenkomen met juist e´ e´ n categorie van het bovenliggende niveau. In dit geval is er een begrenzingprobleem tussen deze hi¨erarchische niveaus. In figuur 3 is het schema van de dimensie Time weergegeven. Deze dimensie heeft twee drill-down paths, namelijk year → month → week en year → quarter → week. Merk op dat er een begrenzingsprobleem optreedt tussen de niveaus week en month, dat kan opgelost worden door een lager niveau day te introduceren.

2.3

Eigenschappen

In een multidimensionale analyse is men vaak enkel ge¨ınteresseerd in een beperkt aantal categorie¨en die tot een bepaald niveau behoren. Daarom laat OLAP, zie bijvoorbeeld de OLE DB for OLAP-specificatie (ODBO) [10], toe om eigenschappen toe te kennen aan de dimensieattributen die met een bepaald hi¨erarchisch niveau geassocieerd zijn. Deze eigenschappen kan men dan in query’s gebruiken om enkel de relevante categorie¨en te selecteren.

7

all ... . ......... .. .... .......... .......... .......... .......... ........... . . . . . . . . . . ...........

quarter ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ........ .......

year.

...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ........ .......

week

...... .......... ........... ........... .......... . . . . . . . . . . ..... ..............

month

Figuur 3: De hi¨erarchie geassocieerd met de dimensie Product

Binnen een dimensie Customer zou men bijvoorbeeld aan het categorieattribuut CustomerName de booleaanse eigenschap Children kunnen toevoegen. Op basis van deze eigenschap kan men dan in de analyses filteren op die klanten die al dan niet kinderen hebben, zonder dat dit blijkt uit de hi¨erarchische structuur van de dimensie Customer.

2.4 Aggregatiefunctie De manier waarop meetwaarden langsheen de niveaus van een dimensie worden geaggregeerd wordt vastgelegd door de aggregatiefunctie die op die meetwaarde van toepassing is. Voorbeelden van aggregatiefuncties zijn sum, count, average, rank, enzovoort.

3

Multidimensionale analyse

Daar waar query’s in relationele query-talen een transformatie zijn tussen tweedimensionale brontabellen en een tweedimensionaal query-resultaat, zijn multidimensionale query’s een transformatie tussen een multidimensionale bronkubus en een multidimensionaal query-resultaat. Althans in dit opzicht lijken multidimensionale query-talen een veralgemening van relationele query-talen. Toch zijn de multidimensionale query’s die men bij OLAP-analyses gebruikt, veel eenvoudiger dan de soms complexe samengestelde query’s die men in SQL tegenkomt. Deze eenvoud volgt uit de doelstellingen van OLAP. Het objectief van OLAP is immers het uitvoeren van multidimensionale analyse aan de hand van point-andclick-operaties op een navigatiescherm, dat eenvoudige berekeningen zoals calculated measures en eenvoudige bewerkingen als slice en dice, drill-up en drill-down en pivot en nest moet toelaten. Voor complexe berekeningen en geavanceerde rapporten is OLAP veel minder geschikt. Deze zaken kunnen met spreadsheets, SQL en specifieke programma’s gerealiseerd worden. In deze sectie worden een aantal

8

multidimensionale query-talen uit de database-theorie toegelicht en aangewend om er de basisoperaties van OLAP mee te illustreren.

3.1

Query-talen uit de database-theorie

In database-theorie deelt men query-talen naargelang hun verschijningsvorm op in drie taalfamilies [1]: algebra¨ısche, logische en regelgebaseerde talen. Algebraische query-talen verschaffen eenvoudige algebra¨ısche operaties voor het manipuleren van de gegevensstructuren waaruit databases zijn opgebouwd. Omdat algebra¨ısche query’s bestaan uit een sequentie van basisoperaties die het antwoord op een query opbouwen, noemt men deze talen prescriptief. Agrawal et al. stellen een algebra¨ısche query-taal voor multidimensionele databases voor, die net zoals relationele algebra gestoeld is op rigoureuze mathematische grondvesten [2]. Een tweede familie van query-talen is gebaseerd op logica. Relationele calculus, bijvoorbeeld, is gebaseerd op predikatenlogica van de eerste orde. Query’s in relationele calculus zijn omzetbaar in relationele algebra via Codd’s reductiealgoritme, maar hebben in tegenstelling tot algebra een descriptief karakter. Cabibbo et al. beschrijven een logische, multidimensionele query-taal en noemen deze MD-CAL [3]. In databasetheorie bestaat er ook een derde taalfamilie, de regelgebaseerde query-talen, die hun oorsprong vindt in logisch programmeren. Net als de logische taalfamilie zijn ook deze talen gebaseerd op eerste of hogere orde predikatenlogica. Omdat regelgebaseerde query-talen de kern zijn van deductive databases, worden deze ook wel deductieve query-talen genoemd. Net als logische query-talen zijn regelgebaseerde query-talen van nature descriptief. Datalog is een bekende regelgebaseerde, relationele query-taal [1]. Hacid et al. stellen een regelgebaseerde taal voor de manipulatie van multidimensionale gegevensbronnen voor die sterk gelijkt op Datalog en die verder in de tekst Multi-D Datalog genoemd wordt [6]. In dit artikel wordt Multi-D Datalog gebruikt om de basisbewerkingen van OLAP te illustreren. Het gegevensmodel in Multi-D Datalog bestaat uit predikaten, die overeenstemmen met de cellen in een OLAP-kubus op hun verschillende aggregatieniveaus. Een predikaat wordt als volgt weergegeven: N (N1 , N2 , ..., Np ):hNp+1 , ..., Np+q i, waarbij een cel wordt ge¨ıdentificeerd door een celreferentie N (N1 , N2 , ..., Np ) waarmee een unieke celinhoud hNp+1 , ..., Np+q i geassocieerd is. Een dergelijke uitdrukking in Multi-D Datalog is de kleinse uitdrukking die waar of vals oplevert. N legt de naam van het predikaat vast. De argumenten N1 , N2 , ..., Np van een predikaat kunnen zowel constanten als variabelen zijn. Analoog met Prolog worden variabelen met een hoofdletter voorgesteld en constanten met een kleine letter. Intu¨ıtief is een

9

term N (n1 , n2 , ..., np ):hnp+1 , ..., np+q i te interpreteren als volgt: “er bestaat een cel met celreferentie N (n1 , n2 , ..., np ) in de kubus N die de meetwaarden hnp+1 , ..., np+q i bevat.’’ De kubus uit figuur 2 heeft in Multi-D Datalog het volgende schema SalesCube(Time,Product,Customer):h Turnoveri en bestaat uit de volgende verzameling van termen: [SalesCube(oct,french fries,customer1):h 104i, ..., SalesCube(dec,beer,customer1):h 9261i]

Net zoals in Datalog kan men query’s formuleren aan de hand van de implicatie-operator ←. Het predikaat in het rule head, de conclusie van de regel, dient men dan te beschouwen als het query-resultaat, de predikaten in het rule body, de premissen van de regel, als de bronkubussen. Alle tupels die door een regel gegenereerd worden, worden in dit query-resultaat opgenomen. In Multi-D Datalog ziet een typische regel ziet er als volgt uit: p(X):hWi← q(X,Y):hWi, r(Y):hXi

Deze regel moet verstaan worden als: als er in de OLAP-kubus q een cel met celreferentie q(X,Y) bestaat die W bevat, en als er in de OLAP-kubus r een cel met celreferentie r(Y) bestaat die X bevat, bestaat er in de OLAP-kubus p, het queryresultaat, een cel met celreferentie p(X) die W bevat. Met behulp van deze taal zullen we nu de basisoperaties binnen OLAP, namelijk slice en dice, drill-up en drill-down en pivot, voorstellen.

3.2

De basis-operaties van OLAP

Multidimensionale analyse met OLAP verloopt aan de hand van point-and-clickoperaties op een navigatiescherm, waarbij de gebruiker het perspectief op de OLAPkubus voortdurend wijzigt aan de hand van vier basisoperaties, namelijk slice en dice, drill-up en drill-down en pivot en nest. De query-resultaten worden door OLAP-client voorgesteld aan de hand van kruistabellen of grafieken. De bewerkingen Slice en dice bestaat erin de OLAP-kubus in schijfjes en blokjes versnijden door in het query-resultaat e´ e´ n of meerdere dimensies tot enkele bepaalde dimensiecategorie¨en te beperken. In onderstaande query wordt het queryresultaat op de kubus SalesCube beperkt tot de maand december. In figuur 4 is het resultaat van deze query in een nieuwe kubus weergegeven. QueryResult1(Time,Product,Customer):h Turnoveri ← SalesCube(Time,Product,Customer):h Turnoveri Time = Dec

10

. ..... ..... ... ...... ..... ..... ..... . . . . . . . . . .... 19........ ..... ..... ... ... ...... ..... ..... Customer1.......................... ..... ..... ..... . . . ..... . . . . . . . . ..... ..... 342 . . . ..... . .. ... ..... ..... 76 F renchF ries................ ..... . .... . . . . . . .... ..... 2 ........ ..... .. . ..... ..... Carpet.................. 3461 ..... ..... ..... ..... . . . . ..... ..... 245 . . . . ..... . ... ..... ..... 5 Chocolate................ ..... ..... . . . . . . .... ..... ..... ... ..... ..... Beer................ 9261 ..... . . . . .. ...... ....... .

Customer2..........................

Dec

Figuur 4: De slice-bewerking op de kubus SalesCube

De operaties drill-up en drill-down worden gebruikt om op te klimmen en af te dalen langsheen een dimensie van de kubus. Op deze manier kan men de meetwaarden in een grover of fijner niveau van detail bestuderen. Onderstaande query verandert het perspectief op de kubus SalesCube door het niveau van de dimensie Time van maandniveau naar kwartaalniveau te brengen. De hi¨erarchische structuur wordt aangegeven door middel van het predikaat in(M onth, Quarter), dat welke maanden tot welk kwartaal behoren. Het predikaat sum(T urnover, SalesCube(Quarter, P roduct, Customer)) sommeert de meetwaarden T urnover van alle cellen die tot eenzelfde kwartaal behoren. Deze speciale predikaten noemt Marcel aggregate subgoals [9]. In figuur 5 is het resultaat van deze query in een nieuwe kubus weergegeven. QueryResult2(Quarter,Product,Customer):h Tsumi ← SalesCube(Month,Product,Customer):h Turnoveri Tsum = sum(SalesCube(Quarter,Product,Customer)) in(Month,Quarter)

..... ... ...... .. . . . . .... ... ...... Customer1.......................... . .....

Customer2..........................

...

F renchF ries................. . Carpet.................. ... Chocolate................ ...

Beer.................

277 10374 8 28374 . ..... ........ .

... ..... ..... ..... ..... . . . . .. 19........ ..... .... ..... ..... ..... . . ..... . . . .....342..... . . ..... . .... .... ..... ..... ..... ..... ..... ..... .... ..... 2 ........ . . . . . .... ..... ..... ..... ..... .... .. ..... ..... ..... ..... 245 . . . . ..... . ..... ..... .... .... . . . . . . . . ... ... ..... ..... ..... ..... .....

Q4

Figuur 5: De drill-up-bewerking op de kubus SalesCube

De operatie pivot bestaat erin de dimensiestructuur van een query te wijzigen door de OLAP-kubus te projecteren op geherori¨enteerde dimensie-assen. Veronderstel bijvoorbeeld dat men in een tweedimensionaal perspectief met dimensies Time en Product de dimensie Product vervangt door de dimensie Customer. Deze bewerking zou het perspectief op de kubus wijzigen van QueryResult3 naar QueryResult4. In figuur 6 zijn de resultaten van deze query’s in kruistabellen weergegeven.

11

QueryResult3(Time,Product):h Tsumi ← SalesCube(Time,Product,Customer):h Turnoveri Tsum = sum(SalesCube(Time,Product,all)) in(Customer,all) QueryResult4(Customer,Time):h Tsumi ← SalesCube(Time,Product,Customer):h Turnoveri Tsum = sum(SalesCube(Time,all,Customer)) in(Product,all)

...

F renchF ries................. . Carpet..................

104

97

95

3456

3457

3803

... Chocolate................ ... Beer................

3

1314

... Oct................

13216

0

.... .......... .

.... .......... .

9457

9506

.... .......... .

.... .......... .

.... .......... .

N ov

608

7

... N ov................

9656 Oct

...

Dec................. 12803

Cust 1

Dec

0

Cust 2

Figuur 6: De pivot-bewerking op de kubus SalesCube

Bij de operatie nest, tenslotte, wordt de dimensiestructuur van een query gewijzigd door de OLAP-kubus te projecteren op dimensieassen waarbij op minstens e´ e´ n dimensieas categorie¨en van meerdere dimensies genest zijn. Om deze operatie voor te stellen gebruikt Marcel de . -operator [9]. In onderstaande query het perspectief op de OLAP-kubus SalesCube gewijzigd door de dimensie Time te nesten in de dimensie Product. Het resultaat van deze bewerking is weergegeven in de geneste kruistabel van figuur 7. QueryResult5(Customer,Product.Time):h Turnoveri ← SalesCube(Time,Product,Customer):h Turnoveri

F renchF ries

...

Dec................. ... N ov................ ...

Oct................. Carpet

...

97

3461

... N ov................

3457

Oct.................

3456

... Dec................

9261

... N ov................ ...

Oct.................

19

104

Dec.................

...

Beer

76

342

245

9457 9656 ...... ....... .

Cust 1

...... ....... .

Cust 2

Figuur 7: De nest-bewerking op de kubus SalesCube

12

3.3

OLAP-navigatie

Eindgebruikers voeren multidimensionele analyses uit aan de hand van een navigatiescherm dat hun OLAP-client-applicatie ter beschikking stelt. Deze clientapplicaties laten de gebruiker toe de gegevens in de OLAP-kubus te projecteren op tweedimensionale kruistabellen of multidimensionale grafieken. Sommige geavanceerde OLAP-clients beschikken over uitgebreide visualisatiemogelijkheden, die bijvoorbeeld toelaten cijfermateriaal te projecteren op geografische kaarten. De meeste OLAP-vendors bieden hun OLAP-client aan in de vorm van een webinterface.

4

Naar ge¨ıntegreerde metamodellen

Zoals vermeld in de inleiding, kan OLAP nog moeilijk los gezien worden van de andere componenten zoals de data warehouse, de rapporteringomgeving, enzovoort die deel uitmaken van heuse BI-suites. Hoewel deze componenten alle beantwoorden aan andere behoeften, is het belangrijk dat deze componenten zo goed mogelijk met elkaar ge¨ıntegreerd zijn. Een belangrijk aspect van de integratie van deze componenten ligt in de integratie van hun metadata.

4.1

Onnodige duplicatie van metadata

In de meeste BI-suites die vandaag op de markt zijn, is er sprake van een onnodige duplicatie van metadata. Zo doen er zich bijvoorbeeld situaties voor waarbij componenten voor OLAP en rapportering beide gebruik maken van dezelfde gegevens in een data warehouse, maar toch afzonderlijke metadata over deze data warehouse bijhouden. Nochtans hebben deze componenten heel wat metadata gemeenschappelijk. Zo beschikken beide componenten typisch over metadata over de relationele verbanden tussen de feiten- en dimensietabellen in de data warehouse, over de hi¨erarchische structuur van de dimensietabellen, over uniforme – en eventueel meertalige – business-naamgeving van data warehouse-objecten, over gebruikersautorisatie, over business rules voor de berekening van afgeleide meetwaarden, enzovoort. Eenzelfde besluit zou men ook kunnen nemen wanneer men de metadata waar ETL-tools over beschikken in de vergelijking binnen zou brengen. Deze duplicatie van metadata is betreurenswaardig, omdat deze leidt tot dubbel werk in een BI-omgeving die reeds geplaagd wordt door erg arbeidsintensieve processen. De oplossing voor deze duplicatie van metadata bestaat er in te zorgen voor geintegreerde metamodellen voor alle BI-componenten, die toelaat gemeenschappelijke metadata te hergebruiken in een wisselende context. Voorbeelden van ge¨ıntegreerde metamodellen voor data warehouse- en OLAP-componenten kan men reeds

13

terug vinden bij IBM, dat met Cube Views een multidimensionaal metamodel bovenop DB2’s relationele metamodel plaatst, en bij Microsoft, dat een zogenaamd Unified Dimensional Model voorziet voor de Analysis Services-component van SQL Server 2005. Het Common Warehouse Metamodel (CWM) [12] is echter een meer algemeen, en bovendien vendor-onafhankelijk, metamodel dat bestaat uit ge¨ıntegreerde metamodellen voor relationele, multidimensionale en XML-gegevensbronnen, ETLprocessen, OLAP, data mining-analyses, enzovoort. De metamodellen van CWM werden tot nog toe door weinig BI-vendors aangewend. Niettemin verdient deze standaard, omwille van zijn metadata-architectuur en de draagwijdte van diens metamodellen, een bespreking in dit artikel.

4.2

Het Common Warehouse Metamodel (CWM)

Metadata laat zich het eenvoudigst defini¨eren als informatie over data. In een OLAP-context, bijvoorbeeld, bestaat metadata onder andere uit informatie over de dimensies, categorie¨en, hi¨erarchi¨en, eigenschappen en meetwaarden waaruit een OLAP-kubus is opgebouwd. Deze metadata is noodzakelijk voor het bouwen van query’s op OLAP-kubussen of voor het aanmaken en beheren van nieuwe OLAPkubussen. Rond metadata hebben zich de laatste jaren twee belangrijke standaardisatiebewegingen voorgedaan. Een eerste standaardisatiebeweging deed zich voor binnen de Metadata Coalition (MDC) rond Microsoft. De MDC bracht eind jaren negentig een algemene metadatastandaard uit die het Open Information Model (OIM) genoemd werd. Een tweede, breed ondersteunde standaardisatiebeweging kwam tot stand onder de auspici¨en van de Object Management Group (OMG). Deze bracht begin 2000 een metadatastandaard uit die specifiek op metadata rond data warehousing gericht is en die het Common Warehouse Metamodel (CWM) [12] gedoopt werd. In juni 2000 besloten de leden van de MDC om zich aan te sluiten bij OMG’s CWM om aldus de realisatie van e´ e´ n universele metadatastandaard mogelijk te maken. 4.2.1

OMG’s metadata-architectuur

In feite is CWM een domeinspecifieke implementatie van OMG’s algemene metadata-architectuur. Deze metadata-architectuur bestaat uit drie andere grote OMGspecificaties: MOF, XMI en UML. 1. OMG’s Meta Object Facility-specificatie (MOF) onderscheidt drie metaniveaus, die in tabel 1 zijn weergegeven. Een eerste metaniveau, het niveau M1, bevat de metadata over de data en objecten van niveau M0. Deze metadata

14

krijgt in MOF-terminologie de benaming model. Het tweede metaniveau, niveau M2, bevat metadata over de modellen van niveau M1. Deze metadata krijgt in MOF-terminologie de benaming metamodel. Het derde niveau, het niveau M3, tenslotte, bevat metadata over de metamodellen van niveau M2. Men spreekt van een meta-metamodel. Dit meta-metamodel is een ontologie die vastlegt hoe domeinspecifieke metamodellen moeten worden gespecificeerd. Het voordeel van een dergelijke ontologie is dat deze domeinspecifieke metamodellen onderling met elkaar in verband kunnen worden gebracht. CWM is in feite niets anders dan een aantal domeinspecifieke metamodellen voor data warehouse- en BI-omgevingen. Naast een meta-metamodel beschrijft de MOF-specificatie een aantal CORBA-IDL-interfaces die een repository moet implementeren voor het aanmaken, opvragen en manipuleren van metamodellen en hun ge¨ınstantieerde modellen. 2. XML Metadata Interchange-specificatie XMI definieert een mapping waarmee MOF-metamodellen in Document Type Definitions (DTDs) en MOFmodellen in XML-code omgezet kunnen worden. Deze omzetting heet model serialization en is een sterke troef van OMG’s metadata-architectuur omwille van de eenvoud en de middleware-onafhankelijkheid van XML. 3. De Unified Modelling Language (UML), tenslotte, is een modelleringstaal waarmee in MOF meta-metamodellen, gedefinieerd en voorgesteld worden. Tabel 1: OMG’s vier-lagige metadata-architectuur

metaniveau M3 M2

benaming

voorbeeld

meta-metamodel metamodel, meta-metadata

M1 M0

model, metadata object, data

4.2.2

CWM’s metamodellen

het ‘‘MOF model’’ UML metamodel, CWM metamodel UML modellen, CWM metadata applicaties, warehouse data

Het Common Warehouse Metamodel (CWM) [12] definieert een kader waarbinnen metadata voorgesteld kan worden omtrent de aanmaak, het onderhoud, het beheer en het gebruik van databronnen, datatransformaties en gegevensanalyses. CWM voorziet in meerdere sub-metamodellen die op hi¨erarchische wijze in UML packages onderverdeeld zijn, zoals afgebeeld in figuur 8. Zo bevat het Resource Package metadatamodellen om objectgeori¨enteerde, relationele, multidimensiona-

15

le, record- en XML-gegevensbronnen voor te stellen. Het Analysis Package bestaat uit metamodellen om datatransformaties en OLAP-, data mining- en visualisatieanalyses voor te stellen. De metamodellen in het Managment Package, tenslotte, stellen metadata over het uitvoeren en beheren van BI-processen voor.

Management

Analysis

Warehouse Process

Transformation

Resource

Object Model

Foundation

Business Information

Relational

Warehouse Operation

OLAP

Record

Data Types Expression

Data Mining

Information Visualization

Multidimensional Keys and Indexes

Type Mapping

Business Nomenclature

XML

Software Deployment

Object Model

Figuur 8: Een overzicht van de sub-metamodellen binnen CWM [12]

4.2.3

OLAP-metadata in CWM

Ter illustratie van de metamodellen binnen CWM, wordt hier het OLAP-metamodel besproken. Het OLAP-metamodel in de CWM-specificatie laat toe om metadata over de beschikbare OLAP-kubussen voor te stellen. Deze metadata kan onder andere door applicaties gebruikt worden om op dynamische wijze query’s aan te maken. De Java OLAP-API [8], bijvoorbeeld, gebruikt de klassen in CWM’s OLAP-metadatamodel als bouwstenen voor de constructie van OLAP-query’s. In figuur 9 zijn de voornaamste klassen en associaties van het OLAP-metamodel weergegeven. De klasse Schema is hierbij de container die alle andere elementen in het OLAP-model bevat. Vanuit dit Schema-object kan rechtstreeks genavigeerd worden naar alle Cube- en Dimensions-objecten die deze container bevat. De klasse CubeDimensionAssociation brengt Cube-objecten in verband met hun gerelateerde Dimension-objecten. Met een dimensie kunnen e´ e´ n of meerdere Hierarchy-objecten geassocieerd zijn. Het schema van dergelijke Hierarchy-objecten is weggelaten in figuur 9, maar kort gezegd bestaan Hierarchy-objecten uit parent-child-relaties van Level-objecten (een subklasse van de klasse MemberSelection), die de Memberobjecten van een dimensie in disjuncte groepen partitioneren. De overige klassen in het klassendiagram van figuur 9, modelleren metadata over de samenstelling van preaggregatie-gedeeltes van een OLAP-kubus.

16

Schema / cube : Cube / dim ens ion : Dim ens ion / deploym entGroup : Deploym entGroup

1

1

* *

Dimension

Cube is Virtual : Boolean / cubeDim ens ionAs s ociation : CubeDim ens ionAs s ociation / cubeRegion : CubeRegion / s chem a : Schem a

is Tim e : Boolean is Meas ure : Boolean / hierarchy : Hierarchy / m em berSelection : Mem berSelection 1 / cubeDim ens ionAs s ociation : CubeDim ens ionAs s ociation / dis playDefault : Hierarchy / s chem a : Schem a

CubeDim ens ionAs s ociation

/ dim ension : Di mension / cube : Cube * / calcHi erarchy : Hierarchy

1

*

*

1

0..1 calcHierarchy

0..1

1

1

dis pla yDefault

0.. 1

Hi erarchy / dimens ion : D imen s ion / cubeDi me ns io nAs s oci ation : Cube Dim ens ionAss oc iation / defaultedDi me ns io n : Di m ens ion

*

* CubeRegion is ReadOnly : Boolean is Full yR eal ized : Bool ean / mem ber Sele ctionGr oup : Memb erSel ectio nGroup / cube : Cube / cubeDeploym ent : CubeD epl oym ent

* MemberSelectionGroup 1

*

/ m em berSelection : Mem berSelection / cubeRegion : CubeRegion

*

MemberSelection / dimension : Dimension / memberSelectionGroup : MemberSelectionGroup 1..*

1 CubeDeployment * {ordered}

/ cubeRegion : C ubeRegion / deplo ym entGr oup : Depl oym entGroup / contentMap : ContentMap

Figuur 9: De voornaamste klassen uit het OLAP-metamodel [12]

4.2.4

Evaluatie van CWM

CWM heeft als doelstelling de integratie van tools voor data warehousing en Business Intelligence (BI) te bevorderen. Enerzijds voorziet CWM in universele metamodellen, die de uitwisselbaarheid van metadata tussen heterogene applicaties ten goede moeten komen en die de basis kunnen vormen voor universele query-talen en Application Programming Interfaces (API’s) – vooral Java-standaarden maken hiervan gebruik. Anderzijds laat CWM toe om metadata over verschillende applicatiedomeinen met elkaar in verband te brengen, en als dusdanig de herbruikbaarheid van metadata te bevorderen. Ondanks deze voordelen kan CWM nog steeds niet rekenen op een grote aanvaarding. De adoptie van CWM is een werk van lange adem. Bovendien blijven vele vendors zweren bij hun eigen metadatastandaarden, in een poging productafhankelijkheid te behouden.

5

Naar universele query-talen en OLAP-API’s

Lange tijd waren OLAP-servers enkel toegankelijk via vendor-specifieke API’s. Deze situatie was betreurenswaardig, omdat deze de ontwikkeling van universele

17

OLAP-software-componenten in de weg stond. Dergelijke universele API’s leiden eveneens tot universele OLAP-clients en vergemakkelijken de toegang tot heterogene OLAP-bronnen vanuit spreadsheets en visualisatie- en balanced scorecardtoepassingen. Het startsein tot standaardisatie werd gegeven door de OLAP Council, een consortium van vele OLAP-vendors, met de in 1998 verschenen MDAPIspecificatie – die echter nadien door geen enkele vendor werd ge¨ımplementeerd. De laatste jaren, echter, heeft Microsoft’s OLE DB for OLAP-API (ODBO) zich als de facto standaard naar voren geworpen. Van deze standaard is trouwens al een opvolger bekend, de op SOAP-gebaseerde standaard XML for Analysis (XMLA). In Java kringen is men bezig met de ontwikkeling van de Java OLAP-specificatie (JOLAP). In feite is de trend naar universele OLAP-API’s een heruitgave van wat zich jaren terug in de database-wereld heeft afgespeeld. Net zoals universele API’s als OLE DB en JDBC in de database-wereld de programmatorische toegang tot relationele databases sterk vereenvoudigd hebben, kunnen enkele recent gespecificeerde API’s hetzelfde bewerkstelligen voor de toegang tot OLAP-kubussen. In de onderstaande paragrafen wordt kort aandacht besteed aan de technische eigenschappen van deze API’s.

5.1

De OLE DB for OLAP- (ODBO) en de XML for AnalysisAPI (XMLA)

De OLE DB for OLAP- (ODBO) [10] en diens opvolger, de XML for Analysisspecificatie (XMLA) [11], defini¨eren beiden een read-only API voor het raadplegen van OLAP-metadata en het uitvoeren van multidimensionale query’s. Beide API’s maken gebruik van de multidimensionale query-taal Multidimensional Expressions (MDX). In essentie is het onderscheid tussen ODBO en XMLA terug te brengen op het communicatieprotocol waarmee OLAP-client en OLAP-server communiceren. ODBO is hierbij gebaseerd op het OLE-protocol – Window’s COM-architectuur – en XMLA baseert zich op SOAP. 5.1.1

Multidimensional Expressions (MDX)

Multidimensional Expressions (MDX) is een multidimensionale query-taal voor OLAP-gegevensbronnen die vastgelegd is in Microsoft’s OLE DB for OLAP-specificatie, en die uiterlijk sterk doet denken aan SQL. Vanwege de grote adoptie door andere OLAP-vendors, is MDX de de facto standaard. Eindgebruikers zullen zelden te maken krijgen met MDX, omdat zij doorheen OLAP-kubussen browsen via een point-and-click navigatiescherm. Niettemin kan de kennis van MDX nuttig zijn voor de programmatorische manipulatie van de gegevens in OLAP-kubussen.

18

MDX-query’s zijn een beschrijving van de structuur van het query-resultaat in functie van de structuur van de bronkubus. Het resultaat van een MDX-query kan uit een willekeurig aantal dimensies bestaan, dit in tegenstelling tot een SQL-query waarvan het resultaat steeds de vorm van een tweedimensionale tabel aanneemt. Algemeen gesproken volgt een MDX-query de volgende syntax. SELECT [ [, ...]] FROM [<cube_specification>] [WHERE [<slicer_specification>]]

In het FROM-gedeelte van de query komt de bronkubus voor, waaruit de gegevens dienen opgehaald te worden. Merk op dat in dit statement steeds juist e´ e´ n bronkubus vermeld staat, omdat MDX, in tegenstelling tot SQL, niet voorziet in join-condities over de gemeenschappelijke dimensies van meerdere kubussen. Om de structuur van een query-resultaat te beschrijven maakt men in MDX gebruik van zogenaamde axis specifications en slicer specifications. Axis specifications bepalen de dimensiestructuur van het query-resultaat en komen voor in het SELECT-gedeelte van de query. Hiertoe bestaat een axis specification uit een set van dimensiecategorie¨en, dimension members genaamd, die verwijzen naar alle categorie¨en die moeten voorkomen op een as van het query-resultaat. Merk op dat in een axis specification slechts dimension members van e´ e´ n en dezelfde dimensie mogen voorkomen. Een Slicer specification is een tupel dat voorkomt in het optionele WHERE-gedeelte van een query en dient om te filteren op bepaalde dimensiecategorie¨en. De dimension members in een slicer specification leggen hierbij op dat de meetwaarden in de cellen van de bronkubus enkel over de vermelde dimensiecategorie¨en mogen geaggregeerd worden. Merk op dat dimensiecategorie¨en van een dimensie nooit tegelijkertijd in zowel een axis specification als de slicer specification kunnen voorkomen. Van dimensies die noch voorkomen in de axis specification, noch in de slicer specification wordt aangenomen dat hun standaardcategorie¨en als slicerdimensies dienst doen. Tenzij anders gedefinieerd zijn standaardcategorie¨en van een dimensie alle dimensiecategorie¨en van het hoogste niveau. Om QueryResult3 te bekomen uit paragraaf 3.2, dient men in MDX een query te defini¨eren waar de maanden en de productnamen op de assen verschijnen – axis specifications –, en waarbij enkel de meetwaarden Turnover gesommeerd worden – slicer specification. SELECT [Time].[Month].Members on AXIS(0), [Product].[Product Name].Members on AXIS(1) FROM SalesCube WHERE [Measures].[Turnover]

19

Merk op dat de concepten axis specification en slicer specification in MDX nauw aansluiten bij de bewerkingen van het navigatiescherm. Pivoting of drilling-up en drilling-down komen hierbij overeen met het wijzigen van de axis specifications, terwijl slicing en dicing overeenkomt met het wijzigen van de slicer specification. 5.1.2

Vergelijking tussen ODBO en XMLA

ODBO en XMLA hebben de query-taal XML gemeenschappelijk, maar verschillen in het communicatieprotocol van de API. ODBO is hierbij gebaseerd op het OLE-protocol – Window’s COM-architectuur – en XMLA baseert zich op SOAP. Deze verschillen hebben gevolgen voor de architectuur van de API’s. Daar waar de OLE DB for OLAP-specificatie typisch leidt tot een fat-clientarchitectuur, maakt de XML for Analysis-specificatie (XMLA) [11] ook thin-clientarchitecturen mogelijk. In dergelijke thin-client-architecturen zijn geen databasespecifieke connectoren aan de client-zijde vereist. Dit wil evenwel niet zeggen dat er geen database-specifieke database drivers meer voorkomen. Dergelijke database drivers kunnen zich echter op een andere locatie op het netwerk bevinden dan de client-applicatie. Men spreekt hier van database adapters. In XML for Analysis wordt een dergelijke database adapter over het netwerk aangesproken via gestandaardiseerde SOAP-requests. De database adapter zal dan vervolgens op een transparante manier verbinding maken met de OLAP-server. XMLA voorziet in twee eenvoudige methodes, namelijk Discover en Execute, waarmee respectievelijk metadata opgevraagd kan worden en MDX-query’s uitgevoerd kunnen worden. Omdat SOAP-programmatie niet eenvoudig is, voorziet Microsoft in een object-wrapper, ADOMD.Net genaamd, die beschibaar is voor de talen van het .Net framework. Deze wrapper biedt een objectmodel aan voor het ontdekken van metadata en het bouwen en verwerken van query’s. Microsoft kondigde ook aan een Enterprise Java Bean-object-wrapper, ADOMD.J genaamd, te voorzien, maar deze is voor zover nagegaan nog niet beschikbaar. Alle hier vermelde protocollen en programmeertalen kunnen in een soort protocol stack geplaatst worden, die in figuur 10 weergegeven is.

5.2

Java OLAP (JOLAP)

Net als OLE DB for OLAP (ODBO) en XML for Analysis (XMLA) is Java OLAP (JOLAP) [8] een API die een programmatorische toegang verschaft tot OLAPservers. De JOLAP-specificatie is echter puur gebaseerd op Java en alle aspecten van de API zijn puur objectgeori¨enteerd. Daar waar de API’s uit de Microsoftwereld een query-taal (MDX) gebruiken, gebruikt JOLAP een objectmodel voor het raadplegen van metadata, het bouwen van query’s en het weergeven van queryresultaten.

20

Java

VB,C#,Delphi...

ADOMD.J

ADOMD.Net

Java, C#, Delphi, ...

SOAP: XMLA HTTP, SMTP, FTP, HTTPs, ...

Figuur 10: De XML for Analysis protocol stack

De JOLAP-specificatie [8] wordt ontwikkeld onder de auspici¨en van Java Community Process (JCP) en wil voor OLAP-systemen worden wat JDBC is voor relationele systemen. Hoewel JOLAP door OLAP-leveranciers als Hyperion, Oracle, SAS, IBM, enzovoort, tot nog toe op lof onthaald wordt, is het nog niet duidelijk of deze specificatie – eens voltooid – ook ge¨ımplementeerd zal worden. Oracle, bijvoorbeeld, ondersteunt de ontwikkeling van JOLAP maar houdt tegelijkertijd diens eigen API, OLAP API, de hand boven het hoofd. Toch is JOLAP het vermelden waard, vanwege zijn vendor-onafhankelijkheid en zijn brede ondersteuning van andere OMG- en Java-standaarden.

6

Naar een integratie van OLAP en data mining

Traditioneel wordt in Business Intelligence onderscheid gemaakt tussen verificatiegebaseerde (OLAP) en ontdekkingsgebaseerde (data mining) analysemethoden. Dit onderscheid – hoe fundamenteel ook – gaat echter voorbij aan de integratiemogelijkheden van beide analysemethoden.

6.1

Situering van OLAP en data mining

Bij verificatiegebaseerde analyse gaat de gebruiker zelf actief op zoek gaat naar patronen of excepties in data. De gebruiker formuleert hiertoe een hypothese die hij vervolgens toetst met de realiteit aan de hand van query’s op een databron. Op deze manier kan de gebruiker nagaan of een door hem vermoed patroon of exceptie ook daadwerkelijk in de gegevens aanwezig is. OLAP- en rapporterings-omgevingen lenen bijzonder goed tot dit soort analyses. Bij ontdekkingsgebaseerde analyse is niet de gebruiker, maar de computer de zogenaamde engine of discovery. De computer is hierbij zelf in staat om patronen in data te ontdekken en om deze op een min of meer begrijpelijke manier voor te stellen aan de gebruiker. In de eerste plaats dienen deze patronen voor het beschrijven van algemene tendensen in data. Daarbovenop kan de gebruiker deze patronen ook nog

21

gebruiken voor het maken van voorspellingen in verband met ongekende of toekomstige fenomenen. Data mining verenigt technieken uit de onderzoeksdomeinen van Machine Learning en Statistiek voor het uitvoeren van deze ontdekkingsgebaseerde analyses. Toch hebben zowel OLAP en data mining elk hun eigen tekortkomingen. Enerzijds is het zo dat Data mining-analyses moeite hebben om de menselijke eindgebruiker op interactieve wijze te betrekken bij het data mining-proces. Deze interactie met een menselijke eindgebruiker is nochtans een cruciale succesfactor voor data mining. Anderzijds is het zo dat OLAP, ofschoon per definitie een interactieve analysemethode, teveel vertrouwen legt in het vermogen van de menselijke eindgebruiker om interessante patronen in gegevens te ontwaren. Door data mining en OLAP beter te integreren kan men enigszins tegemoet komen aan beide tekortkomingen. Bij deze integratie vloeien verificatiegebaseerde (OLAP) en ontdekkingsgebaseerde (data mining) analyses in elkaar over, wat leidt tot een verbeterde interactie tussen mens en machine. Op deze manier doet de machine waar zij goed voor is - namelijk patronen ontdekken - en doet de eindgebruiker waarin hij goed is - namelijk deze patronen valideren en er verdere multidimensionale analyses mee uitvoeren. Sommige OLAP-clients laten toe eenvoudige data mining technieken als regressieanalyses uit te voeren op de resultaten van OLAP-query’s. In de volgende paragrafen beschrijven we echter een meer verregaande integratie van OLAP en data mining.

6.2

Het terugkoppelen van data mining-patronen als business rules

Bedrijfsregels, zogenaamde business rules, zijn op impliciete of expliciete wijze aanwezig in OLAP-kubussen. Voorbeelden van dergelijke bedijfsregels zijn: ‘‘Cash-flow kan berekend worden als de nettobedrijfswinst vermeerderd met alle niet-kaskosten en verminderd met alle niet-kasopbrengsten’’ of ‘‘Belangrijke klanten halen een jaaromzet boven 1 miljoen euro of zijn geaffilieerd met dergelijke klanten.’’ Wanneer dergelijke bedrijfsregels onder de vorm van metadata in een BIomgeving ge¨expliciteerd worden, kan dit aanleiding geven tot nieuwe meetwaarden, dimensies, hi¨erarchische niveaus of eigenschappen in OLAP-kubussen. De met deze bedrijfsregels aangevulde OLAP-kubussen verrijken de multidimensionale analyse. De geldige en bruikbare patronen die data mining-algoritmes genereren, kan men evengoed als bedrijfsregels beschouwen. Voorbeelden van dergelijke bedrijfsregels

22

zijn classificatieregels zoals ‘‘Klanten die aan deze criteria voldoen, zullen met een zekere waarschijnlijkheid overlopen naar de concurrentie’’ of de resultaten van clusteranalyses zoals ‘‘Deze cluster van klanten vertonen grote gelijkenissen naar deze set van attributen.’’ Het levert vaak interessante analyses op, om deze regels toe te passen op de gegevens in OLAP-kubussen ter vorming van nieuwe meetwaarden, dimensies, hi¨erarchische niveaus of eigenschappen. Deze teruggekoppelde data mining-patronen verrijken de multidimensionele analyse die op deze OLAPkubussen uitgevoerd kan worden. Onderstaand voorbeeld voor het terugkoppelen van classificatieregels illustreert dit. Classificatieregels worden gebruikt om te voorspellen tot welke vooraf gedefinieerde, discrete klasse een object behoort. Hiertoe bevat een classificatiemodel als-dan-regels, van de vorm als voorwaarde dan klasse. Classificatieregels zijn vaak stochastisch. Dit wil zeggen dat de regels een kans toewijzen aan alle mogelijke klassen waartoe een object kan behoren. De classificatieregels worden door een algoritme ‘‘aangeleerd’’ op basis van een training dataset waarvan de klasse waartoe de objecten behoren bekend is. Het is echter de bedoeling dat deze regels veralgemeenbaar zijn, zodat ze ook voor de andere objecten uit de testdataset goede voorspellingen opleveren. Churn prediction is een voorbeeld van classificatie waarbij het erop aankomt te voorspellen welke klanten in een bepaalde termijn naar de concurrentie zullen overlopen. Op basis van een training dataset leert een data mining-algoritme classificatieregels aan, die gebruikt kunnen worden om voorspellingen te maken voor de ganse klantenpopulatie. Dergelijke classificatieregels zijn belangrijk voor telecombedrijven en financi¨ele instellingen, waar het overlopen van klanten grote verliezen met zich meebrengt. Indien deze classificatieregels geldige en bruikbare predicties opleveren, kan het zinvol zijn deze regels terug te koppelen naar de OLAP-kubus. Dit kan in de OLAP-kubus van figuur 2 aanleiding geven tot een nieuwe dimensie – of eventueel een nieuw niveau binnen de dimensie Customer – ChurnPrediction, zodat het schema van deze kubus als volgt wijzigt. SalesCube(Time,Product,Customer,ChurnPrediction):h Turnoveri

Deze met data mining-kennis verrijkte OLAP-kubus, kan nu een nieuw soort van multidimensionele analyse uitgevoerd worden, die een antwoord zoekt op vragen als: ‘‘Hoe belangrijk is het aandeel in de omzet van klanten die vermoedelijk naar de concurrentie zullen overlopen? Hoe belangrijk is dit aandeel per abonnementtype? Hoezeer verschillen voorspellingen van de realiteit?’’ Natuurlijk moeten de resultaten van deze analyses, omwille van de onzekerheid die inherent met data mining-analyses verbonden is, met de nodige behoedzaamheid benaderd moet worden. Niettemin laten ze toe om het klantenrisico waaraan een bedrijf onderhevig is, in te schatten en te beoordelen. Op eenzelfde manier kan ook het terugkoppelen

23

van andere data mining-patronen zoals cluster-patronen, associatieregels en regressieverbanden zinvolle multidimensionale analyses opleveren. Het terugkoppelen van patronen uit data mining naar OLAP-kubussen kan wellicht op vele wijzen ge¨ımplementeerd worden. Bovendien kan de discussie evengoed uitgebreid worden naar de terugkoppeling van patronen naar relationele databases, waar deze ge¨ındueceerde regels eveneens een verrijking kunnen vormen van het databasemodel. In de academische wereld behoort het terugkoppelen van bedrijfsregels en het terugkoppelen van uit data ge¨ınduceerde regels naar databases tot het onderzoeksdomein van respectievelijk deductive - en inductive databases. De integratie van (multidimensionele) databases en data mining geeft er aanleiding tot het ontstaan van specifieke – veelal regelgebaseerde – inductieve query-talen [5]. Ook in de software-wereld is er een tendens naar het integreren van uit data geinduceerde regels met databases. De data mining-modellen die aan de basis liggen van deze nieuwe bedrijfsregels worden veelal gemodelleerd met de PredictiveModel Markup Language (PMML). Voorbeelden van integraties tussen databases en data mining vinden we terug bij IBM, waar de integratie tussen Intelligent Miner en DB2 verloopt via User-defined Functions (UDF) die op basis van een PMMLmodel data mining-regels kunnen toepassen op nieuwe data. Microsoft heeft voor de Analysis Services-component van SLQ Server een API bedacht, namelijk OLE DB for Data Mining, die data mining en querying samenbrengt voor zowel relationele als multidimensionale databases. Voor deze API bestaat trouwens een soort inductive query-language, Data Mining Expressions (DMX) genaamd.

6.3

Ontdekkingsgedreven multidimensionale analyse

Sarawagi et al. beschrijven het gebruik van een soort variantieanalyse voor het berekenen van de geanticipeerde waarde van de meetwaarde in een OLAP-kubus [14]. Door deze geanticipeerde waarde te vergelijken met de werkelijke waarde kan men een idee krijgen van de mate waarin deze waarde uitzonderlijk te noemen is. Indien een cel als uitzonderlijk wordt ge¨ıdentificeerd, dan wordt dit als eigenschap van een cel opgeslagen en zal de OLAP-client dit grafisch weergeven. De gebruiker kan dan bij te navigeren doorheen de OLAP-kubus snel een beeld krijgen van anomalie¨en in de gegevens. Het is dan aan hem om zinvolle verklaringen te zoeken voor deze anomalie¨en. Sarawagi et al. noemen de hierboven beschreven manier van werken discoverydriven analysis. Het is een goed voorbeeld van een verbeterde mens-machine interactie, waarbij de machine doet waarin hij goed is -namelijk patronen zoeken- en de

24

mens doet wat hij goed doet -namelijk verklaringen zoeken aan de hand van verdere analyses. Sarawagi et al. stellen dat het opsporen van anomalie¨en een veel gebruikte zoekstrategie is in multidimensionele analyse. Klassieke OLAP-operaties schieten hier echter tekort. Vooreerst is het zo dat de te onderzoeken gegevens vaak erg omvangrijk zijn op gedetailleerde niveaus. Indien men deze data explosie met aggregatie zou willen bestrijden botst men op de tweede tekortkoming. Het is immers waarschijnlijk dat de excepties op detailniveau verborgen blijven door aggregatie, omdat tegengestelde excepties elkaar opheffen of omdat ze niet opvallen tegenover de grootte van de geaggregeerde cijfers. Omdat bij discovery-driven analysis visueel is aangegeven waar zich vermoedelijk uitzonderlijke waarden in de kubus bevinden, kunnen deze excepties echter veel sneller worden opgespoord. Dit idee van discovery-driven analysis werd door IBM gecommercialiseerd in het product OLAP Miner.

7

Conclusie

OLAP is niet langer de stand-alone-applicatie die het was tijdens zijn pioniersjaren. In plaats daarvan is OLAP ge¨evolueerd naar een essenti¨ele component die sterk ge¨ıntegreerd is met de andere componenten van BI-suites zoals ETL-tools, rapporteringsomgevingen, balanced scorecard-applicaties, enzovoort. Deze integratie is onder andere mogelijk gemaakt door de komst van universele API’s en ge¨ıntegreerde metamodellen. Ge¨ıntegreerde metamodellen vermijden de proliferatie van incompatibele metadata doorheen alle componenten van de BI-suite en voorkomen op deze manier dubbel werk bij de definitie van metadata. De komst van universele API’s maken het ontwikkelen van universele OLAP-softwarecomponenten mogelijk en vergemakkelijken de toegang tot heterogene OLAP-bronnen vanuit spreadsheets, visualisatie- en balanced scorecard-toepassingen. Een laatste integratieaspect dat in dit artikel aan bod kwam, is het integreren van met data mining geinduceerde regels met OLAP-analyses. In feite verwijst deze integratie naar een business rules-aanpak van BI. Het combineren van OLAP- en data mining-analyses zorgt voor een betere mens-machine interactie, omdat dit het onderscheid tussen verificatie en ontdekkingsgebaseerde analyse doet vervagen.

Referenties [1] Serge Abiteboul, Richard Hull, and Victor Vianu. Addison-Wesley, 1995. 9

Foundations of Databases.

[2] Rakesh Agrawal, Ashish Gupta, and Sunita Sarawagi. Modeling Multidimensional ˚ Larson, editors, Proceedings of the Thirteenth Databases. In Alex Gray and Per-Ake International Conference on Data Engineering, April 7-11, 1997 Birmingham U.K, pages 232–243. IEEE Computer Society, 1997. 9

25

[3] Luca Cabibbo and Riccardo Torlone. Querying multidimensional databases. In Workshop on Database Programming Languages, pages 319–335, 1997. 9 [4] E. F. Codd. Providing OLAP to User Analysts: an IT Mandate, unpublished manuscript. http://www.hyperion.com, 1993. 3 [5] Luc De Raedt. A perspective on inductive databases. SIGKDD Explor. Newsl., 4(2):69–77, 2002. 24 [6] M. S. Hacid, P. Marcel, and C. Rigotti. A Rule-Based Language for Ordered Multidimensional Databases. In Proc. of the 5th Intl. Workshop on Deductive Database and Logic Programming (DDLP’97), volume 317, pages 69–81, Leuven, Belgium, 1997. 9 [7] W.H. Inmon. Building the datawarehouse. Wellesley, Massachusetts: QED Technical Publishing Group, 1992. 4 [8] Java Community Process. Java Oline Analytical Processing (JOLAP) specification v. 1.0, Final Draft. http://www.jcp.org/en/jsr/detail?id=69, 2003. 16, 20, 21 [9] P. Marcel. Manipulations de donn´ees multidimensionelles et languages de r`egles. PhD thesis, Institut National des Sciences Appliqu´ees de Lyon, 1998. 11, 12 [10] Microsoft. OLE DB for OLAP Specifications. http://www.microsoft.com/data/oledb, 1999. 7, 18 [11] Microsoft and Hyperion. XML for Analysis specification, version 1.1. http://www.xmla.org, 2002. 18, 20 [12] Object Management Group. Common Warehouse Metamodel. http://www.omg.org, 2000. 14, 15, 16, 17 [13] Nigel Pendse. “What is OLAP?”The OLAP Report. http://www.olapreport.com/fasmi, 1995. 3 [14] Sunita Sarawagi, Rakesh Agrawal, and Nimrod Megiddo. Discovery-Driven Exploration of OLAP Data Cubes. Lecture Notes in Computer Science, 1377:168–??, 1998. 24

26