Samenvatting Leerboek Business Intelligence van Peter Ter Braake

Hoofdstuk 1. Inleiding

1.1 Wat is Business Intelligence?

1.1.1 Definitie

BI is een overkoepelende term waarmee applicaties, infrastructuur en hulpmiddelen, en aangeraden werkwijzen worden bedoeld, die als doel hebben om gegevens beschikbaar te stellen ten einde de juiste beslissingen te kunnen nemen op basis van correcte, betrouwbare informatie.

BI is dus in feite een parapluterm waar heel erg veel onder kan vallen. De belangrijkste delen van deze omschrijving zijn de woorden:

1. Informatie
2. Beslissingen

BI draait namelijk om het beter in staat zijn beslissingen te nemen op basis van informatie. Voordat iets informatie is, zijn het alleen nog maar gegevens. Deze gegevens worden informatie wanneer deze gebruikt kunnen worden in de besluitvorming. Een andere omschrijving van BI is Making Better Decisions Faster. BI draait er namelijk om de mensen in een organisatie beter in staat te stellen hun werk te doen. Wanneer zij goed geinformeerd worden zullen ze beter besluiten nemen; daarnaast moet die informatie tot hun beschikking staan op het moment dat ze het besluit moeten nemen.

De BI-oplossing bestaat uit de volgende componenten:

1. Datawarehouse: een centrale database gevuld met gegevens uit 1 of meer aparte bronnen met als doel het maken van rapportages en het uitvoeren van data-analyses.
2. ETL-proces: zorgt voor de juiste vulling van de DWH en daarmee voor de kwaliteit van de rapportages die je maakt en de analyses die je doet.
3. Staging Database: database waarin gegevens tijdelijk worden opgeslagen tijdens het ETL-proces alvorens ze worden overgehaald naar de DWH.
4. Semantisch model: een abstractielaag die betekenis en verbanden toevoegt aan de gegevens in een database; een laag die een vertaalslag doet van een technische implementatie naar logische business entiteiten.
5. Kubus: een meerdimensionale draaitabel en kan beschouwd worden als een semantisch model.
6. Datamining: het gericht zoeken naar (statistische) verbanden in gegevensverzamelingen met als doel profielen op te stellen voor wetenschappelijk of commercieel gebruik; het zoeken naar patronen in gegevens op basis van wiskundige modellen.
7. Machine Learning: een toepassing van AI waarmee systemen automatisch leren op basis van ervaring (gegevens uit het verleden) zonder expliciet geprogrammeerd te worden.
8. Big data; datasets waarbij de hoeveelheid aan gegevens, de snelheid van gegevensverwerking en/of de diversiteit van die gegevens een probleem wordt als de gegevens op een klassieke manier worden behandeld.

1.1.2 Van wie is BI?

BI draait om mensen en de beslissingen die zij nemen. Hierbij is gelijk duidelijk dat BI niet van ICT is. Het gevaar zit namelijk niet in het feit dat ICT een rol speelt, maar dat hun rol zo groot en dominant wordt, dat het een project van alleen ICT afdeling wordt. Oftewel ICT is slechts een middel om tot het doel te komen. Het doel van BI is voornamelijk: competitief voordeel behalen en organisaties slimmer te kunnen laten werken.

Wanneer een BI oplossing niet in de juiste informatie voorziet bij het maken van de juiste beslissingen is het project mislukt. Ook als de BI oplossing niet gebruikt wordt is het project mislukt. Om ervoor te zorgen dat mislukte projecten zo weinig mogelijk voorkomen, moeten de eindgebruikers vanaf het begin betrokken zijn.

1.1.3 Voor wie is BI?

BI is voor iedereen. Het is zowel interessant voor grote als voor kleine bedrijven. Het is in elke branche interessant. Binnen een bedrijf biedt het meerwaarde aan alle soorten functies, van hoog tot laag.

In vroegere implementaties, toen de term BI nog niet in zwang was, werd er voornamelijk gesproken over Decision Support Systems (DSS).

Vroeger werd er gesproken van Decision Support Systems (DSS). De informatie die uit dit system kwam, was vaak hoog geaggregeerd. De informatie die eruit kwam was voornamelijk stuurinformatie voor het hogere management in de organisatie. Tegenwoordig is de informatie beschikbaar voor alle lagen binnen de organisatie, want iedereen binnen de organisatie moet wel eens een beslissing nemen.

1.1.4 Self Servic BI

Binnen een BI-project zul je 2 zaken minimaal moeten overwinnen:

1. Is de BI-oplossing die gebouwd wordt wel wat de gebruikers nodig hebben?
2. Komt de oplossing wel op tijd?

Self Service BI, waar de gebruikers zelf hun benodigde informatie maken, kan hierbij helpen. Informatieanalyse is het achterhalen wat de behoeftes, wensen en eisen van de beoogde eindgebruikers van een systeem zijn. Een veelgebruikte informatieanalyse techniek is voeren van interviews. Je moet hierbij wel open vragen stellen. Wanneer je vragen stelt tijdens interviews is het heel goed mogelijk dat mensen vinden dat er geen problemen zijn. De redenen waarom mensen zo reageren kunnen het volgende zijn:

1. Toegeven dat je je werk niet optimaal doet is moeilijk
2. Angst voor het onbekende
3. Onwetendheid over de mogelijkheden
4. Miscommunicatie

Met Self Service BI is het mogelijk om mensen wel over te halen om nieuwe zaken uit te vinden. Laat de gebruikers zelf beginnen, voordat je vragen gaat stellen. Een ander probleem wat ook kan ontstaan is het moment waarop de oplossing door de gebruikers toegepast gaan worden. Sluit alles nog wel aan bij de eisen van de gebruikers? Dit zijn zaken waar je ook rekening mee moet houden. Self Service BI draait om het in staat stellen van eindgebruikers om zelf in hun informatiebehoefte te voorzien zonder anderen te vragen oplossingen voor ze te bouwen ten einde de juiste informatie op het juiste moment ter beschikking te hebben.

1.1.5 Waarom BI?

BI gaat erom de mensen binnen een organisatie beter hun werk te laten doen, waarmee de organisatie als geheel beter wordt. Goede, accurate, tijdige informatie kan het verschil maken tussen succes en faillissement. BI is iedereen in een organisatie op het juiste moment van de juiste informatie te voorzien met als doel competitief voordeel te behalen door verbeterde besluitvorming te realiseren

1.2. Andere terminologie en definities

1.2.1 Datawarehouse

Een DWH is een centrale database gevuld met gegevens uit 1 of meer aparte bronnen met als doel het maken van rapportages en het doen van data-analyse. Een aantal voordelen van een DWH zijn:

• Historische gegevens
• Kwaliteit gecontroleerd
• Verschillende bronnen samenvoegen
• Performance geoptimaliseerd
• Rapportages uit 1 bron

1.2.2 Extract, Transform, Load

Het ETL proces zorgt voor de juiste vulling van het DWH en daarmee wordt de kwaliteit van de rapportages geborgd die je maakt en de analyses die je doet. ETL staat voor Extract, Transform, Load:

• Extract: haal gegevens uit de bronsystemen
• Transform: pas de gegevens aan aan de eisen die het DWH stelt aan de gegevens
• Load: laad de gegevens in het DWH

1.2.3 Staging, ODS

In de praktijk zullen gegevens altijd eerst in een aparte laag, staging database, gezet worden. Dit wordt de staging area of staging database genoemd. Een staging database is een database waarin gegevens tijdelijk worden opgeslagen tijdens het ETL-proces alvorens deze worden overgehaald naar het DWH. Vaak zal er nog een laag van datamarts tussen de lagen worden gemaakt. Een datamart is een deelverzameling van een DWH die specifiek voor een deelgebied van de te maken rapportages wordt gemaakt. Naast staging is ODS, Operational Data Store, ook een veel gebruikte term. Een ODS is de eerste plek waar gegevens landen nadat ze uit het bronsysteem zijn gehaald. Het is een soort staging database.

1.2.4 Kubussen, modellen

Soms kan het gebruik van een DWH niet voldoen aan alle wensen van een organisatie. Er kunnen een aantal problemen optreden zoals:

• Performanceproblemen
• Moeite om goede queries te genereren
• Eindgebruikers willen gemakkelijk en snel op een flexibele, niet vooraf gedefinieerde wjze door de gegevens heen kunnen wandelen

Door gebruik te maken van semantische modellen kunnen deze problemen verholpen worden. Een semantisch model is een abstractielaag die betekenis geeft en verbanden toevoegt aan de gegevens in een database. Een kubus is een semantisch model.

1.2.5 Datamining en machine learning

Datamining is het gericht zoeken naar (statistische) verbanden in gegevensverzamelingen met als doel profielen op te stellen voor wetenschappelijk of commercieel gebruik. Datamining gaat om patroonherkenning. Die patronen kunnen verschillende toepassingen dienen.

Machine Learning is een toepassing van AI waarmee systemen automatisch leren op basis van ervaring (gegevens uit het verleden) zonder expliciet geprogrammeerd te worden.

1.2.6 Big Data

Een DWH is een relationele database. De tabellen en gegevens worden beheerd door een RDBMS. Het levert veel voordelen op rond beheer en consistentie van gegevens. Big Data refereert aan een dataset waarbij voorgaande een issue wordt. Er zijn 3 kenmerken van Big Data die hiermee te maken hebben. Deze zijn:

1. Volume: hoeveelheid gegevens
2. Velocity: verwerkingssnelheid
3. Variety: diversiteit van de gegevens

Big Data refereert aan een dataset waarbij de hoeveelheid van gegevens, de snelheid waarmee die verwerkt moeten worden en/of hun diversiteit een probleem worden als de gegevens op een klassieke manier worden behandeld.

Hoofdstuk 2. Business Intelligence in de organisatie

2.1 BI in de organisatie

2.1.1 Volwassenheid

BI wordt als een volwassen kerncompetentie beschouwd. Lang niet in alle organisaties wordt BI als een kerncompetentie gezien. Bedrijven gebruiken een volwassenheidsmodel om te bepalen hoever ze zijn in het BI proces. Het model bestaat uit de volgende fases:

1. Prenatale fase: geen BI aanwezig.
2. Peuter fase: hier wordt gebruik gemaakt van spreadmarts. Een spreadmart is een decentrale gegevensverzameling , voor eigen gebruik gemaakt door een individu, vaak opgebouwd met behulp van een spreadsheetprogramma.
3. Kind fase: er komt regie in BI en er komt een centrale datamart.
4. Volwassen fase: datamarts worden gevoed vanuit het centrale DWH; het DWH wordt ook wel de Single Version of Truth genoemd.
5. Ontwikkelde fase: er worden gevorderde analyses gedaan en BI is uitgegroeid tot een competentie.

Wanneer een bedrijf in de ontwikkelde fase komt, is het verstandig om gebruik te maken van een Business Intelligence Competence Center. Een BICC is een speciaal multidisciplinair team dat zich volledig richt op het doen van BI binnen de organisatie.

Van kritiek belang van elke BI-implementatie is de acceptatie door de eindgebruikers.

2.1.2 Life Cycle

BI bestaat uit 4 fases die continu in elkaar overlopen. De BI Life Cycle bestaat uit de volgende fases:

