Het oorspronkelijke toepassingsgebied van datapakhuizen is ondersteuning van beslissingsprocessen. Gegevens worden uit diverse productiesystemen samengebracht in een datapakhuis en daar eventueel verrijkt met externe gegevens.
Vervolgens mogen interne gebruikers de gegevens vrij gebruiken om allerlei rapporten te creëren. Er zijn ook andere toepassingsgebieden. Een die in opkomst is, is gerelateerd aan een ander hip onderwerp: de soa (service oriented architecture). Het datapakhuis kan dienst doen als gegevensbron voor diverse diensten van een soa.
In het kort: een soa is een busstructuur waarmee allerlei applicaties algemene services kunnen aanroepen. De aangeboden diensten (ofwel webservices) kunnen gloednieuwe, op zichzelf staande componenten of onderdelen van bestaande applicaties zijn. Veel van de aangeboden diensten hebben een opvraagkarakter. Door ze aan te roepen ontvangt de geïnteresseerde applicatie een antwoord in de vorm van een waarde of document. Voorbeelden van opvraagservices zijn: geef de adresgegevens van een bepaalde klant, geef alle gegevens van een bepaalde factuur en hoelang wacht een bepaalde klant gemiddeld met betalen?
Door de ontwikkeling van datapakhuizen zijn we ons de afgelopen jaren gaan realiseren hoe vervuild de gegevens in onze productiedatabases eigenlijk zijn. Indien we diensten op die productiedatabases zouden ontwikkelen, is de kans groot dat het antwoord van de service ook vervuild is. Het ligt daarom meer voor de hand om de gegevens uit een datapakhuis te halen, want bij elk pakhuis wordt veel tijd en geld besteed aan het opschonen van de productiegegevens voordat ze erin geladen worden. Services op datapakhuizen geven correctere antwoorden. Dit klinkt als een verstandig idee. Tevens is het ontwikkelen van een service op een datapakhuis relatief eenvoudig. Voor een kenner is dat een technologisch een-tweetje. Dus wat houdt ons tegen? Het is het ontwerp van het pakhuis dat roet in het eten kan gooien.
Een mogelijk probleem is de beschikbaarheid. Als de vragende applicatie vierentwintig uur en zeven dagen per week operationeel is, zal dezelfde beschikbaarheid van de service geëist worden. Veel datapakhuizen zijn niet met deze intentie ontwikkeld. Ze worden vaak ’s ochtends vroeg aangezet en rond het avondeten weer uitgezet. Ook zijn ze niet altijd met software gebouwd die non-stop kan draaien. Een conversie is dan noodzakelijk.
Een ander potentieel probleem is het niveau van aggregatie. Veel pakhuizen bevatten voornamelijk geaggregeerde gegevens, omdat de originele gebruikers vaak niet in gedetailleerde gegevens geïnteresseerd zijn. Een operationele applicatie zal juist wel gedetailleerde gegevens willen zien. Als besloten wordt om dan toch maar gedetailleerde gegevens te gaan registreren, zal het pakhuis fors in omvang toenemen. Alleen al die toegenomen omvang kan tot allerlei onverwachte problemen leiden. Het zal ook een negatieve invloed op de prestaties van rapporten hebben.
Veel gebruikers van een datapakhuis hebben geen gegevens nodig die tot op de seconden actueel zijn. Sommigen kunnen leven met gegevens die enkele weken oud zijn. Ook dat zal niet acceptabel zijn voor services. De aanroepende applicaties zullen accurate gegevens willen zien. Hiervoor moet de verversingsgraad fors opgevoerd worden. Dat kan leiden tot een herontwerp van het hele kopieerproces.
Ondanks het feit dat potentiële problemen eenvoudig te bedenken zijn, is het toch de moeite waard om te bestuderen of een datapakhuis de gegevensbron kan vormen voor enkele diensten van soa. Het zal er echter wel toe leiden dat het ontwerp van veel datapakhuizen grondig onder handen genomen moet worden. Hier ligt een uitdaging voor zowel klanten als de leveranciers van tools daarvoor.< BR>
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
