Dit is de eerste in een serie blogs over het structureren en indelen van data. Daarbij wil ik een lans breken voor het 6 lagen model van Malcolm Chisholm. Dit model is al 15 jaar oud en heeft absoluut niet de aandacht gekregen die het verdient.

In deze eerste aflevering zal ik het model introduceren en uitleggen hoe het werkt. In de volgende posts kijken we wat de waarde van dit model is voor de wereld van Business Intelligence en Data Warehousing.

Maar… Data is toch data?

Nou, niet helemaal. Sommige data is meer data dan andere data – in de zin dat sommige data veel meer betekenis – en meer waarde – heeft dan andere. Achter een eenvoudig record in de landen tabel: UA - Ukraine kan een wereld van betekenis schuilgaan: is dit in- of exclusief Volksrepubliek Donetsk en Loegansk? En de Krim? Wat gebeurt er met gegevens die betrekking hebben op feiten van voor 2014 op de Krim? Horen die nu onder Rusland thuis?

Deze issues kunnen, afhankelijk van de core business van je organisatie, enorme impact hebben en tot veel onduidelijkheid leiden. Veel groter dan de datum 15 november 2015 in het veld 'Date Created' in de User tabel…

En wat dan nog?

Dit is precies waar het 6 layers of data model van Malcolm Chisholm om de hoek komt kijken. Aan de hand van dit model kun je vooraf een gefundeerde inschatting maken over de waarde van bepaalde data, hoe je deze het beste kunt behandelen – en ook van de mogelijke problemen die je daar tegenkomt.

Stel je voor, dat de directeur bij je komt en zegt: We gaan onze sales reorganiseren. Dan worden onze reports met sales trends zeker waardeloos? En jij kunt dan zeggen: Geen probleem, daar heb ik in het data warehouse ontwerp al rekening mee gehouden. Hoe cool is dat?

Goed, tot zo ver over waarom dit model waardevol is. Laten we er eens naar kijken.

 Schermafbeelding 2015 12 07 om 11.21.33

Het model bestaat dus uit 6 lagen, aan de hand waarvan we gegevens in een database kunnen indelen. Iedere laag bevat een specifiek soort data, met de bijbehorende eigenschappen.

De eerste laag is de Meta Data: de beschrijving van de data in de overige lagen. Denk hierbij gewoon aan tabelnamen, datatypen, enzovoorts.

De tweede laag is Reference Data: de code-waarde tabellen. Denk hierbij aan land- of statuscodes, etcetera. Dit zijn vaak kleine tabellen, met een beperkte hoeveelheid kolommen en records – maar in extreme gevallen valt de helft van het aantal tabellen in deze categorie.

Laag drie bevat de Enterprise Structure Data: de beschrijving van de organisatie. In deze categorie vinden we bijvoorbeeld afdelings- en grootboekstructuren.

Daaronder volgt de Transaction Structure Data. Grofweg is dit alle data die nodig hebt voordat je een ‘transactie’ (bijvoorbeeld een verkoop) kunt registreren. Denk hierbij aan klanten, producten, gebruikers, winkels, ...

De Transaction Activity Data is de laag waar het in OLTP systemen om draait: het vastleggen van transacties. In- of verkooporders, facturen, enzovoorts.

En tot slot de Transaction Audit Data: dit zijn, ruwweg, de logging tabellen. Denk hieraan bij mutatielogging, audit trails, etcetera.

Wat kun je hier nu mee?

 

200109 chisholm 1

Bron

Kijkend naar deze lagen, kunnen we een aantal algemene conclusies trekken, bijvoorbeeld:

  • Naarmate je hoger in het model komt, is de hoeveelheid data kleiner, maar de betekenis per data element groter
  • Dit impliceert dat data kwaliteit belangrijker is naar mate je hoger in het model komt
  • Een foreign key verwijst meestal naar een tabel in een hogere laag, soms naar een tabel in de zelfde laag, maar zelden naar een tabel in een lagere laag
  • Master Data management heeft betrekking op de lagen 2, 3 en 4, maar:
  • Klassieke MDM systemen richten zich meestal op de 4e laag (Transaction Structure Data)

Tot zo ver de introductie van het model. Waarom zouden we dit model (zeker als BI-ers) nou moeten omarmen? Daarover meer in een volgende post…

 

Deze website maakt gebruik van cookies: meer informatie