1. Analyseren: verbanden zoeken.
2. Verkrijgen van inzicht: conclusies maken op basis van de analyse.
3. Het uitzetten van acties: plannen van veranderingen op basis van het verkregen inzicht.
4. Het meten van de resultaten van de uitgezette acties.

Door het volgen van de BI Life Cycle ontstaat er ook een probleem. Want door het succes van het DWH kan het DWH outdated worden. Daarom is het slim om gebruik te maken van Agile BI. Agile BI refereert aan het gebruiken van Agile softwareontwikkelmethodieken om snel en gemakkelijk te kunnen inspelen op veranderende behoeften vanuit de organisatie.

2.1.3 Ambitie

Om de ambtie van een organisatie te kunnen inschatten wordt gebruik gemaakt van de BI Maturity Matrix. Deze dient 2 doelen, het bepalen waar men nu staat en bepalen wat de ambities ten aanzien van BI zijn. Wanneer beide punten duidelijk zijn, kan er een roadmap gemaakt worden dat ertoe leidt dat de ambitie gerealiseerd gaat worden. Het hoogste ambitieniveau is het behalen van een intelligente organisatie. Informatie en vooral het gebruik van informatie is een integraal onderdeel geworden van de organisatie. De organisatie leert en past zichzelf aan. Innovatie is een belangrijke drijfveer/ambitie. In de intelligente organisatie is BI het gewone werk geworden en is BI van duur project verworden tot kerncompetentie.

2.1.4 Implementatie

De eerste stap bij het implementeren is het bepalen van het doel. Deze moet bepaald worden voor 3 verschillende niveaus:

1. Strategisch niveau: hoogste niveau en behoort tot hoger management. De strategie van een organisatie is de manier waarop een organisatie als geheel denkt haar doelen te gaan behalen. In het kader van dit hoofdstuk betekent strategisch het maken van de keuze welke rol BI speelt binnen de organisatie. Op strategisch niveau spreken we van het richten van BI.
2. Tactisch niveau: gemaakte strategische keuzes ten uitvoer brengen. De roadmap is het stappenplan om de gestelde ambitie te bereiken. Op dit nivau spreken we van het inrichten van BI.
3. Operationeel niveau: het uitvoeren van zaken. Mensen moeten daadwerkelijk gegevens verzamelen en analyseren. Op basis van de opgedane kennis moeten beslissingen genomen worden. Op dit niveau spreken we van het verrichten van BI.

Wanneer iets besloten wordt op het gebied van BI moet aan de volgende aspecten gedacht worden:

• Scope: de scope is het afbakenen wat wel en ook vooral wat niet een onderdeel is van een project. Een deel van de problemen in de informatievoorziening die we proberen op te lossen, komt door onafhankelijke operationele systemen. De BI oplossing moet dus een geintegreerde oplossing zijn. Om de scope te bepalen moet er een globaal procesmodel gemaakt worden. Hierbij kijk je naar welke processen, wie en producten.
• Doelen: bepaling van de doelen en de scope is een iteratief proces. Ze moeten voor alle 3 lagen beschreven worden, en moeten SMART geformuleerd zijn.
• Informatiebehoefte: een informatiebehoefte is de informatie die een werknemer in een bepaalde functie nodig heeft om zijn of haar functie naar behoren uit te voeren. Er zijn een paar zaken waar je naar moet kijken met betrekking tot de informatiebehoefte, namelijk: de doelgroep en de meetwaarden.

Naast scope, doelen en infomatiebehoefte zijn er nog aspecten als bronnen, architectuur en organisatie.

Om vast te stellen welke onderdelen binnen de scope van een BI-project vallen, wordt er gekeken naar de aspecten complexiteit en meerwaarde (subject area analysis). Weinig meerwaarde in combinatie met een hoge complexiteit (kleinere kans van slagen) is de minst aantrekkelijke combinatie. Onderdelen met veel meerwaarde en een geringe complexiteit genieten de voorkeur.

De doelgroep zijn de gebruikers. Bill Inmon definieert 4 soorten gebruikers:

1. Farmers: vaste, terugkerende informatiebehoefte.
2. Tourists: behoefte aan ad hoc informatie en zelf rapporten kunnen aanpassen.
3. Explorers: gaan analyseren en rapporten zijn nog vrij statisch.
4. Miners: proberen patronen in de gegevens te ontdekken.

Bij meetwaarden denken we aan KPI's. Dit zijn kritieke prestatie indicatoren. Een indicator laat in 1 opslag zien of het goed gaat met een bepaald proces. Deze indicator bestaat uit 4 componenten, namelijk meetwaarde, doelstelling, status en trend. De status en de trend geven resp. de afwijking van het doel en het inzicht in de situatie van de vorige periode.

De Balanced Scorecard (Kaplan): het succes van een bedrijf wordt bepaald door meerdere factoren die onder te verdelen zijn in 4 deelgebieden of perspectieven:

• Financieel perspectief: vertegenwoordigt de kijk van financiers en aandeelhouders op de organisatie.
• Klant perspectief: zegt iets over de markt.
• Intern perspectief: werknemers en de processen binnen de organisatie.
• Leer -en groei perspectief (innovatieperspectief): heeft het vizier iets meer op de toekomst gericht.

2.2 BI-Projecten

2.2.1 Geen gewoon IT-project

Een groot deel van een BI-project is ICT gerelateerd. De IT-componenten van een BI-project, zijn slechts een middel om het grotere BI-doel te realiseren. De belangrijkste consequentie van het feit dat een BI-project geen ICT-project is, is dat er niet IT mensen lid moeten zijn van het projectteam. De beoogde eindgebruikers van BI-oplossingen moeten vanaf het begin betrokken worden bij elk BI-project. Bij elk project zijn er een aantal vaste rollen:

1. Projectleider: project leiden.
2. Architect: overall infrastructuur bepalen, high level overview hebben van alle componenten, hun meerwaarde en beperkingen kennen, en de juiste blokjes kiezen om de puzzel te maken.
3. DBA'ers en ontwikkelaars: technische uitvoering.
4. Informatieanalist: gat dichten tussen organisatie en techneuten.
5. Eindgebruikers: acceptatie van het project.
6. Executive Sponsor: aanmoedigen project.
7. Data Steward: eindverantwoordelijk voor de kwaliteit van de informatie.

De data steward is diegene met inhoudelijke kennis van zaken.

Gevaren van een ICT-project: nadruk teveel op de technische kant, dus een benadering vanuit ICT en niet vanuit de organisatie, kan leiden tot:

• Gebrek aan acceptatie. De oorzaken hiervan zijn: niet op het juiste moment voorhanden, niet actueel genoeg, niet relevant, gebruikers doen niks met informatie, gebruikers vertrouwen informatie niet, gebruikers willen er niet mee werken en het is te technisch. Deze problemen kunnen opgelost worden middels vroege betrokkenheid van de gebruikers. Wel kan het management mensen dwingen om mee te werken.
• Niet genoeg in staat om mee te groeien: BI is een continu proces en niet een eindig project. BI is dus geen project maar 1 van de processen binnen een organisatie.
• Te duur en te lang: zonder een goede scope, bepaald door de organisatie, wordt een BI-project onbeheersbaar groot.
• Richt zich teveel op het verzamelen van gegevens.

2.2.2 Informatieanalyse

De informatieanalyse is het proces waarin je achterhaalt wat de doelen zijn en wat de benodigde behoeften zijn om die doelen te realiseren.

Als je een grondige informatieanalyse hebt gedaan, heb je waarschijnlijk een lange lijst van eisen en wensen. Het is niet aan te raden om alles in 1 keer op te pakken. Beperk de scope van het initiele project. Dit heeft namelijk 2 voordelen:

1. het vergroot de kans dat je groen licht krijgt om het project te beginnen;
2. het vergroot de kans op succes.

2.3 Tot slot

BI is dus een continu proces en geen eenmalig project. Een succesvolle BI implementatie zal veel technische aspecten bevatten. Deze technische componenten zijn alleen ondersteunend aan het proces en moeten nooit een doel op zich worden.

BI moet onderdeel zijn van de dagelijkse werkwijze van mensen. Het is een onderdeel van de cultuur van een bedrijf.

In veel BI-implementaties wordt gebruik gemaakt van datamarts en datawarehouses. Ze vormen daarmee wel een belangrijke component van de meeste BI-oplossingen.

Hoofdstuk 3. Waarom een datawarehouse?

3.1 Het datawarehouse

Een DWH is een centrale database gevuld met gegevens uit 1 of meerdere aparte bronnen met als doel het maken van rapportages en het doen van data-analyse. Het is een relationele database. Dat wil zeggen dat de informatie opgeslagen is in de vorm van tabellen. Een DWH is de "single version of truth". Om ervoor te zorgen dat het DWH gebruikt wordt voor rapportages en analyses, moet ervoor gezorgd worden dat alles wat van belang is erin zit en dat iedereen altijd alleen het DWH gebruikt voor het verkrijgen van informatie. De gegevens die je beschikbaar hebt om te gebruiken, bij het vullen van de DWH, zijn vaak onvolledig en van slechte kwaliteit. De volledige waarheid is daarmee misschien buiten je bereik, zolang de organisatie de informatie maar vertrouwd en stuurt als de versie van de waarheid.

Single version of truth: dat bedrijfsregels zoals dat omzet wordt gerekend op de dag dat de factuur betaald wordt en niet op de dag dat de order geplaatst is, vastgelegd zijn in het DWH.

3.1.1 Waarom een DWH?

Je maakt gebruik van een DWH vanwege de mogelijke problemen die kunnen ontstaan als je rapporten en analyses maakt direct op het bronsysteem.

Het is wel zo dat een DWH NIET de basis hoeft te zijn voor elke BI-oplossing.

Een DWH lost de volgende problemen op:

1. Sommige operationele databases houden geen historie van wijzigingen bij.
2. De kwaliteit van de gegevens in operationele databases laat vaak te wensen over.
3. Veel organisaties hebben meer dan 1 operationele database en de informatie uit verschillende systemen is moeilijk te combineren.

3.2 Performance van rapporten

Operationele databases zijn geoptimaliseerd voor een OLTP workload. OLTP staat voor Online Transaction Processing, waarbij het gebruik van de database zich kenmerkt door veel kleine acties waarvan een relatief groot aantal van die acties wijzigingen betreft.

3.2.1 Normaliseren

Databases die een OLTP workload ondersteunen, worden in meer of mindere mate genormaliseerd. Normaliseren van een database voorkomt redundantie en vergroot de consistentie van de gegevens. Voordelen zijn dat de kans op fouten kleiner wordt en dat de database in z'n geheel kleiner blijft. Het schrijven in een database gaat sneller als er minder redundantie in zit. Een alleen lezen workload wordt ook wel een OLAP workload genoemd, OLAP staat voor Online Analytical Processing, waarbij het gebruik van de database zich kenmerkt door voornamelijk lezen. Normaliseren geeft geen voordeel bij een OLAP workload. Een nadeel van normaliseren voor OLAP is dat de benodigde queries moeilijk en traag worden. Wanneer grote hoeveelheden gegevens nodig zijn, zijn genormaliseerde databases slecht voor de performance. Met het bouwen van een DWH heb je de mogelijkheid de gegevens op te slaan in een structuur die geschikt is om snel en adequaat informatie uit een database te lezen.

Normaliseren heeft een aantal effecten:

