De gestelde eisen aan een bedrijfsbreed monitoringsysteem worden steeds zwaarder en een snel groeiend aantal directies kiest ervoor om van een relationeel databasemanagementsysteem uit te wijken naar datawarehousing. Het verschil tussen 'gewone' database-technologie zit 'm onder meer in het concept, de data modelleringtechniek en de technologie.

Datawarehousing is een concept, terwijl datawarehouses (de materie) implementaties zijn van dit concept, gebruik makende van informatietechnologie. In essentie zegt het datawarehousingconcept dat het koppelen van verschillende databases (onderliggend aan transactiegeoriënteerde informatie-systemen) inefficiënt is, aangezien zij elk zijn geoptimaliseerd voor het stand alone verwerken van transacties. Het ontbreekt bovendien aan instrumentarium om verschillende gegevensbronnen efficiënt te verbinden en als zodanig te beheren, in het bijzonder de metadata. Naar mate het aantal gegevensbronnen toeneemt wordt een en ander steeds problematischer.

Datawarehousing schrijft voor om een organisatiespecifiek business-model te maken van de belangrijkste objecten en hun relaties. Met behulp van een dergelijk business-model kunnen de verschillende definities van een object worden geïntegreerd in één uniforme definitie, zonder dat een bepaalde afdeling of gebruikersgroep water bij de wijn hoeft te doen. Immers, via de eigen gebruikelijke definitie kan de gebruikersgroep het betreffende object blijven benaderen, omdat alle gangbare object-definities gekoppeld kunnen worden aan één object. Integratie van verschillende definities is dus een essentieel kenmerk van datawarehousing en datawarehouses, niet alleen van gegevens, maar ook van gegevensdefinities.

In tegenstelling tot transactiegeoriënteerde systemen waar strakke datamodelleringstechnieken worden toegepast om elke redundantie in de gegevensopslag te vermijden, zoals ER (entity-relationship) of EER (extended entity‑relationship), worden datawarehouses gebaseerd op één of meer multidimensionale gegevenskubussen (data cubes), ontworpen volgens de regels van het multidimensionaal modelleren. Multidimensionaal modelleren impliceert dat gegevens (facts) alleen kunnen worden opgeslagen als er een gemeenschappelijke relatie bestaat tussen twéé of meer objecten, c.q. een gegeven heeft twee of meer dimensies. Per definitie zijn deze objecten niet volledig genormaliseerd - redundantie is juist gewenst vanwege de hiërarchie in de dimensies. Relaties zijn geëxpliciteerd, waardoor een object in meer dimensies wordt benoemd.

Voor wat betreft resources en performance verhouden een transactiegeoriënteerde database

(OLTP - online transaction processing) en een analysegeoriënteerde datawarehouse (OLAP - online analytical processing) zich als performance staat tot performance in het kwadraat. Anders gezegd, de vereiste noodzakelijke toename in resources en performance in een transactie-omgeving bij een toenemend aantal gebruikers is vrijwel lineair, terwijl deze in een OLAP-omgeving bij een toenemend aantal gebruikers, gebruik en gegevensomvang - mede door de redundantie - bijna exponentieel zal zijn.

Derhalve is het voor de implementatie van datawarehouses al gauw noodzakelijk om parallelle hardware (CPUs, drive arrays), veel geheugen en geparallelliseerde database software aan te schaffen. Het moge duidelijk zijn dat deze items stuk voor stuk duur zijn, in het bijzonder de database-technologie.

Eén datawarehouse

Wanneer het implementeren van het datawarehouse-concept onvermijdelijk is - om reden van een beter beheer van de informatie-infrastructuur of het management kan niet meer zonder een snel, integraal inzicht op de business(performance) - is een aantal zaken te overwegen. Ten eerste: er zijn situaties denkbaar waarin er eerst één datawarehouse wordt ontwikkeld, waarvan vervolgens een aantal multidimensionale cubes wordt afgeleid, hetzij voor specifieke doeleinden (analyses), hetzij voor specifieke afdelingen/gebruikers. Anderzijds wordt vaak ten onrechte gedacht, dat er meteen een corporate datawarehouse zou moéten komen.

