Data warehouse voor het mkb

Een data warehouse is een database die speciaal is ingericht om vragen te beantwoorden, niet om het dagelijkse werk in te doen. Het boekhoudpakket, de webwinkel en het CRM blijven de plekken waar medewerkers werken. Het warehouse haalt daar op vaste momenten een kopie van op, zet de gegevens in een vorm die makkelijk te combineren is, en levert de cijfers aan rapportages en dashboards.

Bij een middelgroot of klein bedrijf is de aanleiding meestal heel concreet. De omzet per klantgroep staat in het ene systeem, de marge in het andere en de uren in een derde. Elke maand maakt iemand een spreadsheet die alles combineert, en elke maand kost dat een dag. Of de directie en de verkoopafdeling noemen een ander omzetcijfer, omdat ze elk een andere export gebruiken.

Een mkb-warehouse hoeft geen groot project te zijn. Het begint met twee of drie bronnen en één rapportage die nu veel handwerk kost. Hebben uw gegevens een adres of locatie, zoals afleveradressen of servicebezoeken, dan kan dezelfde database met de extensie PostGIS ook afstanden en regio-indelingen berekenen. Pas als die klopt en gebruikt wordt, komt de volgende bron erbij. De opzet blijft daardoor klein genoeg om door één persoon te worden begrepen en beheerd.

Wie meer zoekt dan rapportage, zoals het publiceren van gegevens als open data of het voeden van andere applicaties, heeft eerder een breder dataplatform nodig. Het warehouse op deze pagina is de kleinere variant, gericht op interne cijfers en beslissingen.

Een warehouse is zinvol als dezelfde vragen steeds terugkomen en het antwoord gegevens uit meer dan één systeem vraagt. Is dat niet zo, dan is het een kostenpost zonder opbrengst.

De laatste rij komt vaak voor. Als een spreadsheet zelf de bron van de gegevens is geworden, lost een warehouse dat niet op. Dan is eerst legacy-modernisering nodig, zodat er een echte bron ontstaat waar het warehouse uit kan lezen.

Deze dienst is dus bedoeld voor bedrijven met meerdere systemen en terugkerende vragen. Ze is niet bedoeld voor wie één dashboard op één pakket wil; dan volstaat vaak een rapportagetool die direct op dat pakket aansluit, zie dashboards.

Bij ELT laadt u de gegevens eerst ongewijzigd in het warehouse en transformeert u ze daarna met SQL. Bij ETL gebeurt de transformatie onderweg, in een apart programma. Voor een mkb-warehouse kiezen we standaard ELT.

Extract

Gegevens ophalen uit de bron, via een API, een databasekoppeling of een exportbestand.

Load

De ruwe gegevens wegschrijven in een eigen schema van het warehouse, zonder ze te wijzigen.

Transform

Opschonen, koppelen en berekenen, in SQL-modellen die in versiebeheer staan.

Het voordeel van ELT is dat de ruwe gegevens bewaard blijven. Blijkt een berekening fout, dan rekent u opnieuw vanaf de ruwe laag zonder de bron opnieuw te bevragen. En omdat de transformaties gewone SQL zijn, kan een analist of een andere ontwikkelaar ze lezen. Bij ETL zit de logica vaak in een tool die alleen de bouwer kent.

Het ophalen zelf is maatwerk per bron. Sommige pakketten bieden een goed gedocumenteerde API, andere alleen een nachtelijke export. Hoe zo'n koppeling betrouwbaar wordt gebouwd, met herhalingen en bewaking, staat bij API-koppelingen.

Een sterschema verdeelt de gegevens in feiten en dimensies. Een feitentabel bevat gebeurtenissen met getallen, zoals orders met een bedrag. De dimensietabellen beschrijven de context, zoals klant, product en datum. In een diagram staat de feitentabel in het midden en de dimensies eromheen, vandaar de naam.

De belangrijkste ontwerpbeslissing is de korrel: wat stelt één rij in de feitentabel voor? Eén orderregel, één order of één dag per klant? De Kimball Group, die het dimensionele modelleren bekend maakte, schrijft daarover:

The grain establishes exactly what a single fact table row represents.

Bron: Kimball Group, Dimensional Modeling Techniques, Grain, gelezen op 11 oktober 2026. De Kimball Group raadt aan te beginnen bij de laagste korrel die het bedrijfsproces vastlegt, omdat die ook vragen aankan die vooraf niemand bedacht.

Voor een mkb-bedrijf betekent dat bijvoorbeeld orderregels uit de webwinkel als feit, met klanten uit het CRM en artikelen uit het voorraadsysteem als dimensie. De moeilijkheid zit zelden in de techniek. Het zit in vragen als of een klant die via twee webwinkels bestelt één klant is of twee, en of een geannuleerde order meetelt in het aantal orders. Die keuzes leggen we samen met u vast, met een beschrijving in gewone taal bij elk model.

Het voorbeeld hieronder is op 11 oktober 2026 gedraaid met dbt-core 1.12.5 en dbt-postgres 1.11.0 op PostgreSQL 14.19. De gegevens zijn een fictief voorbeeld: drie klanten en vijf orders, als CSV ingeladen. In een echt warehouse komen die uit de bronkoppelingen. Het mart-model berekent de betaalde omzet per maand en klantsegment.

-- models/staging/stg_orders.sql
select
    order_id,
    klant_id,
    cast(besteld_op as date)               as besteld_op,
    cast(bedrag_excl_btw as numeric(12,2)) as bedrag_excl_btw,
    status
from {{ ref('raw_orders') }}

-- models/marts/omzet_per_maand.sql
select
    date_trunc('month', o.besteld_op)::date as maand,
    k.segment,
    count(*)                                as aantal_orders,
    sum(o.bedrag_excl_btw)                  as omzet_excl_btw
