Sommige organisaties hebben hun datawarehouse ofwel gegevenspakhuis opgezet volgens een drielagig model. Een optie, waaraan IBM de voorkeur geeft, behelst het aanmaken van een enorm centraal pakhuis, met gedetailleerde gegevens uit allerlei bronnen.
Men gebruikt deze database niet direct, maar haalt er geselecteerde gegevens uit en stuurt die naar kleinere afdelingsdatabases. Deze kleine databases, ook wel datamarts genoemd, voorzien in gegevens voor direct gebruik door zogenaamde kenniswerkers. Dit is een robuust en, als de kosten te rechtvaardigen zijn, wenselijk model. Datamarts voorzien in gespecialiseerde, lokale verwerking, terwijl het uitgebreide centrale pakhuis dient voor globaal, de afdelingen overschrijdend werk. Ook zijn wijzigingen op verzoek van afdelingen eenvoudiger aan te brengen, omdat de bron het centrale pakhuis is, en niet een groot aantal produktiedatabases.
Echter, sommige organisaties hebben zoveel soorten produktiedatabases dat de centrale database meer is gericht op operationele gegevens dan op kenniswerkers. Dan moeten de gegevens in het centrale pakhuis vluchtig zijn, omdat ze bedrijfstoepassingen ondersteunen. Ze worden langer bewaard dan bij online bedrijfstoepassingen, maar niet zo lang als de in een informatiepakhuis opgeslagen historische gegevens.
Als in het pakhuis-concept gegevens van de ene naar de andere database verplaatst zijn, moeten ze nog verwerkt worden. Replicatie van gegevens tussen twee databases is niet adequaat. Het data-extractieproces moet gegevens uit diverse bronnen vastleggen en vervolgens verwerken om ze te comprimeren en hun validiteit te controleren. Verder moeten vertaalslagen worden ingebouwd, om tot gemeenschappelijke formaten en naamconventies te komen. Cruciaal is de implementatie van een meta-database in een vroeg stadium. Deze bevat de voor een betrouwbaar en efficiënt extractie- en verwerkingsproces benodigde gegevens over gegevens. Aan te bevelen is gebruik van tools voor gegevensontwerp, inclusief tools om oude en diverse data-dictionaries, Cobol-copybooks en dergelijke te re-engineeren.
Als een organisatie meerdere afdelingsdatamarts gebruikt, is replicatie echter een waardevol hulpmiddel. Het is vooral nuttig als afdelingen dezelfde functie op verschillende locaties uitoefenen, zoals diverse verkoopkantoren. Elke locatie is dan verantwoordelijk voor de kwaliteit en geldigheid van lokale gegevens. Sommige gegevens worden gerepliceerd naar andere locaties. Dit is nuttig bij vergelijking van lokale trends met landelijke of wereldwijde ontwikkelingen. Het repliceren van records, velden of transacties is met de huidige rdbms-produkten te automatiseren. Replicatie kan al bijna real-time plaatsvinden, maar voor datamarts is het mogelijk een wachtrij op te zetten die regelmatig wordt bediend. Desondanks is replicatie nuttiger als techniek voor het synchroniseren van produktiedatabases die lokaal worden gewijzigd dan voor datamarts, die centraal te beheren zijn.
De organisatie moet inzien dat het beheer van een pakhuis een taak voor de IT-afdeling is, al zijn de eindgebruikers verantwoordelijk voor de manier waarop ze het pakhuis benutten. Een investering in de database en de bijbehorende tools, zoals de meta-database, moet daarom uit een IT-gerelateerd budget komen. Verder moeten de beheertools flexibel, krachtig en gebruiksvriendelijk zijn, al vereist de operationele ondersteuning niet zulke geavanceerde tools als het ad hoc modelleren door eindgebruikers. Investeren in specialistische tools, 4GL’s en dergelijke is essentieel; conventionele 3GL-programmeertechnieken kunnen zo’n flexibel concept niet dragen. Tot slot is cruciaal dat de hele organisatie vanaf het begin bij de operatie betrokken wordt.
Gegevenspakhuizen worden nu, en in de nabije toekomst, gebouwd rond relationele database-produkten. Doordat de meest voorkomende query read-only is, kan men gespecialiseerde hardware voor parallelle verwerking, gericht op het gegevenspakhuis, benutten. Het probleem van parallelle hardware en transactieverwerking is irrelevant. Gespecialiseerde hardware-‘hulpjes’ op mainframes voor DB2 zijn eveneens bruikbaar. Desondanks moeten rdbms-produkten op belangrijke punten worden uitgebreid. Dit heeft geleid tot nieuwe onderzoeksactiviteiten en software-produkten.
De eerste ontwikkeling is het structureren van standaard rdbms-produkten, zoals Ingres, Sybase en DB2/6000, voor het gebruik van parallelle queries. De volgende stap is het ondersteunen van een eenvoudig binair gegevenstype, Blob, dat plaatjes als records kan bevatten. De dreiging van object-georiënteerde databases betekent echter dat een meer geavanceerde ondersteuning van objecten nodig is. Dit betekent idealiter: door de gebruiker te definiëren abstracte datatypen. Verder benut de onderliggende fysieke I/O-technologie in huidige rdbms-produkten een vaste gegevenslengte. Dit moet radicaal worden omgegooid om te kunnen omgaan met de variabele records en objecten in de nieuwe systemen, die met name belangrijk zullen zijn in gegevenspakhuizen. Hoewel veel van deze uitbreidingen transparant zullen zijn voor SQL, zullen andere tot uitbreiding ervan leiden. Hopelijk zijn de nieuwe standaarden voor SQL-extensies grondiger en beter ontworpen dan de huidige taal. Veel van de bezwaren tegen gebruik van relationele technologie voor objectsystemen zijn gebaseerd op de feitelijke rdbms-produkten en SQL, terwijl deze het relationele model niet goed implementeren. De vraag naar uitbreidingen van SQL biedt de mogelijkheid om de standaard op te schonen. Dit zou de leveranciers dwingen de voorgestelde wijzigingen door te voeren. Dat is in hun eigen belang – anders zullen nieuwe ‘post-relationele’ en ‘object-georiënteerde’ databases de markt eroderen.