• Veel verschillende tabellen: om redundantie te voorkomen worden dubbele gegevens in aparte tabellen gezet.
• Tabellen worden klein: tabellen bestaan uit relatief weinig kolommen.

Voor datawarehousing is normaliseren een voordeel omdat de tabelstructuur ongewijzigd kan blijven.

3.2.2 Indexen

Belangrijk voor de performance is de gekozen index-strategie. Er zijn 2 hoofdvormen:

1. Clustered Index: database-engine maakt gebruik van de kennis van de sorteervolgorde om de gevraagde records snel op te halen. Lezen in de database is snel, maar schrijven is traag.
2. Nonclustered Index: verwijzingen naar records zijn gemaakt.

Een datamart of een rapportagedatabase kan indexen bevatten die speciaal voor rapporten en analyses zijn gemaakt. Dit levert verbeterde performance op t.o.v. de bronsystemen en daarmee betere acceptatie.

Indexen maken de database wel groter, maar niet per definitie sneller.

3.3 Schrijven van queries

Veel joins in queries hebben tot gevolg dat de performance van de queries zakt. Daarnaast gaat er vaak tijd verloren tussen het ontstaan van een informatiebehoefte en het invullen daarvan. Dit kan opgelost worden door gebruik te maken van Self Service BI. Om dit te laten slagen hebben mensen de juiste tools nodig en de gegevens moeten op een begrijpelijke manier aangeboden worden. Om dit laatste voor elkaar te krijgen kan er gebruik worden gemaakt van datamarts, deze bieden gebruikers informatie aan in een voor de gebruiker begrijpelijke eenvoudige vorm.

3.3.1 Wie maakt de rapporten?

Als we daadwerkelijk sneller bij de gewenste informatie willen komen, moeten we de mensen die informatie nodig hebben ook in staat stellen bij die informatie te komen. Daar zijn minimaal 2 zaken voor nodig:

1. De mensen moeten de juiste tools krijgen.
2. De beschikbare gegevens moeten op een begrijpelijke manier worden aangeboden.

Datamarts bieden informatie aan gebruikers aan in een voor de gebruiker begrijpelijke eenvoudige vorm.

3.4 Rappportage-impact op het primaire proces

Door het maken van rapportages en analyses gaat de performance van de operationele applicaties achteruit. Er kunnen 2 problemen ontstaan:

1. Gebruik van hardware resources.
2. Gelijktijdig gebruik van dezelfde gegevens.

3.4.1 Resource-gebruik

CPU, maar ook geheugen en storage kunnen een probleem worden. De meeste database systemen proberen zoveel mogelijk gegevens in het geheugen te houden. Grote gegevensverzamelingen kunnen voor het OLTP proces belangrijke gegevens uit het geheugen verdringen waardoor het OLTP trager wordt. Er is een gerede kans dat een BI workload een bottleneck veroorzaakt op de databaseserver als je niet een aparte server inricht voor BI processen.

Een SAN (Storage Area Network) is een populair opslagmedium dat veel gebruikt wordt voor databases.

3.4.2 Concurrency

Concurrency is het tegelijkertijd werken op de database. Rapportages en analyses kunnen grote impact hebben op de performance van operationele processen. De rapportages en analyses loslaten op een DWH lost dit probleem op.

Concurrency levert problemen op indien rapporten zijn gebaseerd op OLTP databases:

1. Grote rapporten kunnen gegevens van anderen uit het geheugen verdrijven.
2. In sommige databases zijn gegevens niet beschikbaar als andere queries die gegevens proberen te wijzigen.

3.5 Kwaliteitsproblemen

De kwalitiet van de gegevens is slecht. De informatie die in de database gezet wordt kan verschillende kwaliteitsproblemen hebben.

3.5.1 Dubbele gegevens

Dubbele records in operationele systemen leiden tot foutieve resultaten tijdens analyses. Doordat een DWH gecontroleerd gevuld wordt door zorgvuldig geteste processen, is het voorkomen van dubbele gegevens in de datawarehouses makkelijker dan in operationele databases.

3.5.2 Ontbrekende gegevens

In operationele databases ontbreken soms gegevens die voor analyse van belang zijn. Tijdens het vullen van een DWH kan dit gedetecteerd worden en kunnen ontbrekende gegevens worden aangevuld of expliciet gekenmerkt worden als onbekend.

3.5.3 Foutieve gegevens

Bepaalde programma's helpen om foutieve gegevens tijdens het laden van het DWH op te sporen en automatisch te verbeteren.

3.5.4 Inconsistente gegevens

Standaardapplicaties geven de vrijheid om voor een organisatie inconsistente informatie op te slaan in de database. Een DWH lost deze inconsistenties niet meteen op. Tijdens het laden van het DWH komen ze waarschijnlijk wel aan het licht. Er ontstaat dan een keuze hoe hiermee om te gaan.

3.6 Verschillende operationele systemen

Informatie uit verschillende databases komt niet overeen. Een bedrijf heeft vaak meer dan 1 database. Als 2 verschillende systemen dezelfde cijfers zouden moeten geven, zal er in de praktijk vaak een verschil tussen beide systemen te zien zijn. Een centrale DWH zorgt voor het gebruik van 1 centrale definitie van termen. Het is van groot belang om tijdens de informatieanalyse te achterhalen of er meer dan 1 definitie gebruikt wordt binnen de organisatie. Eenduidigheid van definities en gegevens is van cruciaal belang voor BI-oplossingen.

3.7 Historische gegevens

Geschiedenis gaat verloren. Wanneer veranderingen optreden, heeft men te maken met Slowly Changing Dimensions (SCD). SCD's hebben betrekking op veranderingen die optreden in de loop van de tijd; het gaat hierbij dan om attributen van dimensies die in de tijd veranderen. Operationele databases houden vaak geen historie bij met betrekking tot wijzigingen. In een DWH kun je dit wel doen. Datawarehouses bieden daardoor uitgebreidere analysemogelijkheden dan operationele databases.

Hoofdstuk 4. Het datawarehouse

4.1 Dimensioneel modelleren

4.1.1 Inleiding

Dimensioneel modelleren is een manier van database ontwerp, die poogt deze tekorkomingen weg te poetsen. Uitgangspunt is dat de database een voornamelijk alleen-lezen workload (OLAP) krijgt. Dimensioneel modelleren leidt tot een database met een zogenaamd stermodel. Een datamart is een database waarvan de tabelstructuur een ster vormt en die 1 proces uit de organisatie beschrijft. In de theorie van Kimball bestaat het DWH uit de verzameling van alle stermodellen die tezamen de processen in de hele organisatie beschrijven. Een stermodel is voor een vakinhoudelijk deskundige een gemakkelijk te begrijpen, en daarmee te gebruiken model. Een stermodel bestaat uit 2 soorten tabellen:

1. De feitentabel: dit is de tabel waar grootheden die een proces meetbaar maken in worden opgeslagen. KPI's worden gebaseerd op deze grootheden.
2. De dimensietabellen: dit zijn de tabellen die de context bevatten die betekenis geeft aan de feiten.

Een andere definitie datamart (Inmon methodiek): een database, die gevuld wordt vanuit het DWH, met als doel specifieke rapportages en analyse mogelijk te maken.

4.1.2 Modelleren

We onderscheiden 4 hoofdstappen om tot een stermodel te komen.

1. Kies het te modelleren proces. Bij normaliseren modelleer je de gegevens en hun verbanden. Bij dimensioneel modelleren modelleer je de bedrijfsprocessen. Dimensioneel modelleren staat dichter bij de eindgebruikers. Start het bouwen van het DWH met het modelleren van een proces dat gemakkelijk is en veel meerwaarde heeft.
2. Bepaal het te gebruiken detailniveau. De grain is het detailniveau van de datamart. Het detailniveau bepaalt hoe groot de database gaat worden. En heeft daarmee ook invloed op de performance. Een laag detailniveau resulteert in een grote database met bijbehorende performance uitdagingen, maar levert wel de meeste mogelijkheden in termen van welke vragen beantwoord kunnen worden. Alle beschikbare details opslaan heeft tegenwoordig de voorkeur. Het grain statement is de uitspraak die vastlegt op welk detailniveau je gegevens in het DWH gaat opslaan.
3. Bepaal de van toepassing zijnde dimensie. Dimensies geven context, betekenis, aan de cijfers die een proces inzichtelijk maken. De belangrijkste dimensies volgen uit het grain statement. Het bepalen van het grain statement en het bepalen van de relevante dimensies is een iteratief proces. Een dimensie kenmerkt zich door de vele beschrijvende elementen die ervoor te vinden zijn.
4. Bepaal de relevante feiten. Feiten worden ook wel meetwaarden genoemd. De processen, en veranderingen in die processen moeten meetbaar zijn.

Laat altijd de wensen en de eisen van de gebruikers leidend zijn in je opzet.

4.1.3 Dimensies

To Slice and Dice staat voor het maken van willekeurige doorsnedes door de feiten. Een attribuut is een kenmerk van een dimensie, ofwel een kolom in de dimensietabel. Alles waarop gefilterd of geaggregeerd moet worden, moet een attribuut zijn van een dimensie. Nadat je de relevante dimensies hebt onderkend, is het zaak zo veel mogelijk relevante beschrijvende elementen van deze dimensies te benoemen.

Bijna alle datawarehouses hebben een datumdimensie, omdat de tijd een belangrijke rol speelt in ons leven. Er is een aantal redenen waarom datumdimensies veel meerwaarde hebben in datamarts:

• Gemak van filteren: met een datumdimensie kun je ervoor zorgen dat er voor elke relevante periode een gedefinieerde kolom bestaat.
• Gebroken boekjaren: de datumdimensie bevat de bedrijfsregel die definieert van wanneer tot wanneer een boekjaar loopt.
• Weeknummers: de datumdimensie bevat de bedrijfsregel voor een specifieke week in een boekjaar.
• Ontbrekende data: een datumdimensie bevat extra informatie over periodes.
• Performance: in plaats van voor elke query opnieuw met functies een periode te berekenen, is die berekening vooraf gedaan. Queries worden sneller.

Bij het bouwen van een datumdimensie moet je op het volgende letten:

• Gewenste detailniveau: in veel datawarehouses bevat de datumdimensie een record voor elke dag op de kalender.
• Bepaal de sleutels: een goede datumdimensie bevat voor elke relevante periode een unieke sleutel in de vorm van een getal en een kolom met een leesbare beschrijving.
• Bepaal de overige kolommen: naast de sleutels bevat de datumdimensie beschrijvende informatie.

Er zijn een aantal zaken die belangrijk zijn bij het maken van dimensies:

• Het aantal te maken dimensies: is volledig afhankelijk van de wensen en de eisen. Probeer het aantal dimensies te beperken tot maximaal 6.
• Denormaliseren van dimensies: dimensietabellen zijn platgeslagen, niet genormaliseerde tabellen, die veel redundantie bevatten.
• Te kiezen sleutels: een surrogate key of datawarehousekey is een automatisch gegenereerd, uniek betekenisloos nummer dat elke record krijgt toegewezen op het moment dat het in het DWH wordt weggeschreven.
• Soort informatie: een dimensie bevat bij voorkeur zoveel mogelijk tekstuele informatie met betrekking tot de dimensie.

