De oplossing vormgeven: Data structuren ontdekken in de informatiebron

“De weg is lang tussen het plan en de voltooiing ervan”
                                                                        - Molière

Informatie komt altijd voort uit een bron. Uitwisseling van gegevens gebeurd op allerlei manieren: mondeling, schriftelijk en digitaal. De inhoud van de uitgewisselde informatie is dan de gegevensbron geworden. Oplossingen hebben deze informatie nodig; ze zijn afhankelijk van data structuren om gegevens optimaal uit te wisselen. Een data structuur is een ontworpen model aan de hand van een specifieke gegevensbron. Maar hoe ontwerp je nou zo’n model.

Als voorbeeld nemen we een alledaagse informatiebron welke te vinden is in iedere industriële onderneming: de ‘factuur’. Facturen zijn openstaande rekeningen van de klanten van het bedrijf; zij zijn door de belastingdienst als een plicht gesteld en een belangrijk onderdeel van de boekhouding.

Als we de voorbeeld factuur analyseren, zijn er veel gegevens zichtbaar die ons direct en voor 90% feitelijke informatie geven:

1)    de ‘debiteurgegevens’, oftewel de klantgegevens

2)    een serie van producten / diensten die worden afgenomen

3)    het ‘unieke’ nummer van de factuur ter identificatie

4)    de datum van verzending

5)    het te vorderen belastingtarief

6)    de betalingstermijn van de factuur

7)    de bedrijfsgegevens, inclusief KvK-, BTW- en bankrekeningnummer

8)    het totaal verschuldigd bedrag van de klant aan het bedrijf.

Ook vinden we informatie in de informatie; producten / diensten per regel worden verdeeld in 3 segmenten (aantal, omschrijving en prijs) en zowel de debiteur- als bedrijfsgegevens zijn een ‘verzameling’.
Niet-feitelijke informatie is de betalingstermijn; het is een indicator dat op deze informatie ‘actie’ ondernomen moet worden, namelijk de betaling. Dit betekent dat een factuur in ieder geval twee ‘stadia’ kent: betaald of onbetaald. Wanneer een bedrijf informatie zal opvragen over de factuur zal de ‘status’ van de betaling meestal het eerste motief zijn; zonder betaling is er geen winst geboekt.

Het totaalbedrag is een ‘berekende’ waarde. Dit wil zeggen dat de waarde is opgebouwd uit een formule (dit geldt overigens ook voor de BTW) die wordt berekend over een verzameling van andere waarden. Het factuurnummer zal ook een berekende waarde zijn, vanwege het feit dat dit gegeven uniek moet zijn. Sommige facturen gebruiken zelfs hele speciale formules om het nummer extra eigenschappen te geven, zoals voor- of achtervoegsels.

Als we de factuur omzetten naar een model, ontwerpen we deze schematisch als volgt:

Factuur (model)
* id (uniek identificatie nummer als gegevensobject in potentiële database)
* datum factuur (facturen worden meestal eerst gesorteerd op datum)
* factuurnummer (identificatie) óf formule: Factuurnummer = ‘B’+lange datum+id
* debiteur id (collectie uit debiteuren tabel)
* artikelregels (collectie van artikelregel)
                        - artikelregel (aantal, omschrijving, prijs)
* btw tarief (keuze uit 0%, 6%, 19%)
* totaal bedrag (formule: som van iedere prijs van elke artikelregel in artikelregels + BTW)
* status
* lengte betalingstermijn

De informatie van het bedrijf hoeft niet in het datamodel; er is sprake van een enkel bedrijf en zijn ‘statische’ gegevens, ze veranderen nooit (of heel zelden). Daarnaast zitten ze meestal vast aan het briefpapier. Hoewel dit model al rekening houdt met techniek, is het nog géén technisch model; echter is met dit model het een peuleschil voor een techneut om deze te vertalen naar een implementatiemodel.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Informatiebron