Alvorens zo'n groot meerjarenproject wordt gestart, dient men te analyseren welke afdelingen en personen er allemaal gebruik gaan maken van het datawarehouse, welke gegevens er allemaal nodig zijn en waar deze kunnen worden gevonden, of er veel overlap bestaat tussen het gegevensgebruik van de verschillende afdelingen, welke typen analyses de hoofdmoot zullen gaan vormen voor het datawarehouse en welke en hoeveel gegevens door de afdelingen zelf worden toegevoegd aan het datawarehouse. Deze vragen bepalen mede of er wel één allesomvattend datawarehouse moet komen, of dat het beter is dat bepaalde afdelingen een 'eigen' datawarehouse c.q. datamart krijgen.

Men moet zich ook van tevoren realiseren dat de organisatiestructuur, de organisatie- en managementcultuur en de mate van zelfbeschikking van afdelingen, werkmaatschappijen en divisies in sterke mate de kans van slagen bepalen van datawarehouses of datamarts. In een centraal geleide, functionele organisatie heeft een datawarehouse een aanzienlijk mindere kans van slagen dan in een gedecentraliseerde divisievorm of in een opener projectmatrix-organisatie. In een meer hiërarchische bedrijfscultuur zal het 'pottenkijken' door het hoger management worden tegengewerkt. Raar maar waar: juist hier zal men top-down eerder beslissen voor een datawarehouse-concept, maar het verzet bottom-up maakt het proces tijdrovend, duur en vaak contraproductief. Waarschijnlijk is het hier zelfs pragmatischer met conventionele managementsupportsystemen te volstaan.

Wat velen ook pas laat doorzien, is dat het onwaarschijnlijk is dat er één multidimensionaal business-model kan worden ontworpen, geschikt voor elke denkbare analyse. Hoewel datawarehousing qua concept maximale flexibiliteit nastreeft en zo min mogelijk beperkingen oplegt aan het multidimensionaal modelleren, is vaak de combinatie van database-technologie, datawarehouse en OLAP tools de bottleneck. Er moeten dan onder meer wel zeer veel paden in het multidimensioneel datawarehouse worden vastgelegd, waarlangs analyses (het makkelijkst) plaats kunnen vinden. Kortom, in plaats van één multidimensionele datakubus, zou het wel eens verstandig kunnen zijn om er meer naast elkaar te hebben. Zowel inhoudelijk (alternatieve views), als systeemtechnisch (performance) is dat goed te motiveren. Wanneer meer gebruikersgroepen dezelfde objecten willen gebruiken voor complexere analyses, kan dat beter op kleinere, facttables (kubussen). Dat geeft geen inconsistenties in het oorspronkelijke bestand, want een datawarehouse is immers alleen voor read only- gebruik. De kubussen kunnen dezelfde dimensies bevatten, maar verschillen in aggregatieniveau, ingericht op veel voorkomende queries.

Ten leste: er bestaat een datawarehouse-continuüm, dat loopt van één enkel allesomvattend datawarehouse naar een architectuur, waarin verschillende decentrale datamarts gezamenlijk het datawarehouse vormen. Bijvoorbeeld bij de Nederlandse Spoorwegen kan elke business unit zijn eigen datamart hebben en de gehele NS heeft op die manier een gedistribueerd datawarehouse.

Elk organisatieonderdeel kan verantwoordelijk worden gehouden voor het beheer en onderhoud van zijn datawarehouse-onderdeel. Dat is bijvoorbeeld zeker aan de orde in een maximaal gedecentraliseerde organisatie; er bestaat nauwelijks een corporate body en dus kan dit de kosten voor een relatief duur corporate datawarehouse niet dragen, maar wel de bedrijfsonderdelen verplichten om elk een bijdrage te leveren.