Waarom is het aan te raden een datumdimensie te gebruiken terwijl alle kolommen die er in staan (zoals jaar, kwartaal, maand etc.) te berekenen zijn uit de transactiedatum:

1. Niet alle gebruikers en tools kunnen deze berekeningen maken.
2. Je kunt logica zoals verschoven boekjaren verwerken in de datumdimensie.
3. Niet alle kalenderdagen komen voor in de feitentabel.

4.1.4 Slowly Changing Dimensions

In operationele databases is er een gebrek aan historische gegevens. Dit wordt door Kimball beschreven als Slowly Changing Dimensions (SCD). Hier zijn een aantal oplossingen voor. De term SCD refereert aan het feit dat attributen van dimensies in de loop van de tijd kunnen veranderen en draagt standaardoplossingen aan voor hoe hier in het DWH mee om te gaan.

SCD type 1: de oude waarde van een attribuut wordt overschreven door de nieuwe, actuele waarde. De waarde van het attribuut wordt niet historisch bijgehouden.

SCD type 2: bij elke verandering van een attribuut wordt een volledig nieuw record aangemaakt. Er bestaan 'actuele' records en 'afgesloten' records.

SCD type 3: je houd van een attribuut in 2 verschillende kolommen zowel de huidige als de vorige waarde bij. Op die manier kunnen huidige en vorige waarde gemakkelijk vergeleken worden.

4.1.5 Conformed dimensions en snowflakes

Een snowflake is een stermodel waarvan 1 of meer dimensies niet zijn platgeslagen maar zijn genormaliseerd. Soms is het wel nuttig om te normaliseren:

1. Het maken van zgn. conformed dimension: veel dimensies zullen voor meer dan een proces interessant zijn. Je wilt deze dimensies zo veel mogelijk hergebruiken bij alle relevante processen. Een dimensiematrix laat overzichtelijk zien welke dimensies relevant zijn voor welke processen. Een conformed dimension is een dimensie die dusdanig generiek is opgezet dat hij door elk relevant stermodel, zonder aanpassingen, gebruikt kan worden.
2. Beheersbaarheid: het normaliseren van een dimensie en daarmee maken van een snowflake kan helpen dimensietabellen klein te houden.

4.1.6 Overige dimensie-overwegingen

Deze zijn:

1. Junkdimensie: dimensie die bestaat uit een combinatie van enkele niet gerelateerde, zeer kleine dimensies.
2. Gedegenereerde dimensie: dimensie zonder dimensieattributen.
3. Unknown member: dummy record in een dimensietabel. Dit record zorgt ervoor dat feiten uit de feitentabel die niet gelinkt kunnen worden aan een dimensierecord nu toch gelinkt kunnen worden.

4.1.7 Feiten

Uit de informatieanalyse zijn indicatoren of zelfs KPI's naar voren gekomen. Daar wordt een organisatie op gestuurd. Dat zijn feiten, en die zijn over het algemeen numeriek en meestal aggregeerbaar. De feitentabel in het sterschema is de centrale tabel in het midden. Er zijn verschillende soorten feiten:

1. Additive feiten: deze zijn aggregeerbaar en kunnen dus bij elkaar worden opgeteld.
2. Niet-additieve feiten: deze zijn niet aggregeerbaar, zoals bijvoorbeeld percentages.
3. Semi-additieve feiten: in sommige dimensies wel aggregeerbaar en in andere niet.

Daarnaast zijn er nog verschillende soorten feitentabellen. De meeste feitentabellen zijn als het ware registraties van wat er is gebeurd:

• Accumulating snapshot: feitentabel die de huidige status van de feiten weergeeft maar waarbij feiten nog aan verandering onderhevig kunnen zijn.
• Periodiek snapshot: feitentabel die stand van de feiten weergeeft op een specifiek moment. Voor een ander moment wordt een ander snapshot gemaakt.

4.2 Bill Inmon

4.2.1 Kritiek op Kimball

Veel gehoorde kritiek op de Kimball-aanpak is dat het dimensioneel gemodelleerde DWH slecht in staat is zich aan te passen aan veranderende omstandigheden.

4.2.2 Inmon methodiek

Een Inmon-DWH is een genormaliseerde database. Dat betekent dat het is gemodelleerd op basis van verbanden tussen gegevens die stabiel zijn in de tijd in plaats van veranderlijke processen. Bij een DWH volgens Inmon wordt het DWH alleen gebruikt om datamarts te vullen, het wordt niet gebruikt als bron voor rapporten of analyses. De Corporate Information Factory is het geheel van componenten van stagen database tot en met datamarts dat ervoor zorgt dat gegevens uit operationele systemen omgevormd worden tot informatie voor de medewerkers van een organisatie.

4.2.3 Kritiek op Inmon

De Kimball-methodiek maakt een iteratieve projectaanpak met kleine stappen en snel opleveren van resultaten mogelijk. De Inmon-opzet van een DWH dwingt je eerst het hele DWH te ontwerpen. Dit is moeilijk te rijmen met de tegenwoordige geprevaleerde iteratieve manier van werken.

4.2.4 Samenvatting

Samengevat kun je zeggen dat de Kimball-methode gemakkelijker is in de uitvoering van het project. Het is eenvoudig een kleine scope te kiezen. Daardoor kun je snel resultaten opleveren. Bovendien vergroot je de kans op succes. Het nadeel is dat het moeilijk kan zijn het DWH mee te laten groeien met veranderende eisen en wensen van de eindgebruikers.

De Inmon-methode levert een in de tijd gezien stabieler DWH op. Een bedrijf kan langer profiteren van zijn investering. De grote uitdaging zit in het bepalen van de scope en het klein houden van je projecten.

Data Vault probeert het beste van beide aanpakken te combineren.

4.3 Data Vault

4.3.1 Definitie

Data Vault is een verzameling gekoppelde tabellen die gedetailleerde en historische informatie bevatten van 1 of meer processen. Het is een mix tussen normaliseren en dimensioneel modelleren. Later kan deze structuur uitgebreid worden. Gebruikers rechtstreeks op een Data Vault-structuur laten werken is dan ook een slecht idee. De datamarts bevatten de informatie uit de Data Vault.

4.3.2 Hybs, Links en Satellites

Het stappenplan voor het maken van een Data Vault structuur is als volgt:

1. Bepaal de business keys, de hubs. Hubs zijn de tabellen die vergelijkbaar zijn met dimensietabellen maar dan zonder alle beschrijvende attributen. Deze tabellen bevatten Surrogate Key, Business Key, Record Source, Load Audit ID.
2. Bepaal de relaties tussen de business keys, de links. Links zijn tabellen die vergelijkbaar zijn met de feitentabellen. Ze bschrijven de relaties die verschillende hubs onderling hebben. Ze bevatten de feiten zelf niet. Deze tabellen bevatten: Surrogate Key, Hub Keys, Record Source, Load Audit ID.
3. Bepaal de beschrijvende informatie van de business keys, de satellites. Satellites zijn tabellen die de feiten - en dimensieattributen bevatten. Ze zijn d.m.v. foreign keys gekoppeld aan links of hubs. Deze tabellen bevatten: Surrogate Key, Hub Key/Satellite Key, Volgnummer, Begin- en Einddatum, Record Source, Load Audit ID, beschrijvende velden.
4. Onafhankelijke tabellen toevoegen.
5. Tabellen toevoegen om performance van queries te ondersteunen.

4.3.3 Voordelen Data Vault

• Eenvoud van laden: generiek en gemakkelijk om te vullen.
• Snelheid van laden: hubs, links en satellites zijn onafhankelijk, de foreign keys zitten in de hubs, dus moeten die eerst worden geladen.
• Betrouwbaarheid van laden: laden is betrouwbaarder, en het loggen van fouten eenvoudiger. Dat moet leiden tot een betrouwbaarder laadproces.
• Compliance: opzet met source keys en verwijzingen naar audit-records.

Andere voordelen data mart zijn:

1. Omdat een tabel nooit van structuur verandert is de impact vn wijzigingen op bestaande functionaliteit klein.
2. Door de generieke ETL structuur is de ETL makkelijk te genereren.
3. Makkelijk incrementeel ontwikkelen.

4.3.4 Samenvatting

Data Vault poogt met een generieke tabelstructuur het beste van Kimball en de Inmon-strategie te combineren. Bovendien speelt het in op de krachtiger hardware die we tegenwoordig hebben. Ook houdt het meer rekening met strengere compliance-regels van de laatste jaren.

4.4 Kimball, Inmon en Data Vault vergeleken

De argumenten die we gebruikten om Kimball en Inmon te vergelijken waren:

1. stabiliteit van het DWH;
2. gemakkelijk iteratief kunnen ontwikkelen.

Doordat Data Vault business keys als basis neemt (de hubs) zonder alle bijbehorende rompslomp, ontstaat een stabiel systeem. Data Vault heeft dezelfde (of zelfs grotere) stabiliteit dan een gewoon genormaliseerde DWH. Dat is wat Inmon wel heeft en Kimball niet.

Met Data Vault is het gemakkelijk om iteratief te ontwikkelen. Je kunt klein beginnen en dus met een beperkt budget. Hiermee kun je dus ook snel resultaten aan de organisatie laten zien. Van daaruit kun je het DWH en daarmee de totale BI-oplossing uitbouwen. Dit is wat Kimball wel heeft en Inmon niet.

4.5 Tot slot

In organisaties die in volwassenheidsmodellen hoog scoren, is het DWH de centrale plek om alle relevante gegevens, ongeacht de herkomst, op te slaan. Vanaf hier gaan de gegevens naar de gebruikers. Bij een Kimball-implementatie wordt het DWH zelf gebruikt. Bij Inmon en Data Vault zit er nog een laag van datamarts tussen het DWH en de gebruikers ervan. Het DWH vormt daarmee het fundament van je BI-oplossing

Hoofdstuk 5. Het fysieke datawarehouse

5.1 Inleiding

Er is nog nergens gesproken over specifieke keuzes met betrekking tot hardware en software. In dit boek zal ook geen keuze worden gemaakt. Toch is het goed te kijken naar de mogelijkheden op dit gebied en naar enkele zaken die kunnen helpen bij het maken van een keuze.

Elke keuze die men maakt heeft voor- en nadelen. Met andere woorden alle hardware en software heeft zo zijn beperkingen.

Voor de technische keuzes kunnen we Gartner Magic Quadrant gebruiken.

5.2 Technisch Ontwerp

Nadat je een functioneel ontwerp gemaakt hebt, moet het technische ontwerp worden gemaakt. Het FO van een DB betreft de gewenste tabelstructuur alleen rekening houdend met de functionele eisen zoals die naar voren komen uit de informatieanalyse.

Het doel van het TO is om het FO aan te passen aan de werkelijkheid. We kunnen hierbij 2 significante problemen onderscheiden:

1. De performance is niet toereikend.
2. De tabelstructuur is niet werkbaar gezien de beperkingen van het DBMS.

Om deze problemen te voorkomen, moet je weten hoe groot de verschillende tabellen gaan worden.

5.2.1 Aantal Records

Het belangrijkste is dat je in orde van grootte probeert een inschatting te maken van het aantal records, zowel nu als in de toekomst. Als je ziet aankomen dat een tabel erg groot gaat worden, moet je vooraf nadenken over hoe die omvang te beheren. Sommige tabellen in datawarehouses worden zo groot dat ze onbeheersbaar worden. Als je dat vooraf ziet aankomen kun je maatregelen treffen.