from {{ ref('stg_orders') }} o
join {{ ref('stg_klanten') }} k using (klant_id)
where o.status = 'betaald'
group by 1, 2
order by 1, 2

Bij de modellen horen datatests in schema.yml: unieke en gevulde sleutels, een geldige statuswaarde, en een relatietest die controleert of elke order bij een bestaande klant hoort.

      - name: klant_id
        data_tests:
          - relationships:
              arguments:
                to: ref('stg_klanten')
                field: klant_id

dbt build draait seeds, modellen en tests in de juiste volgorde en eindigde met PASS=11 WARN=0 ERROR=0. Daarna voegden we een order toe voor klant 9, die niet bestaat:

9 of 11 FAIL 1 relationships_stg_orders_klant_id__klant_id__ref_stg_klanten_ ... [FAIL 1 in 0.02s]
Done. PASS=9 WARN=0 ERROR=1 SKIP=1 NO-OP=0 REUSED=0 TOTAL=11

De omzettabel werd overgeslagen (SKIP=1). Dat is het gewenste gedrag: een fout in de bron levert geen stil verkeerd omzetcijfer op, maar een melding. PostgreSQL 14 krijgt volgens postgresql.org na 12 november 2026 geen updates meer; voor een nieuwe installatie kiest u een recentere hoofdversie.

Metabase is een open source rapportagetool waarin gebruikers vragen aan het warehouse stellen via een klikinterface of SQL, en de uitkomsten als grafiek of tabel in een dashboard zetten. Voor een mkb-warehouse is het een logische keuze omdat het zonder licentiekosten per gebruiker kan draaien.

Er zijn twee punten die u vooraf moet weten. Ten eerste de licentie. Volgens Metabase valt de Open Source Edition onder de GNU Affero General Public License (AGPL), en vragen de functies van de Enterprise Edition een commerciële licentie. Voor intern gebruik is de AGPL meestal geen probleem; wilt u Metabase inbouwen in een product voor klanten, laat dat dan vooraf beoordelen.

Ten tweede de opslag van Metabase zelf. Metabase bewaart vragen, dashboards en gebruikers in een eigen applicatiedatabase. Standaard is dat H2, en de documentatie van Metabase noemt H2 bedoeld voor lokale demo's en raadt PostgreSQL aan voor productie. In onze opzet staat die applicatiedatabase daarom in PostgreSQL, gescheiden van het warehouse en meegenomen in de back-ups.

Gebruikers krijgen in Metabase alleen toegang tot de marts, de eindtabellen met vastgelegde definities, en niet tot de ruwe laag. Zo rekent niemand per ongeluk met geannuleerde orders of dubbele klanten. Meer over het ontwerpen van dashboards die mensen echt gebruiken, staat bij dashboards.

Een warehouse wordt per vraag gebouwd, niet per bron. Zo levert elke stap iets op dat iemand gebruikt.

1. Eén vraag kiezen. Welke rapportage kost nu het meeste handwerk of levert de meeste discussie op? Die wordt de eerste.
2. Bronnen en definities. We stellen vast welke systemen nodig zijn en schrijven elk begrip in gewone taal op, bijvoorbeeld wat telt als omzet en wanneer een klant actief is.
3. Koppelingen en ruwe laag. De gegevens komen ongewijzigd in het warehouse, met een tijdstempel van elke lading.
4. Modellen met tests. Staging, sterschema en marts in dbt, met datatests op sleutels, relaties en geldige waarden.
5. Controle tegen het oude cijfer. De uitkomst wordt naast de handmatige spreadsheet gelegd. Verschillen worden verklaard voordat iemand op het nieuwe cijfer gaat sturen.
6. Rapportage en overdracht. Het dashboard in Metabase, documentatie van de modellen en een afspraak over beheer.

Daarna volgt de volgende vraag. De broncode van koppelingen en modellen staat in een repository waar u toegang toe hebt, zodat ook een eigen analist of een andere partij verder kan. Het werk wordt uitgevoerd door oprichter Tekin Uslu, die volgens eigen opgave sinds 2006 werkt aan geo-informatie, data engineering en IT-architectuur.

De kosten worden vooral bepaald door het aantal bronnen en de kwaliteit van hun koppelmogelijkheden, niet door de hoeveelheid gegevens. Een mkb-bedrijf heeft zelden zoveel records dat de database een probleem wordt; een goed gedocumenteerde API scheelt daarentegen veel bouwtijd ten opzichte van een bron met alleen een handmatige export.

• Aantal en soort bronnen. Elke bron vraagt een eigen koppeling en eigen onderhoud als de leverancier iets wijzigt.
• Datakwaliteit. Dubbele klanten of ontbrekende codes kosten tijd om te verklaren, en soms om in de bron te herstellen.
• Hoe actueel. Een nachtelijke lading is eenvoudiger en goedkoper dan cijfers die elk kwartier bijgewerkt moeten zijn.
• Hosting en beheer. Een server voor PostgreSQL en Metabase, back-ups, updates en bewaking. PostgreSQL ondersteunt een hoofdversie vijf jaar, dus een upgrade hoort in de planning.
• Privacy. Bevat het warehouse persoonsgegevens, dan horen toegangsrechten per rol, bewaartermijnen en een verwerkersovereenkomst erbij.

Open source betekent geen licentiekosten voor PostgreSQL, dbt Core en de Open Source Edition van Metabase, maar wel tijd voor beheer. Een algemene uitleg over kostenfactoren bij maatwerk staat in de kennisbank onder kosten van maatwerk software. Waar het warehouse draait, regelt u bij cloud- en data-infrastructuur.