OLAP meets SQL

De taal SQL is qua functionaliteit geschikt om de meeste - misschien wel alle - OLAP-vragen te beantwoorden. De meest complexe joins kunnen geformuleerd worden, met group-by kunnen gegevens geaggregeerd worden en met diverse functies kunnen statistische berekeningen uitgevoerd worden. Kortom, als we met een OLAP-tool een SQL-databaseserver benaderen, is functionaliteit niet het probleem. Het probleem is performance. Een doorsnee SQL-databaseserver heeft nog steeds moeite een vraag die door het OLAP-tool gegenereerd wordt binnen een acceptabele tijd te beantwoorden. Die responstijd kan uiteenlopen van enkele seconden tot vele uren. Toen er enkele jaren geleden OLAP-tools op de markt kwamen, zijn de leveranciers van de databaseservers dan ook intensief op zoek gegaan naar mogelijkheden om de performance te verbeteren.

Eerst werd de oplossing gezocht in krachtigere hardware. Iedereen had het over het belang van parallelle machines en parallelle databaseservers. Vervolgens werden speciale indexvormen, zoals de multi-tabel index, de conditionele index en de bitmap-index, toegevoegd. Vooral de laatste is een aanwinst. Ook hebben sommige leveranciers hun optimisers geleerd vraagvormen te herkennen die door OLAP-tools veelvuldig gegenereerd worden en daar efficiënte verwerkingsstrategieën voor te verzinnen.

De zoektocht heeft er ook toe geleid dat het SQL-dialect van bijna alle databaseservers uitgebreid werd met taalconstructies waarmee typische OLAP-vragen eenvoudiger geformuleerd kunnen worden. Met als effect dat de optimiser efficiëntere strategieën kan verzinnen. RedBrick kwam met de starjoin en functies om bijvoorbeeld voortschrijdende totalen en gemiddelden te berekenen. DB2 en MS SQL Server zijn zodanig uitgebreid dat met één instructie een gehele kubus gegenereerd kan worden.

Ondanks al deze verbeteringen, blijven sommige OLAP-vragen langzaam. Dit is de hoofdreden waarom in veel datawarehouses tabellen aan elkaar geplakt worden (via denormalisatie) om gegevenstoegang te versnellen. Veelvuldig worden aggregatietabellen gecreëerd om allerlei lastige, online berekeningen te voorkomen. De antwoorden liggen reeds opgeslagen. 

Deze aanpak kent echter een aantal nadelen. Bijvoorbeeld, software moet speciaal geschreven worden waarmee de aggregatietabellen bijgewerkt worden indien de originele gegevens veranderen. Een ander nadeel is dat aan elke (relevante) gebruiker bekend gemaakt moet worden dat deze aggregatietabellen bestaan. We moeten ons realiseren dat deze tabellen niet automatisch ingezet worden. We moeten alle rapporten zodanig aanpassen dat de vraag op de aggregatietabellen afgevuurd wordt.

Het werd tijd dat hier wat aan gedaan werd. Oracle heeft hier als eerste een oplossing voor verzonnen. Bij de nieuwe versie van de Oracle-databaseserver kunnen tabellen met geaggregeerde gegevens gedefinieerd worden die gekoppeld zijn aan de tabellen met de originele gegevens. Deze aggregatietabellen worden automatisch door Oracle bijgewerkt indien de originele gegevens veranderen. 

Het interessante aan dit nieuwe type tabel is dat ze niet direct door gebruikers benaderd kan worden. Nee, de OLAP-vragen worden nog steeds afgevuurd op de originele tabellen. Echter, indien bij een vraag een aggregatie wordt gevraagd, dan kijkt de databaseserver zelf of er een aggregatietabel aanwezig is en of het nuttig is deze te gebruiken. Zo ja, dan wordt de OLAP-vraag geherformuleerd en afgevuurd op de aggregatietabel. Let wel, dit gebeurt allemaal achter de schermen. De gebruiker heeft hier geen weet van. Dit biedt de mogelijkheid om deze aggregatietabellen te creëren en te verwijderen wanneer noodzakelijk, maar dit heeft geen effect op alle OLAP-vragen en rapporten die operationeel zijn. 

Beheerders van datawarehouses, die bekend zijn met het creëren van aggregatietabellen, weten hoeveel werk het is deze tabellen te onderhouden. Het is nu mogelijk deze tabellen met een veel groter gemak te creëren. Hopelijk volgen de andere leveranciers snel Oracle's voorbeeld.