5.2.2 Gemiddelde recordlenge

De gemiddelde lengte van de records zijn belangrijk. Om dit te bepalen worden 3 zaken bekeken:

1. Welke kolommen?
2. Wat is het datatype?
3. De gemiddelde lengte van de kolommen.

Het datatype van een kolom bepaalt het soort gegevens dat in deze kolom opgeslagen kan worden. Er zijn 3 verschillende datatypes:

1. Numeriek: hoe groter het datatype, hoe groter de getallen die je kunt opslaan, maar ook hoe meer opslagcapaciteit en geheugen je nodig hebt. Kies altijd het kleinste datatype dat gegarandeerd groot genoeg is voor wat je met een kolom gaat doen.
2. Alfanumeriek: alfanumerieke velden kennen over het algemeen een variant met een vaste lengte en een variant met variabele lengte.
3. Datum: een aparte datatype.

Gemiddelde lengte van namen: als je van elk kolom het datatype kent, en als je van alle kolommen de lengte kent, kun je de gemiddelde recordlengte uitrekenen.

5.2.3 Page Size

Met het toepassen van verticale partionering van snowflakes kun je de problemen voorkomen. Gemiddelde recordlengte en page size zijn belangrijk om in een vroeg stadium te weten zodat je een model kunt maken dat rekening houdt met beperkingen waardoor er later geen performanceproblemen zullen ontstaan. Je moet altijd kijken hoe het functionele ontwerp aansluit bij de eventuele beperkingen van het DBMS en aanpassingen doen waar dat nodig is.

5.2.4 Grootte van de database

Factoren die effect hebben op de totale omvang. Hierbij moet je denken aan:

1. Compressie van de gegevens. Dit is ook erg handig bij grote tabellen.
2. Indexen. Een index moet het gemakkelijker maken om zo snel mogelijk de juiste gegevens te vinden. Dit zorgt dan voor een betere performance van de queries.

Met compressie kun je 2 dingen bereiken:

1. Minder opslagcapaciteit nodig: snelle back-ups, meer tijd voor andere zaken en restore tijden kunnen belangrijk zijn voor de afgesproken SLA's.
2. Betere performance: door het toepassen van compressie hoeven er minder gegevens direct van de schijf ingelezen te worden. Daarmee gaan queries beter performen.

5.2.5 Overige factoren

Het is belangrijk om bij nog meer dingen stil te staan:

• Verwachte workload. Om een inschatting te maken van de workload kun je queries indelen in simpele, gemiddelde en complexe queries.
• Aantal gebruikers. Het aantal concurrent gebruik is mede bepalend voor de belasting op je systeem.
• Beschikbaarheidseisen. De beschikbaarheid van het DWH. Dit kan lokaal maar ook een corporate DWH zijn. Daarnaast moeten er ook eisen opgesteld worden met betrekking tot de downtime. Wanneer een DWH 24/7 online moet staan is namelijk moeilijk om deze down te halen om te patchen. Ook moet er bekeken worden wat er moet gebeuren wanneer geplande downtime ontstaat.

5.2.6 Grootte van je oplossing

5.3 Hardware en software

Bij de Fast-Track architecturen wordt ervan uitgegaan dat alle componenten vergelijkbare specificaties moeten opleveren voor wat betreft de hoeveelheid gegevens die per seconde verwerkt kunnen worden. Elk component kan de bottleneck zijn en de traagste zal dat zijn.

5.3.1 CPU-Capaciteit

De Maximum Consumption Rate is de maximale hoeveelheid data die het DBMS per seconde per processor core kan verwerken. Je kan deze meten door een query uit te voeren en te kijken hoeveel data de query ophaalt en wat de query-responsetijd was.

Het aantal processor cores wordt gegeven door de onderstaande formule: $$ A = \frac{\frac{R}{MCR} G}{T} $$ waarbij

1. A = het aantal Cores
2. R = grootte resultset in MB
3. MCR = Maximum Consumption Rate
4. G = aantal concurrent gebruikers
5. T = responsetijd in sec.

5.3.2 Overige hardwarespecificaties

Naast de CPU moet je nadenken over:

1. Geheugen: de actieve dataset betreft de gegevens die regelmatig geraadpleegd worden en zich daarmee bij voorkeur in het geheugen van de server moeten bevinden.
2. Netwerkbandbreedte: netwerkverkeer moet goed genoeg zijn om de desbetreffende resultaten over het netwerk te kunnen versturen.
3. Opslagcapaciteit: naast de hoeveelheid opslagcapaciteit is ook het soort opslagmedium belangrijk.

5.3.3 Appliances

Een DWH appliance is een geintegreerde set van servers, opslagmedia, operating system, DBMS en andere software speciaal geinstalleerd en geoptimaliseerd voor datawarehousing. Referentie architecturen zijn vooraf gedefinieerde specificaties van hardware opgesteld met ervaring van vergelijkbare DWH projecten uit het verleden.

5.4 Performance features

5.4.1 Indexen

Er zit een nadeel aan het gebruik van indexen:

1. Database wordt groter: meeste situaties zijn echter ondergeschikt aan de query.
2. Schrijf performance wordt slechter: voornamelijk wordt er van deze database gelezen, en is het schrijven ook niet zo belangrijk.

5.4.2 Columnstore

Een gemiddelde DWH query gebruikt 10 to 15% van de beschikbare kolommen uit een tabel. Een columnstore index slaat gegevens kolom voor kolom op in plaats van rij voor rij.

5.4.3 Compressie

Bij compressie wordt de hoeveelheid benodigde opslag kleiner zonder dat er informatie verloren gaat. Maar de gegevens moeten wel gedecomprimeerd worden als ze worden ingelezen en gecomprimeerd als ze worden weggeschreven. De processorbelasting van het serversysteem gaat dus omhoog.

5.4.4 Aggregatietabellen

GROUP BY queries vergen veel rekentijd van de server. Een view is een virtuele tabel. Omdat de performance van GROUP BY queries verbeterd kan worden met aggregatietabellen, moet bij de bepaling van de grain van een feitentabel gekozen worden voor een laag aggregatieniveau.

5.4.5 Partionering

Partionering gaat uit van het idee dat kleine tabellen beter zijn voor de performance dan grote tabellen. Een grote tabel is op te slaan als een verzameling kleine tabellen. Dat kan op 2 manieren:

1. Verticale partionering: hierbij worden kolommen verdeeld over 2 tabellen.
2. Horizontale partionering: hierbij worden de records verdeeld over 2 of meer tabellen.

5.5 Tot slot

In dit hoofdstuk wordt geleerd welke extra aspecten van belang zijn om over na te denken voordat je een DWH gaat implementeren.

Ten aanzien van performance is het volgende van belang:

1. Met trage databases willen mensen niet werken.
2. Query-responsetijden opnemen in de functionele eisen zodat objectief vastgesteld kan worden of de performance acceptabel is.
3. DWH zo klein mogelijk houden omdat kleine datasets betere performance laten zien dan grote.

Het volgende is waar met betrekking tot indexen:

1. Indexen maken een database groter.
2. Indexen moeten worden afgestemd op de gebruikte queries.
3. Indexen maken het lezen in databases sneller.

Het is noodzakelijk om een TO te maken van je DWH omdat het theoretisch ideale model moet worden aangepast aan de beperkingen van je hardware en software.

Hoofdstuk 6. ETL

6.1 Inleiding

ETL staat voor Extract, Transform en Load:

• Extract betreft het lezen van gegevens uit operationele systemen en andere mogelijke bronnen.
• Load staat voor het vullen van het DWH met deze gegevens.
• Transform moet de ingelezen gegevens zo manipuleren dat de organisatie uiteindelijk bereid is de informatie die uit het DWH komt, te accepteren.

ETL is een groep technologieen die veelal gebruikt wordt bij de koppeling tussen systemen, waarbij er gestreefd wordt naar een minimale technische en semantische koppeling. Het is een batchproces dat regelmatig gebruikt wordt.

6.2 Master Data Management

Voor het ETL proces zijn er eigenlijk 2 problemen:

• Twee verschillende systemen geven tegenstrijdige informatie.
• Voor twee verschillende systemen ziet de waarheid er anders uit.

Met behulp van Master Data Management kunnen we deze problemen aanpakken. Het betreft een verzameling disciplines en processen die zorgt voor accurate, complete, tijdige en consistente gegevens voor belangrijke entiteiten binnen een organisatie over verschillende databases, afdelingen en landen heen. Een van de voordelen van MDM is het makkelijker voldoen aan compliancy als de gegevens centraal staan met duidelijke regels omtrent eigenaarschap en veranderingen.

6.2.1 Verschillende soorten gegevens

Verschillende soorten gegevens die in een database zitten zijn:

1. Meta Data
2. Reference Data
3. Enterprise Structure Data
4. Transaction Structure Data
5. Transaction Activity Data
6. Transaction Audit Data

Meta data zijn gegevens over de gegevens: gegevens die de gegevens in een db beschrijven, zoals de naam van een kolom en het datatype van die kolom.

Reference data zijn de gegevens in look-up tabellen. Dat kunnen gegevens zijn uit ISO, DIN en NEN, maar ook zaken zoals automerken.

Enterprise structure data zijn gegevens zoals grootboekrekeningen of journaalposten.

Transaction structure data zijn de gegevens die nodig zijn om primaire gegevens over processen te kunnen opslaan.

De transaction activity data en de transaction audit data zijn gegevens die betrekking hebben op de registratie van feitelijke processen.

6.2.2 Definities

Master data is de combinatie van reference data, enterprise structure data en transaction structure data. Een voorbeeld van Master Data zijn klant gegevens waar in het ideale geval in een organisatie 1 centrale set wordt bijgehouden die bepalend is voor alle processen.

Master Data Management is een verzameling disciplines en processen die zorgt voor accurate, complete, tijdige en consistente gegevens voor de belangrijke entiteiten binnen een organisatie over verschillende databases, afdelingen en landen heen.

Vanwege de centrale rol van het MDM wordt er ook gesproken over de Master Data Hub.

Compliancy is het voldoen aan (wettelijke) regels en eisen opgelegd door externe partijen zoals overheden en toezichthouders.

Belangrijke zaken voor een goede introductie van MDM in een organisatie zijn:

• een projectleider die politieke gevoeligheden ziet en begrijpt en die oplossingen daarvoor kan aandragen.
• sponsorship van het management.
• een goede Business Case met een heldere doelstelling die gecontroleerd kan worden.
• duidelijke scope van het (initiele) project.
• inzicht in het businessmodel.

MDM kan op 3 punten voordelen opleveren:

1. Op operationeel niveau worden er minder fouten gemaakt en/of kan er efficienter gewerkt worden, als de gegevens consistenter zijn.
2. Op BI-niveau kunnen eenduidiger analyses gemaakt worden van gegevens uit verschillende systemen.
3. Het is makkelijker te voldoen aan wet- en regelgeving als de gegevens centraal staan met duidelijke regels omtrent eigenaarschap en veranderingen.

Het is van belang de scope van ee MDM-implementatie goed te definieren.

Data stewards zijn mensen met inhoudelijke kennis van zaken die verantwoordelijk zijn voor de (kwaliteit van de) gegevens.

