Granulariteit (gegevens)

Uit Wikipedia, de vrije encyclopedie

Granulariteit (lett. korreligheid) is een term die bij het ontwerpen van datawarehouses wordt gebruikt, ze geeft aan in welke mate er detail-gegevens van de entiteiten aanwezig zijn.

Een lagere granulariteit (grove korreligheid) geeft aan dat er -op een zeker niveau- minder details worden opgeslagen.

Aangezien datawarehouses vaak erg veel gegevens moeten opslaan, en deze gegevens zich vaak herhaald aandienen, ontstaan hoeveelheden gegevens die zonder maatregelen praktisch niet meer benaderbaar zijn, bijvoorbeeld doordat een simpele opvraging vijfhonderd uur duurt. Het ontwerp van het gegevensmodel dient deze situaties dus te voorzien en voorkomen. Het sturen van de granulariteit is een van de belangrijkste technieken voor het voorkomen van het 'vastlopen' van een datawarehouse, naast andere technieken als bijvoorbeeld partitioneren en denormaliseren. Een totaalontwerp is vaak een mix van al deze technieken, en denormalisatie en partitionering zijn vaak automatisch deel van het granulariteitsontwerp.

Het bij het ontwerp van een datawarehouse benodigde bepalen van de gewenste mate van granulariteit, is meestal een afweging tussen de opslag- en opvraagkosten enerzijds, welke afhangen van de -vaak grote- hoeveelheden gegevens, en de mogelijkheid om de gegevens later nog te kunnen doorzoeken op verbanden, de zogeheten datamining, anderzijds.

Techniek[bewerken | brontekst bewerken]

Vaak worden de gegevens opgedeeld in verschillende tijdframes. Ervan uitgaande dat recente gegevens telkens vaker worden benaderd dan oudere gegevens, worden deze oude gegevens in een aparte tabel ondergebracht. Vaak is het zo dat de antwoorden die men wenst op basis van oude gegevens ook kunnen worden gegeven met gecumuleerde gegevens, zodat op dit andere niveau geen detailgegevens nodig zijn. De gegevens van de lage niveaus worden na een zekere tijd 'gecondenseerd' tot gegevens op een hoger niveau. De exacte details van deze condensatie hangen af van de specifieke situatie.

Hierdoor blijven de tabellen dicht bij het operationele niveau klein en bewerkbaar, en de tabellen op strategisch niveau groeien meer beheersbaar. De keerzijde is dat de detailgegevens uit het verleden niet meer analyseerbaar zijn wanneer ze daadwerkelijk verwijderd worden, men verliest dus drill-down mogelijkheden.

Voorbeeld[bewerken | brontekst bewerken]

Een telecomprovider heeft een gegevensbank met gegevens over tekstberichten. Honderdduizend klanten die gemiddeld twee boodschappen per uur sturen genereren dan per dag bijna vijf miljoen detailrecords. Wanneer deze records voor een jaar worden opgespaard komen we voor deze tabel op ongeveer 1.8 miljard records. Bij deze hoge granulariteit ontstaan zonder verdere maatregelen vroeg of laat problemen.

boodschappen
nr klant datum tijd ontvanger boodschap
1 1 22/02/2008 22:23 123 456 78 Hallo, we zijn er hoor.
2 1 10/12/2007 07:22 335 574 82 We komen eraan hoor, groetjes Pap.
3 2 04/03/2008 07:22 335 574 82 Klopt, 122.50. Tot zo.
4 2 03/10/2007 07:22 335 574 82 Het wordt toch de eerste. Jan.

Om dit te voorkomen worden gegevens ouder dan tien dagen overgebracht naar een volgend detailniveau, zeg een weekniveau. Het hangt van de specifieke gegevensvragen uit de organisatie af welke gegevens er op dit niveau moeten blijven bestaan. Een keuze is om van alle records van één klant van één week één detailrecord te maken met daarin de totalen voor die week. Dit reduceert en fixeert de inhoud van de hoofdtabel, aangezien er nu altijd maar voor een week aan records in blijft staan, circa 35 miljoen records. De tabellen zien er dan dus zo uit:

boodschappen
nr klant datum tijd ontvanger boodschap
1 1 22/02/2008 22:23 123 456 78 Hallo, we zijn er hoor.
2 2 04/03/2008 07:22 335 574 82 Klopt, 122.50. Tot zo.
weektotalen
klant jaar week aantal
1 2008 5 22
2 2008 5 437

Query's die op deze deelverzameling (berichten van deze week) betrekking hebben zullen dus altijd -eigenlijk zolang het weekvolume binnen normale grenzen blijft- goed blijven werken. Op het weekniveau 'ontstaat' nu dus één record per klant per week, wat per jaar 5.2 miljoen records behelst. Samen met de 35 miljoen actuele records 'maar' plusminus 40 miljoen records per jaar, tegen de 1.8 miljard in het niet gesplitste model. Natuurlijk bevat het model nu ook procedures waaronder de gegevens van het ene naar het andere niveau worden gebracht. Doordat het model nu een totaal bevat (het aantal boodschappen in een week), is het gedeeltelijk gedenormaliseerd, er treden dus mogelijk update-anomalieën op.

Gevolgen[bewerken | brontekst bewerken]

Het toepassen van deze granulariteitsdiversificatie van de gegevens heeft vaak als belangrijkste gevolg dat het systeem bruikbaar blijft bij toenemend succes en gegevensvolume. De granulariteit van een gegevensverzameling heeft ook een niet-directe invloed op de systeemprestaties, aangezien niet alleen de gegevensverzamelingen zelf groter worden, maar ook bijvoorbeeld de indexbestanden en besturingssystemen worden beïnvloed.

Zie ook[bewerken | brontekst bewerken]