In de beginfase van ‘datawarehousing’ lag het accent op de technologie. Door de interesse voor onderwerpen als crm (customer relationship management) en analysetechnieken, is de aandacht verschoven van minder technische zaken naar onderwerpen als wat de manager eigenlijk nodig heeft. Toch is er één hardnekkige, technische discussie die maar aandacht blijft krijgen: moet het ontwerp van het gegevenspakhuis opgebouwd worden volgens een sterschema of een sneeuwvlokschema?
Voor de niet-ingewijden, praten over ster- en sneeuwvlokschema’s is gewoon een manier om het woord denormaliseren te omzeilen. En die term kent u waarschijnlijk nog wel, het heeft te maken met het ontwerpen van relationele databases. In een notendop, denormaliseren houdt in dat gegevens op een bepaalde manier gedupliceerd worden. En een sterschema is een gedenormaliseerde versie van het equivalente sneeuwvlokschema. Ze bevatten dezelfde gegevens, maar zijn anders georganiseerd.
Nog steeds zijn er enkele specialisten die er van overtuigd zijn dat sterschema’s, door hun gedenormaliseerde structuur, altijd de prestaties verbeteren van de vragen die door ‘warehouse’-gebruikers gesteld worden. Een enkeling geeft ook alternatieve argumenten, maar prestatie is toch wel het doorslaggevende argument om voor een sterschema te kiezen. Het is echter een ongeldig argument waardoor er onnodig langzame gegevenspakhuizen gecreëerd worden en er dure hardware aangeschaft moet worden om alsnog de gewenste prestaties te realiseren.
Het valt me altijd op dat de voorstanders van sterschema’s de beloofde prestatieverbeteringen zelden onderbouwen met cijfers. Ze poneren het gewoon als een wetmatigheid, zoiets als: water stroomt altijd naar beneden. Alsof een ‘join’ (operatie om tabellen te combineren) van x tabellen per definitie langzamer is dan die van op x-1 tabellen. Was het leven maar zo makkelijk. Die prestaties zijn afhankelijk van vele aspecten, waaronder aantal rijen, aantal verschillende waarden, beschikbaar intern geheugen en de distributie van waarden.
Waar komt dit misverstand dan vandaan? En waarom zijn er toch zoveel mensen mee bezig? Laten we eens een vergelijking trekken met ‘formule 1 racen’. Stel dat ik ben uitgenodigd in de pits. Tijdens de race wordt mij gevraagd een van de auto’s sneller te maken. Een leuke uitdaging, echter, omdat ik geen auto-expert ben, ben ik beperkt in de trucs die ik kan toepassen. Ik zal me moeten beperken tot het kantelen van de voor- en achterflappen en ik zal wat spelen met de bandenspanning. Waarom? Omdat ik ze dat op televisie heb zien doen, en ik denk ongeveer dat ik begrijp hoe het werkt: hoe platter de flappen, des te minder de wrijving op de rechte stukken en hoe meer rechtop de flappen des te meer kleefvermogen in de bochten. Een expert kent nog veel meer knopjes waaraan hij kan draaien.
Het blind kiezen voor een sterschema om de prestaties te verbeteren, is vergelijkbaar met mijn gestuntel met de flappen. De andere, meer interne technieken zijn onbekend en dus beperken ontwerpers zich tot de technieken die ze wel kennen en begrijpen.
Het advies is, als u niet alle hoeken en gaten van een relationele databaseserver kent, dus als u bijvoorbeeld niet eens weet wat een ‘freespace’-parameter is, houdt u zich dan niet bezig met prestatiezaken! Laat dat maar over aan de specialisten. Gebruik prestatie dus niet als argument om voor een sterschema te kiezen.
Kijken we naar de toekomst van gegevenspakhuizen, dan zal ook daar het sterschema problemen gaan geven. Ten eerste, we zien langzaam het gegevenspakhuis evolueren van een statische naar een dynamische omgeving. De snelheid waarmee de gegevens in gegevenspakhuizen bijgewerkt moeten worden, wordt opgevoerd. Indien dit gebeurt, zullen de gedenormaliseerde databasestructuren die snelheid negatief beïnvloeden. Gedupliceerde gegevens vertragen altijd de prestatie van het bijwerken van gegevens.
Ten tweede, databaseservers zijn langzaamaan aan het veranderen in zogenaamde ‘main-memory’ ofwel ‘in-memory’ databaseservers. Dit wil zeggen dat ze zullen proberen zoveel mogelijk gegevens in geheugen vast te houden en ze zullen trachten vragen te beantwoorden zonder de harde schijven hiervoor te benaderen. Bekende leveranciers, zoals IBM, Microsoft en Oracle, zijn hiermee bezig, maar ook leveranciers van nieuwe producten, zoals Bull, Polyhedra en Times-Ten, volgen deze route. De algoritmes in deze producten werken het best, als alles in het intern geheugen past. We moeten dus proberen onze databases zo klein mogelijk te houden, omdat de kans dan groter is dat alles in het geheugen past. Zoals reeds vermeld, een ontwerp waar gebruik gemaakt wordt van sterschema’s is gedenormaliseerd, dus bevat dubbele gegevens, dus maakt de database groter. U kunt zelf wel de conclusie trekken.
Laten we gewoon realistisch zijn. Soms is een sterschema sneller en soms een sneeuwvlokschema. Vraag uw database-experts wat het beste is voor uw situatie. En vergeet niet, de oplossing die nu de snelste is, hoeft dat bij een volgende versie van uw databaseserver niet meer te zijn.
Eigenlijk doet de gehele discussie rond sterschema’s denken aan het volgende. De Sumerieërs wisten zo’n 5000 jaar geleden reeds dat de aarde plat was. Die kennis is ooit verloren gegaan, want een lange tijd dachten we dat de aarde plat was. Totdat iemand het licht zag: de aarde was toch rond. Laten we maar hopen dat de periode waarin we dogmatisch sterschema’s toepassen niet zo lang zal duren als de aarde-is-plat periode.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