6.2.3 Paragraaf niet aanwezig

6.2.4 Voorbeeld van Microsoft MDS

In deze paragraaf woordt een voorbeeld uitgewerkt van MDM op basis van MS SQL Server Master Data Servers:

• https://www.leerboekbusinessintelligence.nl/6_etl/voorbeeld_met_microsoft_mds

6.2.5 Tot slot

Niet relevant.

6.3 Implementeren van het ETL-proces

Ook hier moet de informatieanalyse leidend zijn bij het nemen van ontwerpbeslissingen. Deze beslissingen hebben betrekking op de volgende onderwerpen:

• Welke gegevens moeten worden opgehaald?
• Architectuur en frequentie van het ETL-proces.
• Technische implementatie (SQL, keuze tools e.d.)

6.3.1 Resultaten van de informatieanalyse

Aspecten ETL die in de informatieanalyse aandacht behoeven:

1. Welke kolommen moeten er mee genomen worden?
2. Data latency
3. Historische gegevens (denk aan SCD en welke type moet er worden geimplementeerd).
4. Oude gegevens (hoe ver ga je terug in de geschiedenis?)
5. Auditing
6. Fouten
7. Monitoring

Duidelijk is dat de informatiebehoeften (welke informatie moet op welke rapporten beschikbaar komen) stuurt welke kolommen overgehaald moeten worden naar het DWH.

De data latency van een DWH is de tijd die zit tussen het ontstaan van gegevens en het moment dat deze gegevens beschikbaar komen in het DWH. De eisen die hieraan gesteld worden hebben in eerste instantie betrekking op de frequentie van het ETL-proces.

De feiten kunnen achteraf wijzigen. Uit de informatieanalyse moet blijken hoe de ETL hiermee moet omgaan (type SCD, accumulating snapshot feitentabel, peildatum).

Naast historische gegevens in de zin van veranderende gegevens, is het interessant om te weten hoe ver terug in de geschiedenis het DWH of de datamart moet gaan.

Auditing is het toevoegen van metadata aan de gegevens in het DWH zodat is te herleiden wie of welk proces de gegevens wanneer en hoe heeft geladen. In de context van ETL-auditing komt dit neer op het toevoegen van informatie over de ETL zelf aan de gegevens die geladen worden. Door audit-informatie toe te voegen als dimensie aan het DWH, kunnen vragen beantwoord worden als:

1. Waar komt deze informatie vandaan?
2. Hoe komen we aan deze getallen? Audit-informatie hoeft niet per se als dimensie te worden toegevoegd. Auditing is cruciaal als je moet voldoen aan compliance-eisen, immers er komen steeds meer situaties dat je moet voldoen aan wetten en regels.

ETL is software en bij software moet je nadenken over hoe je wilt omgaan met fout situaties.

Beheerders van ETL-processen moeten weten of de processen hebben gedraaid, of ze succesvol of met een fout zijn geeindigd, wat de totale doorlooptijd van het proces was en misschien nog wel andere zaken.

Daarnaast zijn er nog een aantal factoren die een rol spelen:

1. De hoeveelheid gegevens die per keer overgehaald moeten worden.
2. Het aantal en soorten bronnen.
3. Het tijdstip en tijdsduur dat de gegevens uit de bronnen ingelezen mogen worden.

6.3.2 Architectuur

Er kunnen grofweg 3 ETL architecturen worden onderkend:

1. Zonder staging-laag (wordt niet vaak gebruikt).
2. Met staging-laag.
3. Met 2 staging-lagen.

Een staging database is een db waarin gegevens tijdelijk worden opgeslagen alvorens ze worden doorgestuurd naar het DWH.

De voordelen van het gebruik van een staging database zijn:

1. Meer flexibiliteit.
2. Herstarten ETL is makkelijker.
3. Omgaan met verschillende databases en verschillende beschikbaarheid van databases wordt gemakkelijker.
4. In staging kunnen bewerkingen uitgevoerd worden zoals uitzoeken welke gegevens gewijzigd zijn.

De belangrijkste eigenschap van 2 staging-lagen is: de landing database lijkt nu qua ontwerp op de bronnen, de staging juist op het DWH. Het vullen van de DWH is nu een kwestie van het 1 op 1 overhalen van de gegevens uit de staging database. Een groot deel van de tijdrovende transformaties vindt plaats tussen de landing en de staging database.

Het voorgaande schetst vooral de logische architectuur. Je moet ook nadenken over de fysieke architectuur. Is elke laag ook echt een aparte database? En zo ja, staat elke database op een aparte server?

6.3.3 Documenteren

Er zijn 2 balangrijke redenen om mappingdiagrammen te gebruiken:

1. Om helder te krijgen welke brontabellen nodig zijn.
2. Om de ETL te documenteren.

In een mappingtabel kun je in detail aangeven welke kolom uit het bronsysteem op welke manier in het doelsysteem terechtkomt. De mappingtabel bevat typische ETL-informatie. Geef per kolom aan of het een SCD-kolom is, en zo ja, welk type. Verder kun je transformaties invullen. Het resultaat is tegelijkertijd documentatie en input voor de ETL-programmeur. Het enige wat nog moet worden bedacht is: met welke tools en met welke technieken gaan we de ETL implementeren. Daarvoor moeten de bronsystemen nog wat nader worden bekeken.

Er zijn veel verschillende bronnen:

• Relationele databases
• Big Data en NoSQL-databases
• Tekst bestanden, XML, JSON
• RSS Feeds
• Wellicht nog veel andere bronnen

De tool die je kiest om het ETL-proces mee te bouwen, moet in staat zijn deze verschillende bronsystemen te kunnen uitlezen. Vluchtigheid van gegevens en security speelt hierbij natuurlijk ook een belangrijke rol.

6.3.4 Tools en Technieken

Er zijn heel veel tools op de markt met hun sterke en zwakke punten

Een combinatie van een ETL-tool en SQL is vaak het beste:

1. ETL-tools (MS IS en MS Power Query)
2. Data Quality (MS DQS)
3. Data Management (MS MDS)

6.4 Datakwaliteit

6.4.1 Slechte gegevens

Er zijn verschillende redenen dat de kwaliteit van de gegevens slecht is:

1. Er zijn meer bronsystemen. Elk bronsysteem heeft zijn eigen versie van de waarheid.
2. Situaties veranderen.
3. Gegevens worden foutief en onvolledig ingevoerd.

MDM kan een oplossing zijn als dimensiedata in meer bronnen voorkomt. Hierbij dien je er wel voor te zorgen dat de kwaliteit van de Master Data goed is. Zonder MDM-oplossing moet je bij het laden van dimensies iets met de kwaliteit van de gegevens doen.

Naast het probleem van meerdere bronnen blijkt dat de gegevens zelf inherent slecht zijn van kwaliteit. Soms zijn de gegevens niet meer waar. Er kan immers van alles gebeuren buiten het zichtveld van een organisatie, dat ervoor zorgt dat de gegevens niet meer kloppen.

Soms worden gegevens door mensen ingevoerd en mensen maken fouten

6.4.2 Data Cleansing

Data Cleansing is het opsporen en verbeteren of verwijderen van inconsistente en foutieve records uit een verzameling, tabel of database.

Data Cleansing is misschien wel de belangrijkste stap in het ETL-proces

Als je de gegevens overhaalt naar een MDM-implementatie of naar datamarts, moet de kwaliteit goed zijn.

6.4.3 Voorbeeld met Microsoft DQS

• https://www.leerboekbusinessintelligence.nl/6_etl/voorbeeld_met_microsoft_dqs

6.5 Scenario's

• https://www.leerboekbusinessintelligence.nl/6_etl/scenarios

6.6 Tot slot

Basaal is ETL niets anders dan het kopieren van gegevens van een bronsysteem naar een doelsysteem. In een breder perspectief is het ook het aanpassen van gegevens aan de eisen van het doelsysteem: herleidbaarheid, auditing en compliancy komen dan om de hoek kijken.

Datakwaliteit is belangrijk. Met gedistribueerde systemen is MDM en Master Data een uitdaging. Hierbij geldt het aloude paradigma: garbage in, garbage out.

Er zijn veel tools op de markt ter ondersteuning van het ETL-proces.

Met een kwalitatief goede DWH en/of datamart zijn analisten in staat om goede analyses te doen.

Data Scrubbing is het verbeteren van inconsistenties en incorrecte gegevens.

Master Data Hub: Master Data staat centraal en bronnen worden gesynchroniseerd met de Master Data.

Voordelen automatisch gegenereerde getallen:

1. Ze zijn efficient in het gebruik.
2. Ze maken de ETL langzamer omdat voor elk record een unieke waarde moet worden gegenereerd.

Hoofdstuk 7. Big Data en Advanced Analytics

7.1 Introductie Big Data

7.1.1 Beperkingen van klassieke datawarehouses

Klassieke datawarehouses hebben een aantal tekortkomingen:

1. Er worden vnl. alleen relationele bronnen ontsloten.
2. Het is moeilijk realtime datawarehouses te maken.
3. Datawarehouses zijn niet heel geschikt voor Advanced Analytics.

7.2 Definitie van Big Data

Big Data betekent dat het soort gegevens dat je hebt in combinatie met wat je er mee wilt doen, je dwingt te innoveren.

Big Data wordt gedefinieerd door de 3 V's:

• Volume
• Variety
• Velocity

7.2.1 Volume

Scale-up is het inzetten van een grotere server.

Scale-out is het verdelen van de workload over een cluster van meerdere servers.

7.2.2 Variety

In het kader van variety kunnen we de gegevens onder verdelen in 3 soorten:

1. Structured Data
2. Semi-structured Data
3. Unstructured Data

Bij gestructureerde data is er een schema, een datamodel bekend. Met het schema wordt de metadata bedoeld: de beschrijving van alle kolommen, de datatypes van de kolommen en het domein (de mogelijke waarden) van de kolommen. Met schema-on-write bedoelen we dat de metadata al moet bestaan voordat de gewone gegevens opgeslagen kunnen worden.

Bij semi-gestructureerde data (XML, JSON, log bestanden) is er nog wel sprake van enige metadata maar niet meer zo in ijzer gegoten als bij de gestructureerde gegevens. Met schema-on-read bedoelen we dat we de metadata die gegevens beschrijft pas gebruiken bij het verwerken van de gegevens, niet bij het schrijven (registreren) van die gegevens.

Ten slotte heb je ongestructureerde gegevens. Helemaal ongestructureerd is het nooit. Als je een bestandsformaat weet, heb je al kennis over het soort informatie. Big Data is aanvullend op klassieke BI. Het is geen vervanging van klassieke BI.

7.2.3 Velocity

Dit heeft betrekking op:

1. De snelheid waarmee gegevens ontstaan.
2. De snelheid waarmee we de gegevens moeten verwerken tot bruikbare informatie.

7.2.4 Andere kenmerken

Andere kenmerken van Big Data zijn o.a. Veracity en Value.

Mogelijke vertalingen voor veracity zijn waarheid, echtheid en geloofwaardigheid. De signal-to-noise ratio is de verhouding tussen informatie en de ruis in de data.

Met de value wordt de meerwaarde van gegevens bedoeld, de bruikbaarheid. De waarde wordt onder meer bepaald door vragen als:

