OLTP, OLAP & datawarehousing

Wanneer je één systeem twee totaal verschillende vragen moet laten beantwoorden

Stel je runt een e-commerce platform. Overdag voegen tientallen services bestellingen toe, passen adressen aan, en reserveren voorraad. Tegelijk vraagt het management elk uur: “Wat is de omzet per kanaal, per regio, en hoe verhoudt dit zich tot vorige maand?” Als je die rapportvragen direct op dezelfde tabellen draait waar continu transacties binnenkomen, krijg je al snel een systeem dat óf traag wordt, óf onbetrouwbare cijfers geeft. Herkenbaar?

Dit is precies waarom in databasegeschiedenis een scheiding ontstaat tussen systemen die operaties verwerken en systemen die inzicht leveren. In data engineering is dat geen theorie: het bepaalt hoe je je data platform inricht, welke datamodellen je kiest, hoe je performance borgt, en hoe je “één waarheid” bewaart zonder je applicaties kapot te trekken.

In deze les zet je drie begrippen scherp neer—OLTP, OLAP en datawarehousing—en leer je waarom ze bestaan, hoe ze samenwerken, en welke ontwerpkeuzes vaak verkeerd gaan.

OLTP, OLAP en datawarehouse: één taal voor twee soorten werk

OLTP (Online Transaction Processing) gaat over het betrouwbaar verwerken van veel kleine, gelijktijdige wijzigingen: inserts/updates/deletes die samen één zakelijke handeling vormen. Denk aan “plaats bestelling”, “registreer betaling”, “wijzig klantadres”. De kern is consistentie: transacties moeten kloppen, ook bij concurrentie en storingen.

OLAP (Online Analytical Processing) gaat over het analyseren van grote hoeveelheden data: aggregaties, trends, cohort-analyses, “slice-and-dice”. Hier wil je vooral snel kunnen lezen en flexibel vragen stellen, vaak over lange tijdsperiodes. OLAP-queries zijn doorgaans zwaarder: veel rijen scannen, groeperen, joinen en filteren.

Datawarehousing is de aanpak (en vaak ook het centrale systeem) waarmee je data uit operationele bronnen verzamelt, structureert en bewaakt zodat analyses stabiel en herhaalbaar worden. Belangrijk: het datawarehouse is niet “een grote database”; het is een contract over definities, tijd, historiek en kwaliteit—precies het soort expliciete afspraken dat je ook bij relationele schema’s en constraints zag.

Een nuttige analogie: OLTP is de kassa en voorraadbalie (elke handeling moet meteen kloppen), OLAP is de boekhouding en analyse (je wilt doorkijken over weken/maanden), en het datawarehouse is het geconsolideerde grootboek waarin definities en historiek strak zijn vastgelegd.

Waarom OLTP-ontwerp draait om integriteit en voorspelbare writes

In OLTP is het primaire doel: transacties correct verwerken onder gelijktijdigheid. Dat is de wereld van sleutels, constraints, en transacties als gedragscontract. Normalisatie is hier vaak een voordeel omdat je feiten op één plek bewaart en update-anomalieën voorkomt: één klantrecord wijzigen in plaats van vijf kopieën. Ook referentiële integriteit (foreign keys) is typisch OLTP-waardig: een order mag niet naar een niet-bestaande klant verwijzen.

De performance-trade-off is dat OLTP-systemen gevoelig zijn voor query’s die “te breed” worden: grote scans en zware aggregaties concurreren met writes. Daarom zie je in OLTP vaak nadruk op gerichte indexen, korte transacties, en querypatronen die op primaire sleutels of selectieve filters werken. Een OLTP-systeem is meestal geoptimaliseerd voor lage latency per request, niet voor “scan alles van de afgelopen 2 jaar”.

Best practices die hier direct op aansluiten (en die je in data engineering steeds terugziet):

• Houd businessregels in het schema waar het kan: constraints als expliciet contract, niet alleen “best effort” in applicatiecode.

• Ontwerp voor concurrency: transacties klein houden, contention op hot rows beperken, en updates zo deterministisch mogelijk maken.

• Behandel schemawijzigingen als productverandering: OLTP-breuk (kolom hernoemen, constraint toevoegen) heeft directe impact op applicaties.

Veelvoorkomende misvattingen:

• Misvatting: “We kunnen integriteit later met een batch fixen.” In OLTP leidt dat tot realtime fouten: dubbele klanten, orders zonder klant, of voorraad die negatief staat.

• Misvatting: “Constraints vertragen alleen maar.” Ja, ze kosten iets, maar ze voorkomen vaak veel grotere kosten door herstelwerk en inconsistentie tussen services.

• Valkuil: OLTP-tabellen gebruiken als “oneindige log” voor alle events. Dat lijkt handig, maar maakt het schema zwaar, onderhoud lastig, en analytische vragen duur.

Waarom OLAP-ontwerp draait om leesbaarheid, historiek en veranderende vragen

OLAP ontstaat omdat organisaties niet alleen willen weten wat nu waar is, maar ook wat er door de tijd heen gebeurde. Die tijdsdimensie botst vaak met OLTP-normalisatie. In OLTP update je een klantadres “in-place” omdat je huidige waarheid nodig hebt. In analytics wil je soms juist weten: welk adres gold op het moment van aankoop? OLAP draait dus om historisering, eenduidige definities, en het kunnen herhalen van rapporten met dezelfde uitkomst.

Daarom is OLAP vaak minder strikt genormaliseerd dan OLTP. Niet omdat “normalisatie slecht is”, maar omdat analytische workloads baat hebben bij minder joins en betere scan-/aggregatiepatronen. Je ziet dan modellen die expliciet zijn ingericht op vragen: feiten (metingen zoals omzet, aantallen) en dimensies (beschrijvingen zoals klant, product, tijd). Het doel is dat businessgebruikers en data teams dezelfde begrippen consistent kunnen gebruiken: “omzet” betekent één ding, “actieve klant” heeft één definitie, en “maand” heeft een vaste kalenderlogica.

Best practices in deze wereld:

• Maak definities expliciet: metrics en dimensies zijn afspraken, net als constraints dat zijn in OLTP.

• Ontwerp voor veranderende vragen: analytics-vragen evolueren; je model moet dat kunnen absorberen zonder telkens de bronapplicaties te verstoren.

• Wees streng op tijd en semantiek: timestamps, timezones, en “as-of” logica zijn geen detail; ze bepalen of dashboards te vertrouwen zijn.

Typische valkuilen en misconcepties:

• Misvatting: “OLAP is gewoon een read-replica van OLTP.” Een kopie zonder semantische laag geeft je nog geen consistente definities, historiek of ‘single source of truth’ voor reporting.

• Valkuil: analytics direct op operationele tabellen laten draaien “want het werkt nu”. Bij groei krijg je onvoorspelbare performance en discussies over cijfers.

• Misvatting: “Denormaliseren is altijd de oplossing.” Te veel duplicatie maakt definities juist fragiel; je wilt doelgericht denormaliseren rond stabiele dimensies.

Datawarehousing als contract: van ruwe transacties naar betrouwbare inzichten

Een datawarehouse is in essentie een integratielaag: het zet meerdere operationele waarheden om naar één analytische waarheid. Daarbij gaat het om drie dingen: (1) consistentie van definities, (2) stabiliteit door de tijd (historiek en reproduceerbaarheid), en (3) scheiding van workloads zodat OLTP niet lijdt onder OLAP. Dit past bij de rode draad uit databasegeschiedenis: data is niet alleen opslag, het is een set afspraken over structuur en gedrag.

In een goed warehouse modelleer je expliciet welke data “feitelijk” is en welke data context geeft. Feiten veranderen meestal door nieuwe rijen toe te voegen (nieuwe orders, nieuwe pageviews), terwijl dimensies langzaam kunnen veranderen (klantsegment, productcategorie). Historisering is een bewuste keuze: soms overschrijf je (current-state), soms bewaar je versies (slowly changing dimension-achtig denken), afhankelijk van wat je wilt kunnen verklaren. Wat belangrijk is: je maakt dit ontwerp expliciet, zodat twee teams niet elk hun eigen interpretatie bouwen.

Datawarehousing voorkomt ook een organisatorische valkuil: elk team dat “even snel” een extract maakt en in een eigen spreadsheet of schaduwdatabase logica toevoegt. Dat leidt tot hetzelfde file-based probleem van redundantie en inconsistentie, maar dan modern verpakt. Het warehouse probeert juist de “single source of truth” te operationaliseren: één plek waar definities, datatypes, keys, en tijdsregels vastliggen en herbruikbaar zijn.

