SQL en rdbms’en zijn tegenwoordig, samen met SQL front-ends om queries op niet-relationele gegevens te ondersteunen, sleutelcomponenten. Toch is er nog een ernstige beperking. Complexere beslissingsondersteunende activiteiten vergen ad-hoc toegang tot een brede verzameling gegevens, gedefinieerd in meerdere dimensies.
Dit betekent dat gegevens in tabellen in een willekeurige volgorde worden uitgelezen. Een ad-hoc meerdimensionaal systeem zou hiervoor een groot aantal SQL-queries genereren. Elke query zou zeer veel gegevens ter verwerking naar de PC-client sturen. Dit leidt tot onaanvaardbare prestatie-problemen, netwerk-overbelasting en heel grote PC’s. Daarom is Online Analytical Processing bedacht. In een Olap-systeem draait een Olap-processor op de server. De client stuurt een n-dimensionale aanvraag op hoger niveau over het netwerk en ontvangt alleen de gewenste gegevens. Onlangs heeft dr E.F. Codd, de geestelijke vader van het relationele model (en verklaard tegenstander van slechte implementaties daarvan, inclusief SQL), zijn licht laten schijnen over de regels waaraan een Olap-server moet voldoen. Hopelijk ontstaat er een standaardtaal om client en Olap-server aan elkaar te koppelen. Het Olap-concept is echter al vrij oud; het belangrijkste produkt is SAS.
Een Olap-server is op verschillende manieren te implementeren. Hij kan beschikken over een eigen gespecialiseerde database in een compleet pakhuis-produkt. SAS lijkt hiervan het enige voorbeeld. Het kan ook een gespecialiseerde database zijn, zoals Arbour Essbase, dat afhankelijk is van third-party tools, of een front-end voor andere databases, met name standaard rdbms-produkten. Verder komen combinaties van deze opties voor, waarbij sommige gegevens zich binnen en andere zich buiten het Olap-systeem kunnen bevinden. In dat geval worden communicatiepoorten gebruikt. Merk op dat SQL nog steeds gebruikt wordt, inclusief de vertalers naar niet-relationele gegevens – maar alleen door de Olap-server, niet door de client.
Merk ook op dat er behoefte is aan dictionaries die de gebruiker wegwijs maken in de Olap-machine en aan meta-databases voor het beheren, laden en routeren van SQL-aanvragen. Ook deze kunnen ingebed zijn in het Olap-produkt (SAS) of in third-party repositories. Verder is er een trend om gegevens voor gebruikers en voor operationeel beheer te combineren in één repository; wellicht convergeert dit met case- en andere ontwerptools.
Veel gebruikers stellen prijs op ad-hoc queries, toegesneden op hun specifieke behoeften. Zulke queries hebben echter geen vast patroon, en moeten daarom volledig geïnterpreteerd worden. Dit vermindert de prestatie, al zijn de moderne query-optimalisators op de servers tegenwoordig erg goed. Voorgedefinieerde queries blijven efficiënter; men kan ze tunen, waarbij te profiteren valt van de beschikbare faciliteiten voor database-beheer.
Geparametriseerde queries zijn ook efficiënter: doordat ze voorgedefinieerd zijn, gebruiken ze bekende tabelstructuren optimaal. Toch geven ze de eindgebruiker geen volledige vrijheid. Echter, slechte standaard query-routines veroorzaken een groot deel van de behoefte aan ad-hoc systemen. Een hybride oplossing is het bieden van standaard queries, waarbij men tegelijkertijd de gebruiker volledige vrijheid geeft in het kiezen van PC-tools om de standaardgegevens te bewerken. Deze techniek wordt in veel pakketten toegepast. Deze bevatten een module om ’s nachts op basis van bepaalde parameters gegevens uit de produktiedatabases te halen. De resulterende gegevens worden naar een lineair bestand geschreven, in het formaat van een standaard spreadsheet. De PC-gebruiker kopieert dit bestand naar zijn eigen PC en spreadsheet. Met behulp van een voorgestructureerde SQL back-end die toegang heeft tot gegevens in het pakhuis valt een online variant van deze techniek te realiseren.
Om twee redenen is het wenselijk dat gebruikers beschikken over ad-hoc tools. De eerste is de gebruiker die de gegevens moet doorspitten, op zoek naar niet goed vooraf te definiëren combinaties (data-mining). Dit vergt geïnterpreteerde ad-hoc faciliteiten. De tweede zijn de gebruikers die ad-hoc tools nodig hebben om hun eigen behoeften te definiëren en vervolgens telkens dezelfde query gebruiken. Deze klasse van queries moet opgespoord worden om ze te optimaliseren. Dit is een enorme verbetering tegenover de klassieke rapportgeneratoren.
Veel queries moeten worden geïnterpreteerd. Standaard queries kunnen echter het concept gebruiken van procedures die zijn opgeslagen in rdbms’en. Deze stored procedures zijn essentieel voor transactie-applicaties (zowel lezen als schrijven). Bovendien maken ze het veel eenvoudiger om de prestaties van een pakhuis te verbeteren. Twee obstakels staan het gebruik van opgeslagen SQL-procedures in het pakhuis nog in de weg. Ten eerste willen sommige gebruikers niet toegeven dat ze in feite standaard queries benutten, omdat dit hun status als ad-hoc gebruiker bedreigt. Ten tweede gebruiken de PC-tools SQL alleen lokaal, meestal via een Odbc-interface. Odbc biedt wel enige ondersteuning voor opgeslagen procedures, maar dit wordt weinig toegepast, omdat elk database-produkt er een eigen interface voor heeft. Hieruit volgt dat meer specifieke eis-produkten opgeslagen procedures veelal beter ondersteunen. Op dit gebied is de interactie tussen eindgebruiker en degenen die het gegevenspakhuis ondersteunen voor veel verbetering vatbaar.