• Is de data volledig?
• Wat is de veracity?

7.2.5 Tot slot

BI is langzaam maar zeker aan het verschuiven van een Decision Support System (DSS) dat gebruikt wordt voor hoger management naar een operationeel systeem dat de dagelijkse besluitvorming ondersteunt. Daarmee ondersteunt het direct de primaire processen en geeft het bedrijven de kans beter te functioneren.

7.3 Advanced Analytics

7.3.1 Inleiding Data Analytics

Data Analytics is het analyseren van gegevensverzamelingen om besluitvorming te ondersteunen en theorieen te testen.

De ervaring leert dat door het opzetten van datawarehouses en daaraan verwante technieken het proces van Data Analytics het best wordt gefaciliteerd.

Analytics is een werkwijze die een onderdeel moet zijn van de bedrijfscultuur.

7.3.2 Basic Analytics

Basic Analytics bestaat uit Descriptive Analytics en Diagnostic Analytics.

Descriptive Analytics beschrijft een situatie of proces met getallen waarbij wordt teruggekeken naar het verleden.

Diagnostic Analytics probeert antwoord te geven op de vraag "Waarom iets is gebeurd?"

7.3.3 Advanced Analytics

Advanced Analytics is onder te verdelen in Predictive Analytics en Prescriptive Analytics.

Predictive Analytics berekent de waarschijnlijkheid dat iets zou kunnen gebeuren in de toekomst.

Bij Prescriptive Analytics gaat het om het nemen van beslissingen.

7.3.4 Top-down versus bottom-up

Bij een top-down benadering ga je uit van een bestaande theorie oftewel kennis vooraf. De analyse kan gedaan worden op basis van het DWH of op basis van een semantisch model dat gebaseerd is op het DWH omdat er met voorkennis al rekening is gehouden met de mogelijkheid dat dit soort analyses uitgevoerd gaan worden.

Conformatory analyse gebruikt een top-down benadering om een vooraf gestelde hypothese te bevestigen.

Exploratory analyse is een bottom-up benadering waarbij je probeert zonder beinvloeding vooraf patronen in datasets te vinden.

7.3.4 Tot slot

Het woord analytics omschrijft een breed scala aan handelingen waar vooral het analyseren van gegevens en het communiceren van de resultaten centraal staan. Bij Advanced Analytics wordt in het algemeen gebruik gemaakt van machine learning en datamining.

7.4 Machine learning en datamining

7.4.1 Definities

Datamining is het achterhalen van verbanden, patronen en trends in gegevensverzamelingen.

Machine learning is een techniek die tot doel heeft het doen van voorspellingen op basis van bekende patronen in gegevensverzamelingen.

De nauwkeurigheid waarmee voorspellingen gedaan kunnen worden neemt toe als de gebruikte dataset groter wordt.

7.4.2 Machine learning scenario's

1. Supervised learning (classificatie, regressie)
2. Unsupervised learning (clustering, outlier detectie)

7.4.3 Tot slot

Er zijn veel algoritmes waaruit een data scientist kan kiezen bij de verschillende scenario's. Hij zal gedegen statistische kennis nodig hebben om de gegevens te analyseren, de juiste algoritmes te kiezen, de juiste parameters te kiezen en de uitkomsten op de juiste waarde te schatten

Machine learning is een component van analytics. Het doel is om besluitvorming te ondersteunen. Uiteindelijk willen we er competitief voordeel uit halen. En daarmee vormt het een goede aanvulling op BI.

7.5 Big Data Tools - Data Lake - noSQL

7.5.1 Data Lake

Een Data Lake is een omgeving waar je gegevens verzamelt in hun oorspronkelijke formaat en schema. Meestal gaat het om tekst files en blob files.

7.5.2 noSQL

noSQL staat voor not only SQL. Het is een term die staat voor alle databaseplatformen die niet relationeel zijn.

7.5.3 Big Data-databases

Een cluster is een verzameling gekoppelde servers die samenwerken alsof ze een zijn.

Hadoop is een opensource raamwerk van software voor Big Data-toepassingen.

7.6 Big Data en datawarehousing

Big Data is een aanvulling op klassieke BI en datawarehousing.

7.7 Big Data en ethiek

7.7.1 Hoe wenselijk is Big Data Analytics?

Het gaat hier om vragen op te werpen waar de samenleving als geheel over moet nadenken.

7.7.2 Wet- en regelgeving

Bij wetgeving dient er nagedacht te worden over het volgende:

1. Privacy
2. Transparantie
3. Discretie
4. Identiteit

7.7.3 Tot slot

Zowel als maatschappij, als ook binnen bedrijven, is het noodzakelijk om stil te staan bij de ethische kant van Big Data Analytics.

7.8 Voorbeeld van datamining met Excel

• https://www.leerboekbusinessintelligence.nl

7.9 Tot slot

Alle nieuwe mogelijkheden zijn aanvullend op wat BI altijd al was.

Het concept cluster is belangrijk bij Big Data oplossingen:

1. Bij een cluster kan een computer taken overnemen van een andere computer als die andere kapot gaat.
2. Bij een cluster kunnen bewerkingen verdeeld worden over meer computers zodat de totale oplossing schaalbaar is voor grote databewerkingen.

Machine Learning is een onderdeel van Advanced Analytics. Advanced Analytics is geen onderdeel van Big Data omdat deze ook kan worden toegepast op gestructureerde data van niet-extreme omvang.

Het verschil tussen BI en Business Analytics: BI is het kwantitatief inzichtelijk maken van prestaties, Business Analytics beantwoordt het waarom en vertaalt dat naar de toekomst.

De redenen dat Predictive Analytics om een bottom-upbenadering vraagt zijn:

1. Door bottom-up te werken verminder je de kans op bias in de resultaten.
2. Bij Predictive Analytics wil je ook gebruik maken van eventueel niet bekende of verwachte verbanden in de gegevens.

De redenen dat datamining leidt tot verkeerde conclusies zijn:

1. Afwijkende gegevens zijn niet altijd foutieve gegevens.
2. Niet alle soorten verbanden zijn oorzakelijke verbanden.

Hoofdstuk 8. Semantische modellen

8.1 Inleiding

Om goed, gemakkelijk en snel gegevens te kunnen analyseren zijn datamarts in de vorm van een sterschema uiteindelijk niet toereikend. Waarom voldoet een datamart dus niet? Om deze vraag te beantwoorden kijken we eerst naar 3 eisen die worden gesteld aan gespecialiseerde OLAP-databases:

1. OLAP-database moet een conceptueel en intuitief gegevensmodel opleveren.
2. OLAP-database moet (relatief) gemakkelijk voor analysedoeleinden nuttige berekeningen kunnen uitvoeren.
3. OLAP-database moet goede performance hebben, ook bij grote datasets.

8.1.1 Semantisch model

Stermodel heeft de volgende tekortkomingen:

• Technische kolommen
• Stermodel bevat voor eindgebruikers irrelevante technische kolommen
• Stermodel bevat auditing-gerelateerde kolommen
• Kolomnamen sluiten niet aan bij het bedrijfsjargon
• Tabelstructuur geeft problemen voor query-generatoren
• Nuttige berekende kolommen en meetwaarden ontbreken

Een semantisch model bevat alleen de voor de gebruikers relevante kolommen en entiteiten.

Headers op rapporten moeten duidelijk zijn, in de taal van het bedrijf geschreven eenduidig over alle rapporten heen.

In een semantisch model wordt vastgelegd hoe verschillende entiteiten uit de organisatie verband met elkaar houden. Een semantisch model vertaalt een technische database-implementatie in een voor eindgebruikers leesbaar en begrijpelijk model dat bruikbaar is zonder over (veel) technische kennis te beschikken.

Belangrijker dan berekende kolommen zijn de berekende meetwaarden.

Om een OLAP-database een intuitief en conceptueel gegevensmodel te laten zijn, wordt bereikt door de vertaling naar een semantisch model.

Er zijn 2 belangrijke criteria die bepalen hoeveel meerwaarde een semantisch model heeft:

1. Het technisch niveau van diegenen die rapporten gaan bouwen en die analyses gaan doen.
2. Hoe goed de gebruikte datamart aansluit bij het gebruik.

Het bouwen van een semantisch model komt overeen met een topdown-benadering.

8.1.2 Performance

Bij gebruik van datamarts komt de performance op 2 vlakken in het geding:

1. De tijd die het duurt om de juiste query te schrijven.
2. De tijd die het duurt om de query uit te voeren.

Met een OLAP-database of een in-memorydatabase kunnen performanceproblemen die bij datamarts een rol spelen voorkomen worden.

8.1.3 Query-performance en Big Data

Veel Big Data-architecturen verdelen de gebruikte technieken in drie lagen:

• batch layer
• speed layer
• serving layer

In de batch layer draaien jobs die zich goed laten schedulen. Hier is dus sprake van batchverwerking.

In de speed layer vindt realtime analyses plaats en kunnen we de resultaten direct gebruiken.

In de serving layer kunnen we de resultaten aanbieden aan de gebruiker. Een OLAP-database zoals een kubus kan heel goed dienen als de serving layer. Dit is 1 van de belangrijkste doelen van een OLAP-database.

8.1.4 OLAP query engine

Goede OLAP-databases hebben krachtige scripttalen om berekeningen te doen.

8.1.5 Tot slot

Semantische modellen laten beschikbare gegevens aan gebruikers zien in hun egen taal zonder technisch randzaken.

OLAP-kubussen kunnen de performance problemen oplossen.

8.2 OLAP-kubus

8.2.1 Wat is een kubus?

Een kubus is op te vatten als een multidimensionale database. OLAP-database en OLAP-kubus zijn synoniemen. Het betreft een analyse database waarbij vanuit meerdere perspectieven naar de gegevens gekeken kunnen worden.

Members in een kubus worden gevormd door de inhoud van een kolom in een DWH.

Een vuistregel zegt dat een stermodel uit niet meer dan 7 dimensies moet bestaan. Dat vertaalt zich echter niet naar een kubus met 7 assen; het zal een veelvoud daarvan zijn.

8.2.2 Waarom kubussen?

Er zijn 2 redenen waarom excel zo'n belangrijke BI tool is:

1. de draaitabel
2. formules en functies

De draaitabel (matrix, pivottable) is een handige en veelgebruikte manier om grote hoeveelheden gegevens eenvoudig inzichtelijk te maken.

Multi Dimensional eXpressions (MDX) is de taal die hoort bij OLAP-kubussen.

8.2.3 Aggregaties

Redenen waarom kubussen betere performance bieden dan relationele databases zijn:

• een andere opslagstructuur
• betere compressie
• andere query engine
• pre-aggregates

Een natuurlijke hierachie is een drill-downpad waarvoor geldt dat er een 1-op-veelrelatie bestaat van het hogere niveau naar lagere niveaus.

8.2.4 Model of database?

MOLAP staat voor multidimensional OLAP.

ROLAP staat voor relational OLAP.

HOLAP staat voor Hybrid OLAP oftewel een mengvorm van MOLAP en ROLAP.

DOLAP staat voor Desktop OLAP en representeert technieken om de informatie offline beschikbaar te maken zodat bijvoorbeeld thuis met de laptop ook gewerkt kan worden.

8.2.5 Tot slot

Samengevat heeft de kubus 3 voordelen:

• Kubus is een semantisch model.
• Kubus heeft een krachtige rekentaal: MDX.
• Kubus heeft goede performance.

8.3 Voorbeeld in memorymodel

Zie inzendopgave.

8.4 Tot slot

Voordeel van excel in combinatie met een model is de analytische kracht van deze combinatie.

In de hoofdstukken 3 t/m 6 lag de nadruk op het verzamelen van de juiste gegevens om die vervolgens met de juiste kwaliteit in de juiste structuur op te slaan.

Hoofdstuk 6 nuanceerde de behoefte aan structuur en focuste met analytics al op het meer praktische gebruik, terwijl in dit hoofdstuk de focus lag op het gebruik van gegevens.

Het volgende hoofdstuk gaat over het echte presenteren, de communicatie uit analytics.

Semantisch model betreft een laag die een vertaalslag doet van een technische implementatie naar logische business entiteiten.

Argumenten om een kubus in te zetten binnen een BI-architectuur:

1. Het voor gebruikers makkelijker en intuitiever maken om gegevens uit het DWH te gebruiken.
2. Het verrijken van de gegevens in het DWH met berekende dimensieattributen en meetwaarden.

De 4 definities van een OLAP-kubus:

1. Een kubus is een manier van gegevensopslag die dynamische analyse van de gegevens ondersteunt.
2. Een kubus is een semantisch model.
3. Een kubus is een multidimensionale database.
4. Een kubus is een draaitabel met (mogelijk) meer dan 2 assen.

Bij MOLAP is de kubus een semantisch model en een database in 1, bij ROLAP is het alleen een semantisch model.

De kracht van een OLAP query engine is:

1. Het aggregeren van numerieke gegevens in grote datasets.
2. Het beantwoorden van multidimensionele vragen.

Hoofdstuk 9. Het front-end

9.1 Inleiding

Front-end BI-oplossing is wat we zien en gebruiken:

• rapportages,
• dashboards,
• scorecards, en
• andere tastbare zaken.

Hierbij wordt het DWH en/of modellen ter beschikking gesteld aan de makers van front-ends.

Vanuit projectperspectief verdient een incrementele aanpak wel de voorkeur. Dit betekent dat je een stukje DWH ontwikkelt en vult en daar dan een front-end bij bouwt. Daarna breid je het DWH uit, waarna er weer nieuwe rapportages gebouwd kunnen worden.

9.2 Wie maakt en wie gebruikt rapporten?

Om de juiste tools te kiezen moet je naar 2 zaken kijken:

1. Technische specificaties van de beschikbare tools.
2. Wie is de doelgroep?

Technische specificaties hebben betrekking op de tools die beschikbaar zijn. Daarnaast is het belangrijk te kijken naar de aansluiting van deze tools op de achterliggende DWH en/of model. Bovendien is het belangrijk te weten voor welke doelgroep deze tools zijn gemaakt.

De mogelijke doelgroepen zijn al in hoofdstuk 2 ter sprake gekomen: farmers, tourists, explorers en de miners. We moeten weten welke mensen in welke groep vallen en bepalen welke tool aansluit bij de gestelde BI-doelen voor deze mensen. Gekozen tool dient aan te sluiten bij hun technische kennis en vaardigheden.

9.2.1 Farmers

Farmers zijn mensen met een vaste, terugkerende informatiebehoefte. De farmer is veelal niet degene die de rapporten maakt; dit is een BI-ontwikkelaar of iemand met een vergelijkbare rol.

Farmers gebruiken de volgende soorten rapporten:

• productierapporten;
• pixel perfect-rapporten;
• operationele rapporten;
• enterprise reporting.

Hoe farmers rapporten gebruiken komt overeen met Descriptive Analytics.

9.2.2 Tourists

Nadat tourists de informatie uit de standaardrapporten tot zich hebben genomen, blijft er nog een informatiebehoefte nodig: ad hoc vraagstukken. Hierbij is het relevant je af te vragen wie in deze informatiebehoefte gaat voorzien. Dit kan een professional vanwege haar/zijn technische bagage zijn en er is geen beperking als het gaat om tooling.

Nadelen inzetten specialist zijn:

1. Relatief duur.
2. Afdeling die rapporten maakt is druk, waardoor de vraag pas laat beantwoord werd.
3. Door slechte communicatie tussen de vrager en de IT-professional voldoet rapport niet aan de vraag.

Tools waar tourists wellicht mee aan de slag kunnen gaan zijn: MS Reporting Services en Power View.

Naast ad-hoc rapportages hebben tourists behoefte aan meer gedetailleerde informatie dan de standaardrapportages leveren. Dit kan door rapportages interactief te maken. Bij interactieve rapporten kun je onderscheid maken tussen drill-down en drill-through.

Drill-down staat voor het navigeren van hoog geaggregeerde gegevens naar steeds meer detail.

Drill-through betekent dat op een rapport hyperlinks staan naar andere rapporten.

9.2.3 Explorers

Dit zijn de mensen die nieuwe wegen moeten en willen zoeken. Zij kijken vanuit een andere invalshoek naar de gegevens. Ze zoeken naar onbekende informatie en verbanden.

Excel is optimaal geschikt voor explorers.

De explorer is sterk bezig met Diagnostic Analytics.

9.2.4 Miners

Miners zetten bijvoorbeeld datamining in voor het analyseren van gegevens. Dit zijn mensen die zich bezighouden met Advanced Analytics en dan voornamelijk de Predictive Analytics.

De tools waarmee zij werken zijn bijv. SPSS, R en Python.

De data scientist vervult veelal deze rol.

9.2.5 Tools en acceptatie

Belangrijk is bij het kiezen van de juiste front-endtools is inspraak geven aan de beoogde gebruikers. Alles wat wordt opgelegd brengt per definitie wat weerstand met zich mee. Die drempel is genomen indien mensen zelf mogen (mee)beslissen. Bovendien weten ze zelf wat ze willen en kunnen. ICT mag de technische specificaties als inbreng hebben in het besluitvormingsproces.

9.3 Rapporten, scorecards en dashboards

9.3.1 KPI

Een KPI is een managementinstrument dat in 1 oogopslag de status van een proces laat zien. De KPI bestaat uit 4 componenten:

1. Meetwaarde
2. Doel
3. Status
4. Trend

De meetwaarde is het feit. De doelstelling is ook een getal die goed vergeleken kan worden met de meetwaarde. Met de status wordt de doelstelling vergeleken met de meetwaarde. Met behulp van de trendindicatie kunnen verschillende periodes met elkaar worden vergeleken.

Een mission statement is het algemene doel dat een organisatie zichzelf als geheel stelt. Doelstellingen dienen SMART te zijn. SMART betekent: Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden.

De strategie van een organisatie is de wijze waarop de organisatie het doel zoals verwoord in het mission statement denkt te bereiken.

9.3.2 Scorecard

Een scorecard is niets anders dan een lijstje met KPI's. Het doel van een scorecard is snel te kunnen zien hoe een organisatie, een afdeling of een persoon presteert.

Balanced Scorecard is een techniek voor strategisch management en het behalen van langetermijndoelstellingen binnen bedrijven. Het is een methode om bedrijven aan te sturen, terwijl de scorecard het hulpmiddel is dat daarbij wordt gebruikt.

Bij de balanced scorecard-methode en de hulpmiddelen die daarbij gebruikt worden hoort volgens Kaplan en Norton (bedenkers balanced scorecard), ook een strategy map. De map beoogt het verband tussen de strategie en de concreet gestelde doelstellingen duidelijk te maken. Een strategy map kan gezien worden als documentatie bij een scorecard die is opgezet volgens de theorie van de balanced scorecard, dus met KPI's in alle 4 de perspectieven, uitgewerkt tot concrete SMART-doelstellingen op operationeel niveau

9.3.3 Dashboard

Een dashboard is een gemakkelijk te lezen, vaak realtime, grafisch overzicht van de status en de historische trends van de KPI's van een organisatie om onmiddellijk gefundeerde besluiten te nemen.

Het is geen harde eis dat een dashboard interactief moet zijn. Een ander kenmerk dat dashboards kan onderscheiden van andere rapporten is het feit dat ze putten uit meerdere bronnen.

Er zijn veel speciale tools op de markt om dashboards te maken, bijv. PerformancePoint van Sharepoint.

9.3.4 Rapporten

Een rapport is een verzameling gegevens die zodanig is opgemaakt en weergegeven dat deze voor de gebruikers bruikbare informatie oplevert.

Veel rapporten maken gebruik van parameters.

Een bekend fenomeen met rapporten is de wildgroei van beschikbare rapporten.

9.3.5 Security

Bij tool-keuze moeten de securityvereisten meegenomen worden.

Voor rapporten en dashboards valt security uiteen in 2 onderdelen:

1. wie welke rapporten mag gebruiken.
2. welke gegevens mogen op het gebruikte rapport getoond worden.

Technisch moet er ook nog gekeken worden met welke security credentials de op een rapport getoonde gegevens uit de gebruikte bron gehaald worden.

9.4 Ontwerpen van (goede) rapporten

9.4.1 Inleiding rapportontwerp

Het kiezen van verkeerde visualisaties, of het kiezen van een verkeerde schaal, kan leiden tot foutief geinterpreteerde informatie. Dat leidt weer tot verkeerde beslissingen waarmee wij ons hele doel voorbij schieten.

9.4.2 Attentieve verwerking

Belangrijk bij het ontwerpen van rapporten is het onderscheid tussen preattentive processing (preattentieve verwerking) en attentive processing (attentieve verwerking).

Boodschap: door iets simpels als een afwijkende kleur kan je de aandacht van iemand onmiddellijk laten uitgaan naar datgene wat jij als belangrijkste beschouwd op dit rapport. Andere voorbeelden van attentieve eigenschappen zijn:

1. Lengte, breedte,
2. Orientatie
3. Vorm
4. Grootte
5. Kader
6. Kleur/Intensiteit van de kleur
7. 2D-positie

Bij preattentieve eigenschappen maken we onderscheid tussen wel of niet kwantitatief. Naast kwantitatieve informatie hebben we ook categoriale informatie. Bij categoriale informatie gaat het om de logische verdeling van de gegevens.

9.4.3 Rapportrichtlijnen

Welke boodschap wil je met een rapport overbrengen?:

1. Vergelijking van nominale waarden
2. Chronologische vergelijking
3. Positiebepaling
4. Verhoudingen
5. Afwijking
6. Verdeling
7. Correlatie
8. Geografische componenten

9.4.4 Tabel versus grafiek

Een plaatje zegt meer dan 1000 woorden.

9.5 Power View

Zie Handboek Power BI.

1. Power View is een tool om self-service BI te bevorderen.
2. Power View vereist een semantisch model.

9.6 Tot Slot

Goede front-ends geven gebruikers inzicht (intelligence) in hun business.

Een strategy map maakt inzichtelijk welke doelstellingen voortkomen uit welke strategie.

Slicer is een grafische vorm waarin een filter kan worden weergegeven.

Operationele rapporten hebben over het algemeen striktere latency-eisen dan managementrapportages.

Wildgroei rapporten: er zijn zoveel rapporten dat niemand meer weet welk rapport welke informatie toont.

Een dashboard is een overzicht van belangrijke informatie waaronder eventueel een scorecard.