Hier helpt het om de verschillen scherp te zien:

[[flowchart-placeholder]]

Twee concrete situaties die je als data engineer echt tegenkomt

Voorbeeld 1: klant- en orderdata — van productiequeries naar een warehouse-beeld

Je hebt een Customer- en Order-schema dat netjes werkt voor de webshop. Support wijzigt adressen, finance zet betalingen door, en orders stromen binnen. Marketing wil nu “omzet per klantsegment per maand” en start met een query die orders join’t met customer en vervolgens groepeert. In het begin werkt dat, maar zodra de tabellen groeien en er piekverkeer is, zie je twee effecten: productie wordt trager door zware scans, en de cijfers worden betwist omdat klantsegmenten intussen veranderd zijn.

In een warehouse-aanpak maak je expliciet wat je wilt meten en op welke tijds-as. Stap voor stap:

1. Je bepaalt een fact: bijvoorbeeld orderregels of orders met bedragen en datums.
2. Je definieert dimensies: klant, product, kanaal, tijd—met sleutels die stabiel zijn voor analytics.
3. Je kiest een historiseringsregel: klantsegment “as of orderdatum” of “huidig segment”. Dat is geen detail, dat is de definitie van het rapport.
4. Je maakt het rapport een query op het warehouse-model, niet op de OLTP-tabellen.

De impact is praktisch: minder druk op OLTP, snellere analyses, en vooral minder discussie over “welke omzet klopt”. De beperking is dat je latency introduceert: analytics is vaak niet milliseconde-real-time. Daarom is het cruciaal om met stakeholders af te spreken welke versheid nodig is en welke definities leidend zijn—precies zoals schema en constraints in OLTP afspraken afdwingen.

Voorbeeld 2: productcatalogus en categorieën — één operationele waarheid, meerdere analytische perspectieven

Operationeel wil je een product kunnen tonen met categorieën en actuele prijzen. In OLTP modelleer je product, category en een koppelrelatie (veel-op-veel) zodat de webshop flexibel blijft. Marketing vraagt vervolgens: “Hoe presteren categorieën over time, ook als we producten hercategoriseren?” Hier botst current-state OLTP met analytische historiek: als je een product vandaag verplaatst van “Wearables” naar “Sport”, dan verandert je oude reporting terugwerkend als je niet historiseert.

In een warehouse leg je daarom een perspectief vast: je kunt categorie-toewijzingen versioneren of “snapshotten” per periode. Stap voor stap:

1. Je neemt operationele relaties (ProductCategory) als bron van waarheid voor nu.
2. Je bepaalt hoe je verleden wil interpreteren: categorie op ordermoment, of categorie volgens huidige indeling.
3. Je materialiseert die keuze in warehouse-tabellen (bijv. door een tijdsdimensie te koppelen aan de categorisatie).
4. Je laat dashboards consequent dezelfde definitie gebruiken.

De winst is dat analytics niet meebeweegt met elke operationele herindeling, tenzij je dat expliciet wil. De beperking is dat je extra model- en governancewerk doet: definities documenteren, keys beheren, en tijdlogica testbaar maken. Maar dat is precies de investering die “CSV-achtige chaos” voorkomt: één contract waar meerdere teams op kunnen bouwen.

Wat je meeneemt naar je platformontwerp

OLTP, OLAP en datawarehousing bestaan omdat “data opslaan” niet één probleem is. Je verwerkt transacties (correctheid onder concurrency), je beantwoordt veranderende vragen (flexibele analyses), en je bewaakt definities en historiek (vertrouwbare cijfers). Als je die rollen door elkaar haalt, betaal je met performanceproblemen of met eindeloze discussies over wat waar is.

Belangrijkste takeaways:

• OLTP optimaliseert voor correcte, snelle transacties en leunt op schema’s, keys en constraints als contract.

• OLAP optimaliseert voor zware reads en aggregaties, met extra nadruk op tijd, definities en modelleerkeuzes die vragen faciliteren.

• Datawarehousing maakt analytics herhaalbaar en eenduidig door integratie, semantiek en historiek expliciet te maken.

Next, we’ll build on this by exploring NoSQL & cloud storage trade-offs [20 minutes].