Samenvatting
Deel I: Sterschemas en het onderhoud
Dit deel is sterk geïnspireerd door de boeken en artikelen van Kimball. Sterschemas staan hierin centraal. Behandeld worden de verschillende soorten dimensietabellen. Verder uiteraard de manieren waarop historie in de dimensies kan worden aangepakt.
In het hoofdstuk 'het pletten van een ster' introduceren we het zogenaamde OASI concept (One Attribute Set Interface). Aan de hand hiervan komen we tot de conclusie dat sterschema’s in principe technische constructies zijn, alhoewel het dimensie begrip ook in de gebruikers wereld een rol kan spelen. Maar vaak is het dan ook verstandig om een onderscheid te maken tussen technische dimensies (= tabellen in het sterschema) en gebruikersdimensies. Verder blijkt bijvoorbeeld iets als ‘aggregaat navigatie’ nu heel eenvoudig uit te leggen, met andere woorden het OASI-concept heeft ook didactische waarde.
Ook sterk op het inzicht gericht is hoofdstuk 8 waarin we het verband zoeken (en vinden!) tussen sterschema’s, sneeuwvlokken en OASI’s enerzijds en ‘gewone’ ER-diagrammen anderzijds. Dit is bijvoorbeeld van belang wanneer men, model gedreven, een sterschema wil genereren. Dus eigenlijk voer voor tool-bouwers. Toch wordt ook door praktijkmensen het verhoogde begrip van deze zaken erg gewaardeerd.
Dit deel is redelijk onafhankelijk van waar men staat in de architectuur discussie tussen Kimball en Inmon, waarop we in het derde deel dieper ingaan.
Deel II: Gebruikersontsluiting van een sterschema
Wanneer we eenmaal een database hebben ontworpen via de in deel I besproken dimensionale modelering-technieken en we zijn er ook nog in geslaagd om de database tabellen met data uit de bronsystemen te vullen (dat is vaak het lastigste) dan blijft er nog één onderdeel over. We moeten deze gegevens voor de eindgebruikers benaderbaar maken. Men zou kunnen zeggen: geef de gebruikers een SQL hulpmiddel en klaar. En in de begintijd kwam men daar wel mee weg. Je ziet zelfs dat Kimball soms nog met argumenten om de hoek komt die te maken hebben met het idee dat de gebruikers zelf op deze manier hun rapporten maken. Maar tegenwoordig worden daarvoor Rapportage tools en OLAP-tools gebruikt en die moeten ingericht (geconfigureerd) worden.
Nu is dit gedeelte meestal niet het grootste struikelblok bij projecten. Er zijn goede tools en wizards beschikbaar. Toch zijn er een aantal conceptuele aspecten een aparte bespreking waard. Het gaat dan met name om meetwaarden een hiërarchieën. Verder worden ook de karakteristieken van dergelijke tools besproken.
Deel III: Architectuur en Data Vault
In dit deel gaan we na wat de discussie tussen Kimball en Inmon nu precies inhoud. Nadat we zelf ook kleur hebben bekend, gaan we na wat voor consequenties voor de modellering van het Centrale (‘Enterprise’) Datawarehouse dit heeft. Dit moet volgens Inmon immers een genormaliseerde relationele database worden, waarin echter wel ook historie moet worden bijgehouden. Wanneer we deze punten combineren met het idee dat ‘business entiteiten’ (zoals Klant, Product, Factuur, etc, etc) naast hun identificatie zoals die in de bronsystemen wordt gehanteerd (KlantCode, ProductNummer, Factuurnummer, etc, etc) ook een betekenisloze sleutel krijgen, dan komen we op een vrij natuurlijke manier uit op datgene dat Dan Linstedt in de markt heeft gezet onder de naam ‘Data Vault’. We gaan diep op de structurele aspecten hiervan in. We sluiten het deel af met een tweetal hoofdstukken die geavanceerdere historie begrippen behandelen.
Thuiswinkel Waarborg