Bijlage A — Berekende Attributen

Belangrijk

Je leest de versie die nog in ontwikkeling is. Dit hoofdstuk is nog een concept; er kan nog veel veranderen.

Het dilemma

Bij het ontwerpen van een database kom je attributen tegen waarvan de waarde je kunt berekenen uit andere velden. Denk aan:

Subtotaal = Aantal × Prijs
Totaalbedrag = Som van alle subtotalen
Leeftijd = Huidige datum - Geboortedatum

De vraag is of je deze berekende waarden moet opslaan in de database of niet. Hierop is geen simpel antwoord te geven. Het hangt van het type gegeven en van de situatie af.

Volgens strikte normalisatieregels moet je geen berekende velden in een database opslaan omdat je de waarde immers kunt laten berekenen wanneer je deze nodig hebt.

Maar de praktijk wijkt af

In de praktijk kunnen er goede redenen zijn om berekende waarden wel op te slaan. Wat zijn de problemen?

Historische prijzen (belangrijkste reden!)
Stel een laptop kost vandaag €799 en een klant bestelt en betaalt 1 laptop. Wanneer een maand later de prijs verhoogd wordt naar €899 dan is er een probleem wanneer Subtotaal niet in de database wordt opgeslagen, maar berekend wordt. Bij de maand eerder gekochte laptop staat dan het berekende bedrag Aantal * Prijs = 1 * 899 = 899. En dit is fout want de klant heeft maar €799 betaald.
Kortingen en aanbiedingen
Stel een product kost normaal €50, maar de klant krijgt 20% korting.

Wanneer moet je WEL en wanneer NIET opslaan

NIET opslaan wanneer:

de waarde continu verandert en altijd direct berekend kan worden uit actuele data. Een voorbeeld hiervan is een attribuut als Leeftijd. Deze verandert elk jaar en kan altijd via het attribuut Geboortedatum berekend worden: `Leeftijd = Huidige_jaar - Geboortejaar`
de berekening altijd op actuele data gebaseerd is en geen geld betreft.

WEL opslaan wanneer:

het een financiële transactie (bestelling, betaling, boeking) betreft. Je moet altijd vastleggen wat een product kostte op het moment van de transactie. Zie het hiervoor geschetste probleem met de prijsverhoging van de laptop. In de tabel met de transacties neem je dan de echte verkoopprijs als attribuut op.
Bij financiële transacties sla je altijd op wat er OP DAT MOMENT gold. Dit heet een ‘snapshot’ en beschermt je tegen veranderende prijzen en tarieven.”
er kortingen of speciale prijzen zijn. Immers de korting of actie kan op een later moment voorbij zijn.
historische waarden belangrijk zijn. Wat was de BTW toen? Wat waren de verzendkosten toen?
de performance kritiek is. Als je een berekening duizenden keren per dag moet uitvoeren, kan het efficiënter zijn om het resultaat op te slaan.

Vuistregels voor je ontwerp

Sla berekende waarden OP wanneer:

✅ Het gaat om geld (prijzen, bedragen, kortingen)
✅ Het is een transactie of gebeurtenis (bestelling, betaling, boeking)
✅ De onderliggende waarden kunnen veranderen (prijzen, tarieven)
✅ Je een “snapshot van dat moment” wilt bewaren

Sla berekende waarden NIET OP wanneer:

❌ De waarde continu verandert (leeftijd, voorraad)
❌ Het altijd uit actuele data berekend kan worden
❌ Er geen financiële of historische component is
❌ De onderliggende data permanent is