Produktiesystemen maken de ruwe gegevens aan. Daarom moet de database zowel te lezen als te schrijven zijn. Gezien de eisen aan de prestaties van de database moet deze geoptimaliseerd worden door een deel van de fysieke betekenis van tabellen, records en velden effectief te verbergen.
De transacties zijn hoofdzakelijk deterministisch. Veel organisaties leggen service level agreements op, die met name responstijden garanderen. Ook is het gebruikelijk om gegevens te archiveren; als een transactie voltooid is, wordt hij naar tape geschreven en van het direct-toegankelijke schijfsysteem verwijderd.
‘Kenniswerkers’ hebben totaal andere behoeften. De database moet het bedrijf zo simpel mogelijk weerspiegelen, zelfs als dit ten koste gaat van de prestaties. De behoeften betreffen wel het lezen van gegevens, maar niet het modificeren. De benodigde read-only database is dus eenvoudiger dan de databases die nodig zijn voor transactiesystemen. Moderne, parallelle hardware en database-managementsoftware zijn hierdoor ten volle te benutten. De queries die kenniswerkers op de database afvuren, kunnen zowel eenvoudig als ingewikkeld zijn. Veel queries zijn ad-hoc van aard, zodat de prestatie niet te voorspellen valt. Als een transactie en een applicatie dezelfde database gebruiken (wat in sommige gevallen moet), kan dit de sla’s geweld aan doen. Tot slot analyseert de kenniswerker vaak tijdreeksen. Hierbij verwerkt hij historische gegevens, die daardoor niet offline op tape te archiveren zijn.
De mogelijkheid bestaat dat opslag en verwerkingskracht op den duur zo goedkoop worden dat de geschetste conflicten geen gevolgen hebben, en dat één enterprise data server kosteneffectief voorziet in alle behoeften. Momenteel is er echter slechts één praktische oplossing: het ondersteunen van meerdere databases. Ruwe gegevens worden aan diverse produktiebronnen onttrokken en vervolgens verwerkt en opgeslagen in een aparte, speciaal voor de informatiegebruikers ontworpen database. Dit noemt men informeel ook wel data warehousing. Definieer een gegevenspakhuis voor het gemak maar als database(s), ontworpen voor de informatiegebruikers, gecombineerd met softwaretools om gegevens te selecteren, te laden en te beheren. De PC-georiënteerde tools voor de eindgebruiker vallen ook onder het algemene pakhuis-concept.
Gegevens in produktiedatabases worden voortdurend gewijzigd en zijn vluchtig. De kennisdatabase in een pakhuis accumuleert gegevens, waarbij de oudere data verouderen naarmate recentere worden toegevoegd. Deze gegevens zijn in wezen niet-vluchtig.
Dit duale systeemconcept vereist betrokkenheid en een realistisch budget. Het is moeilijk om een zinvolle uitspraak te doen over het rendement van zo’n investering. Om de kosten te rechtvaardigen is een gezamenlijke inspanning van de IT-afdeling en de andere afdelingen noodzakelijk. Het concept lost de genoemde conflicten op en maakt het mogelijk om de afzonderlijke systemen voor hun specifieke doeleinden te optimaliseren. Transactiesystemen hoeven dan geen uitgebreide querie-applicaties meer te ondersteunen, zodat de levensduur van legacy-applicaties en -databases (Vsam, IMS, Adabas, Idms etcetera) aanzienlijk te verlengen valt. De beschikbaarheid van een gegevenspakhuis kan de doorlopende ontwikkeling van nieuwe transactie-applicaties voor bestaande dbms’en stimuleren. Hierbij valt optimaal gebruik te maken van de hoge transactiecapaciteit die deze relatief simpele systemen bieden. Dit geldt vooral voor IMS en Adabas; de leveranciers van deze systemen blijven investeren in ontwikkeling.
Het is onwaarschijnlijk dat alle queries op basis van pakhuis-gegevens te beantwoorden zijn, zodat interfaces van PC-query-tools naar de produktiedatabases nodig blijven. Er zijn geen harde en snelle regels, maar het 80/20-principe lijkt haalbaar: 20 procent van de queries naar de produktiedatabases, 80 procent naar het pakhuis.
Toegang tot de produktiedatabases is te verschaffen door gateway-produkten, zoals Eda/SQL of Omniserver, die ook niet-relationele gegevens aankunnen. Als de transactiesystemen op een relationele database gebouwd zijn, kan men ook views gebruiken.
De database voor het pakhuis is of centraal voor het hele bedrijf, of opgesplitst in decentrale afdelingsdatabases, elk met meer specifieke deelverzamelingen van gegevens. Bij een centrale database zullen veel gebruikers via een wan gekoppeld zijn, wat enige prestatie- en capaciteitsproblemen met zich meebrengt. Gebruikers van afdelingsdatabases zullen vooral lokaal gekoppeld zijn. Bij een centrale database zijn echter zowel globale als lokale gegevens op te vragen. Beveiliging is hierbij een belangrijke zorg. Een gegevenspakhuis is bedoeld om gebruikers snel en makkelijk toegang te geven tot detailgegevens over het bedrijf, goed en slecht. Dit is precies waar de concurrent ook graag toegang tot zou hebben. Voor veel financiële mensen is dat het argument om zich te verzetten tegen de introductie van een pakhuis. Vooral het wan moet door beveiligingssystemen en encryptie beschermd worden. SNA en DCE zijn daarom aantrekkelijke opties, maar pas op voor simpele router-gebaseerde netwerken.
