Kennisbank · datakwaliteit

Data classes

Eenduidige afspraken over invoer, validatie, normalisatie, opslag en weergave van veelvoorkomende gegevens.

Waarom data classes?

Een SQL-datatype vertelt vooral hoe een database een waarde technisch bewaart. Het vertelt niet of een tekenreeks een postcode, telefoonnummer, domeinnaam of IBAN voorstelt, hoe die waarde mag worden ingevoerd en hoe zij aan een gebruiker moet worden getoond.

Een data class vult dat ontbrekende betekenisniveau aan. Zij legt één centrale semantische definitie vast voor een veelvoorkomend gegevenstype. Daardoor worden dezelfde gegevens in verschillende tabellen, schermen en toepassingen op dezelfde manier geïnterpreteerd en verwerkt.

Deze verzameling is opgesteld voor de database achter datamanagers.nl, maar is ook bedoeld als praktisch en herbruikbaar vertrekpunt voor andere databases en organisaties.

Algemene uitgangspunten

De officiële term is data class; de formele Nederlandse omschrijving is semantisch datatype. Een data class is geen nieuw SQL-datatype, maar een betekenisvolle laag boven op het fysieke datatype.

  • Iedere data class heeft een herkenbare mnemonic en een attribuutsuffix. Zo maakt project_start_dat direct zichtbaar dat de waarde de regels van data class datum volgt.
  • Met uitzondering van id bestaat iedere mnemonic uit drie tekens.
  • De regels worden volgens het SPOM-principe centraal onderhouden en vanuit zowel de GUI als de opslaglaag toegepast.
  • Variabele tekstvelden worden bij opslag ontdaan van voor- en achterliggende spaties; voor char geldt deze algemene trimregel niet.
  • Een definitie beschrijft alleen aanvullende of afwijkende regels. Algemene eigenschappen van een standaard worden niet onnodig herhaald.
  • Nullability en andere situationele beperkingen worden per attribuut bepaald, tenzij zij wezenlijk onderdeel zijn van de data class zelf.

Algemene verwerking van waarden

  • Data wordt bij invoer centraal geparsed en gevalideerd volgens de regels van de betreffende data class.
  • Ongeldige invoer wordt niet opgeslagen. Een melding verschijnt bij het veld of de knop die tot de validatie heeft geleid.
  • Bij geldige, formatteerbare invoer wordt de canonieke waarde opgeslagen en vervangt de afgesproken weergave de ingevoerde tekst in de GUI.
  • Geldige maar niet-formatteerbare invoer wordt, behoudens algemene bewerkingen, inhoudelijk ongewijzigd opgeslagen en weergegeven.

Contact- en locatiegegevens

tel Telefoonnummer
  • Attribuutsuffix: _tel.
  • Fysiek SQL-datatype: varchar(32).
  • Een telefoonnummer bevat maximaal vijftien daadwerkelijke cijfers. Toegestane opmaaktekens tellen mee voor de maximale opslaglengte van 32 tekens, maar niet voor dit maximum van vijftien cijfers.
  • Toegestane invoertekens zijn cijfers, (, ), +, - en spaties.
  • Een + is uitsluitend toegestaan als eerste teken; 00 aan het begin wordt als internationale prefix herkend.
  • +31 en 0031 worden als Nederlandse landcode herkend. Een direct daaropvolgende (0) wordt genegeerd.
  • Een Nederlands telefoonnummer bestaat uit een nationale 0 gevolgd door negen cijfers. Bij invoer met +31 of 0031 vervangt de landcode deze nationale 0.
  • Canonieke opslag van een Nederlands nummer: +31XXXXXXXXX.
  • Een buitenlands nummer wordt na succesvolle basisvalidatie verder ongewijzigd opgeslagen en weergegeven.
  • Nederlandse mobiele nummers worden weergegeven als (06) 12 34 56 78.
  • Nederlandse geografische nummers worden weergegeven als (010) 12 34 567 of (0318) 123 456. De tabel driecijferig_netnummer bepaalt welke netnummers uit drie cijfers bestaan.
pcd Postcode
  • Attribuutsuffix: _pcd.
  • Fysiek SQL-datatype: varchar(10).
  • Bij invoer in de GUI zet het invoermasker ingevoerde letters onmiddellijk om naar hoofdletters. In de opslaglaag gebeurt dit voor de zekerheid nogmaals.
  • Een Nederlandse postcode mag met of zonder de gebruikelijke spatie worden ingevoerd.
  • Na verwijdering van de tussenruimte bestaat een Nederlandse postcode uit vier cijfers en twee letters; het eerste cijfer mag geen 0 zijn.
  • Canonieke opslag: 1234AB.
  • Weergave: 1234 AB.
  • De Nederlandse canonieke waarde voldoet aan ^[1-9][0-9]{3}[A-Z]{2}$.
  • Een buitenlandse postcode wordt na basisvalidatie verder ongewijzigd opgeslagen en weergegeven.
eml E-mailadres
  • Attribuutsuffix: _eml.
  • Fysiek SQL-datatype: varchar(254).
  • Bij invoer in de GUI worden letters onmiddellijk naar kleine letters omgezet. In de opslaglaag gebeurt dit voor de zekerheid nogmaals voor het volledige e-mailadres.
  • Het e-mailadres bevat precies één @, die het lokale deel en het domeingedeelte scheidt.

Lokale deel vóór de @

  • Toegestaan zijn a-z, 0-9, ., -, _ en +.
  • Een punt mag niet als eerste of laatste teken voorkomen en twee punten mogen niet direct opeenvolgen.
  • Het lokale deel bevat maximaal 64 tekens.

Domeingedeelte na de @

  • Het e-maildomein is van de data class domeinnaam.
  • Canonieke opslag: [lokaal deel]@[canonieke waarde dom], bijvoorbeeld gebruiker@xn--mnchen-3ya.de.
  • Weergave: [lokaal deel]@[weergavewaarde dom], bijvoorbeeld gebruiker@münchen.de.
  • Als het domein Punycode bevat, wordt het volledige e-mailadres weergegeven volgens de aanvullende Punycodeweergaveregels van data class domeinnaam.

Webadressen en netwerkgegevens

dom Domeinnaam
  • Attribuutsuffix: _dom.
  • Fysiek SQL-datatype: varchar(253).
  • Formaat: domain.
  • Unicode-domeinnamen worden geaccepteerd.
  • Voor canonieke opslag wordt de domeinnaam naar lowercase ASCII/Punycode geconverteerd.
  • Ieder domeinlabel bevat na conversie maximaal 63 ASCII-tekens, inclusief eventuele Punycode.
  • IP-adressen en lokale namen, zoals localhost, zijn niet toegestaan.
  • De domeinnaam mag niet eindigen op een punt.
  • Canonieke opslag: xn--mnchen-3ya.de.
  • Weergave: münchen.de.

Weergave bij Punycode

  • De GUI toont de domeinnaam in de bedoelde Unicode-vorm.
  • De domeinnaam wordt in een sterk afwijkende rode tekstkleur weergegeven, zonder afzonderlijke zichtbare melding.
  • Een tooltip legt uit dat de opgeslagen domeinnaam Punycode bevat; dezelfde toelichting is beschikbaar voor hulptechnologie.
pth Pad
  • Attribuutsuffix: _pth.
  • Fysiek SQL-datatype: varchar(2048).
  • Formaat: /path.
  • Het pad begint met precies één /.
  • Querystrings en fragmenten zijn niet toegestaan.
  • Hoofd- en kleine letters blijven behouden.
  • Een ontbrekende afsluitende / wordt niet toegevoegd.
  • Dubbele slashes binnen het pad en gewone spaties zijn niet toegestaan.
  • Geldige percent-encoding is toegestaan en wordt as is opgeslagen, maar mag geen verboden constructie verhullen.
  • Canonieke opslag en weergave: /Kennisbank/Jaar%202026.
dpt Domeinnaam met pad
  • Attribuutsuffix: _dpt.
  • Fysiek SQL-datatype: varchar(2048).
  • Formaat: domain[:port][/path].
  • Het domeingedeelte is van de data class domeinnaam.
  • Een poortnummer van 1 tot en met 65535 is toegestaan en wordt niet verwijderd.
  • Het padgedeelte is, indien aanwezig, van de data class pad.
  • Canonieke opslag: xn--mnchen-3ya.de:8443/OverOns.
  • Weergave: münchen.de:8443/OverOns.
  • Als het domeingedeelte Punycode bevat, wordt de volledige waarde weergegeven volgens de aanvullende Punycodeweergaveregels van data class domeinnaam.
url Webadres met protocol
  • Attribuutsuffix: _url.
  • Fysiek SQL-datatype: varchar(2048).
  • Formaat: protocol://domain[:port][/path].
  • Toegestane protocollen zijn http en https.
  • Het protocol wordt in lowercase opgeslagen.
  • Het gedeelte na :// is van de data class domeinnaam met pad.
  • Canonieke opslag: https://xn--mnchen-3ya.de:8443/OverOns.
  • Weergave: https://münchen.de:8443/OverOns.
  • Als het domeingedeelte Punycode bevat, wordt het volledige webadres weergegeven volgens de aanvullende Punycodeweergaveregels van data class domeinnaam.
ip4 IPv4-adres
  • Attribuutsuffix: _ip4.
  • SQL-datatype: varchar(15).
  • De waarde is een geldig IPv4-adres en bestaat uit vier decimale getallen van 0 tot en met 255, gescheiden door punten.
  • Voorloopnullen binnen de vier getallen worden bij canonieke opslag verwijderd.
  • Canonieke opslag en weergave: 192.0.2.1.
ip6 IPv6-adres
  • Attribuutsuffix: _ip6.
  • SQL-datatype: varchar(39).
  • De waarde is een geldig IPv6-adres.
  • Bij invoer zijn hoofdletters en kleine letters toegestaan; voor canonieke opslag worden letters naar kleine letters omgezet.
  • Voorloopnullen binnen een groep worden bij canonieke opslag verwijderd.
  • De langste aaneengesloten reeks groepen met uitsluitend nullen wordt eenmaal verkort tot ::. Bij meerdere even lange reeksen wordt de meest linkse verkort.
  • Canonieke opslag en weergave: 2001:db8::1.
ipx IP-adres
  • Attribuutsuffix: _ipx.
  • SQL-datatype: varchar(39).
  • De waarde is een geldig IPv4- of IPv6-adres.
  • Een IPv4-adres wordt verwerkt volgens de regels van data class IPv4-adres.
  • Een IPv6-adres wordt verwerkt volgens de regels van data class IPv6-adres.
  • Canonieke opslag en weergave volgen de regels van de toepasselijke data class.

Organisatie- en financiële gegevens

vat Btw-nummer
  • Attribuutsuffix: _vat.
  • Fysiek SQL-datatype: varchar(32).

Nederlandse btw-nummers

  • Een btw-nummer dat, ongeacht hoofdletters, begint met NL, wordt als Nederlands btw-nummer behandeld.
  • De letters worden naar hoofdletters omgezet.
  • Het nummer bestaat uit NL, negen cijfers, de letter B en twee cijfers.
  • Canonieke opslag en weergave: NL123456789B01.

Niet-Nederlandse btw-nummers

  • Er wordt geen inhoudelijke of landspecifieke validatie uitgevoerd.
  • Het nummer wordt as is opgeslagen en weergegeven.
crn KVK-nummer
  • Attribuutsuffix: _crn.
  • Fysiek SQL-datatype: varchar(8).
  • Het KVK-nummer bestaat uit precies acht cijfers.
  • Voorloopnullen blijven behouden.
  • Canonieke opslag en weergave: 12345678.
ibn IBAN
  • Attribuutsuffix: _ibn.
  • Fysiek SQL-datatype: varchar(34); maximale invoerlengte: 42 tekens.
  • Bij invoer in de GUI worden letters direct naar hoofdletters omgezet.
  • Een IBAN mag met of zonder spaties tussen groepen tekens worden ingevoerd.
  • Bij opslag worden letters opnieuw naar hoofdletters omgezet en worden de spaties verwijderd.
  • Een IBAN bestaat uit een landcode van twee letters, twee controlecijfers en een landspecifiek rekeninggedeelte.
  • De landcode, lengte en opbouw moeten overeenkomen met de regels van het betreffende land en de controlecijfers moeten geldig zijn.
  • De canonieke opslag bevat uitsluitend hoofdletters en cijfers.
  • De weergave vindt vanaf links plaats in groepen van vier tekens; de laatste groep mag korter zijn.

Nederlandse IBAN's

  • Een Nederlandse IBAN bestaat uit precies achttien tekens: NL, twee controlecijfers, een bankcode van vier letters en een rekeningnummer van tien cijfers.
  • Canonieke opslag: NL91ABNA0417164300.
  • Weergave: NL91 ABNA 0417 1643 00.

Landregels

  • In de landentabel wordt per land vastgelegd of het land IBAN gebruikt, welke IBAN-landcode geldt, wat de vereiste totale lengte is en hoe het landspecifieke rekeninggedeelte is opgebouwd.
  • De algemene regels voor hoofdletters, spaties, weergave en controlecijfers behoren tot de data class IBAN.
  • De GUI en opslag gebruiken volgens het SPOM-principe dezelfde centraal vastgelegde landregels.

Landcodes

la2 Landcode alpha-2
  • Attribuutsuffix: _la2.
  • Fysiek SQL-datatype: varchar(2).
  • Formaat: ISO 3166-1 alpha-2; precies twee letters.
  • Bij invoer in de GUI en bij opslag worden letters naar hoofdletters omgezet.
  • De waarde moet een geldige ISO 3166-1 alpha-2-code zijn.
  • Canonieke opslag en weergave: NL.
la3 Landcode alpha-3
  • Attribuutsuffix: _la3.
  • Fysiek SQL-datatype: varchar(3).
  • Formaat: ISO 3166-1 alpha-3; precies drie letters.
  • Bij invoer in de GUI en bij opslag worden letters naar hoofdletters omgezet.
  • De waarde moet een geldige ISO 3166-1 alpha-3-code zijn.
  • Canonieke opslag en weergave: NLD.
ln3 Numerieke ISO-landcode
  • Attribuutsuffix: _ln3.
  • Fysiek SQL-datatype: varchar(3).
  • Formaat: ISO 3166-1 numeric; precies drie cijfers.
  • Voorloopnullen blijven behouden.
  • De waarde moet een geldige ISO 3166-1 numeric-code zijn.
  • Canonieke opslag en weergave: 528.

Datum en tijd

dat Datum
  • Attribuutsuffix: _dat.
  • Fysiek SQL-datatype: date.
  • Invoer en weergave: dd-mm-jjjj.
  • Een datum moet een bestaande kalenderdatum zijn.
  • Canonieke waarde voor MySQL: jjjj-mm-dd.
  • Een datum kent geen tijdzone.
  • Voorbeeld invoer en weergave: 07-09-2026.
  • Voorbeeld canonieke waarde: 2026-09-07.
tim Tijd
  • Attribuutsuffix: _tim.
  • Fysiek SQL-datatype: time.
  • De 24-uursnotatie wordt gebruikt.
  • Invoer: uu:mm; bij handmatige invoer worden de seconden als 00 verwerkt.
  • Canonieke waarde voor MySQL: uu:mm:ss.
  • Een ingevoerde tijd wordt weergegeven als uu:mm; een gegenereerde tijd als uu:mm:ss.
  • Een losse tijd kent geen tijdzone en wordt niet naar UTC omgerekend.
  • Voorbeeld invoer en weergave: 14:30; canonieke waarde: 14:30:00.
dtm Datumtijd
  • Attribuutsuffix: _dtm.
  • Fysiek SQL-datatype: datetime.
  • Invoer: dd-mm-jjjj uu:mm.
  • Een door een gebruiker ingevoerde datumtijd wordt geïnterpreteerd volgens de tijdzone Europe/Amsterdam. De gebruiker kan geen tijdzone invoeren of selecteren.
  • Alle datumtijden worden in UTC aan MySQL aangeboden en vastgelegd.
  • Canonieke waarde voor MySQL: jjjj-mm-dd uu:mm:ss in UTC.
  • Bij weergave wordt de UTC-waarde omgerekend naar Europe/Amsterdam.
  • Een ingevoerde datumtijd wordt weergegeven als dd-mm-jjjj uu:mm; een gegenereerde datumtijd als dd-mm-jjjj uu:mm:ss.
  • De tijdzoneregels van Europe/Amsterdam bepalen automatisch of zomer- of wintertijd geldt.
  • Een lokale datumtijd die tijdens de overgang naar zomertijd niet bestaat, is ongeldig.
  • Als een lokale datumtijd tijdens de overgang naar wintertijd tweemaal voorkomt, wordt de UTC-tijd behorend bij het tweede tijdstip vastgelegd: het tijdstip ná het terugzetten van de klok.
  • Voorbeeld invoer en weergave: 07-09-2026 14:30; canonieke waarde: 2026-09-07 12:30:00.

Sleutels, getallen en logische waarden

id ID
  • Attribuutsuffix: _id.
  • Fysiek SQL-datatype: integer.
  • Een ID wordt uitsluitend gebruikt voor primary en foreign keys en wordt door het systeem toegekend.
  • Een ID heeft geen bedrijfsinhoudelijke betekenis.
  • Een ID verandert niet nadat het is toegekend en wordt na verwijdering niet opnieuw gebruikt.
  • Een ID wordt niet door gebruikers ingevoerd of gewijzigd en normaal gesproken niet aan gebruikers getoond.
  • De attribuutnaam bestaat uit de naam van de geïdentificeerde of gerefereerde entiteit, gevolgd door _id, bijvoorbeeld project_id.
  • id is de enige toegestane mnemonic van twee letters.
uid UUID
  • Attribuutsuffix: _uid.
  • Fysiek SQL-datatype: varchar(36).
  • Een UUID wordt uitsluitend door het systeem gegenereerd. Nieuw gegenereerde UUID's zijn van versie 4 en gebruiken cryptografisch veilige willekeur.
  • Een UUID bestaat uit 32 hexadecimale tekens en vier koppeltekens, verdeeld in groepen van 8, 4, 4, 4 en 12 tekens.
  • Letters worden in lowercase vastgelegd.
  • Een UUID is uniek en heeft geen bedrijfsinhoudelijke betekenis.
  • Een UUID verandert niet nadat het is toegekend en wordt na verwijdering niet opnieuw gebruikt.
  • Een UUID wordt niet door gebruikers ingevoerd of gewijzigd.
  • Een UUID wordt niet aan gebruikers getoond.
  • Canonieke opslag: 5f04de8f-14d4-4b86-a630-79d6e98b1763.
amt Bedrag
  • Attribuutsuffix: _amt.
  • Fysiek SQL-datatype: decimal(15,2).
  • Invoer volgt de Nederlandse getalnotatie: een komma scheidt decimalen en een punt mag duizendtallen scheiden.
  • Invoer zonder decimalen wordt verwerkt met twee decimalen; invoer met één decimaal wordt aangevuld.
  • De canonieke waarde voor MySQL bevat geen duizendtalscheiding en gebruikt een punt als decimaalteken.
  • Bedragen worden niet via een floating-point datatype verwerkt.
  • Een negatief bedrag begint met een minteken.
  • De weergave gebruikt een punt voor duizendtallen, een komma als decimaalteken en altijd twee decimalen.
  • Voorbeeldinvoer: 1.234,5; canonieke waarde: 1234.50; weergave: 1.234,50.
  • Een valutateken of valutacode maakt geen deel uit van deze data class. Wanneer de valuta niet door de context vaststaat, wordt deze afzonderlijk gemodelleerd.
pct Percentage
  • Attribuutsuffix: _pct.
  • SQL-datatype: decimal(9,4).
  • Invoer volgt de Nederlandse getalnotatie: een komma scheidt decimalen, een punt mag duizendtallen scheiden en het procentteken mag aan het einde staan.
  • De ingevoerde waarde vertegenwoordigt het percentage zelf en wordt niet omgerekend naar een breuk.
  • Een percentage bevat maximaal vier decimalen; minder decimalen worden bij opslag aangevuld tot vier.
  • De canonieke SQL-waarde bevat geen duizendtalscheiding of procentteken en gebruikt een punt als decimaalteken.
  • Percentages worden niet via een floating-point datatype verwerkt.
  • Een negatief percentage begint met een minteken.
  • De weergave gebruikt de Nederlandse getalnotatie, toont alleen significante decimalen en eindigt met een procentteken.
  • Voorbeeldinvoer: 18,9%; canonieke waarde: 18.9000; weergave: 18,9%.
bln Boolean
  • Attribuutsuffix: _bln.
  • SQL-datatype: boolean.
  • Een boolean heeft uitsluitend de waarde TRUE of FALSE.
  • Invoer in de GUI gebruikt een bedieningselement met twee mogelijke toestanden, zoals een checkbox of schakelaar.
  • Een geselecteerde of ingeschakelde toestand vertegenwoordigt TRUE; de andere toestand vertegenwoordigt FALSE.
  • De canonieke SQL-waarde is TRUE of FALSE; de tekstuele weergave is Ja of Nee.
  • Attribuutnamen worden positief geformuleerd, zodat TRUE betekent dat de beschreven eigenschap van toepassing is.

Technische en beveiligingswaarden

jsn JSON
  • Attribuutsuffix: _jsn.
  • SQL-datatype: json.
  • De waarde moet geldige JSON zijn en bevat precies één JSON-hoofdwaarde.
  • De hoofdwaarde kan een object, array, string, getal, boolean of null zijn.
  • Namen binnen hetzelfde JSON-object zijn uniek.
  • De JSON wordt geparsed en compact geserialiseerd.
  • De volgorde van waarden binnen een JSON-array blijft behouden.
  • Weergave gebruikt inspringing en regelafbrekingen om de structuur leesbaar te maken.
  • Canonieke opslag: {"actief":true,"aantal":3}.

Voorbeeldweergave

{
  "actief": true,
  "aantal": 3
}
sha SHA-256-hash
  • Attribuutsuffix: _sha.
  • SQL-datatype: char(64).
  • De waarde is een met SHA-256 berekende hash.
  • De hash wordt door het systeem gegenereerd en niet handmatig door een gebruiker ingevoerd.
  • De canonieke opslag bestaat uit precies 64 hexadecimale tekens in lowercase.
  • Een SHA-256-hash wordt normaal gesproken niet aan een gebruiker getoond.
psw Wachtwoordhash
  • Attribuutsuffix: _psw.
  • SQL-datatype: varchar(255).
  • Een wachtwoord wordt uitsluitend opgeslagen als wachtwoordhash.
  • De hash wordt berekend met een algoritme dat specifiek bedoeld is voor wachtwoorden.
  • Het gebruikte algoritme, de instellingen en de salt worden als onderdeel van de wachtwoordhash opgeslagen.
  • Ieder wachtwoord krijgt een afzonderlijke, willekeurig gegenereerde salt.
  • Alle afdrukbare ASCII-tekens en spaties zijn toegestaan; Unicode-tekens zijn eveneens toegestaan.
  • Unicode wordt vóór het hashen genormaliseerd naar NFC. Afgezien daarvan blijven alle tekens en hun posities ongewijzigd.
  • Hoofdletters en kleine letters blijven behouden en hebben een verschillende betekenis.
  • Spaties zijn op iedere positie betekenisvol en worden niet verwijderd.
  • Het volledige wachtwoord wordt als UTF-8 verwerkt en nooit stilzwijgend afgekapt.
  • Een wachtwoordhash wordt vernieuwd wanneer het gebruikte algoritme of de instellingen niet meer aan de actuele eisen voldoen.
  • Een wachtwoordhash wordt niet aan een gebruiker getoond.
fil Bestandsnaam
  • Attribuutsuffix: _fil.
  • SQL-datatype: varchar(255).
  • De waarde bevat uitsluitend een bestandsnaam en geen pad.
  • De bestandsnaam mag niet leeg zijn.
  • Toegestaan zijn A-Z, a-z, 0-9, ., -, _, +, @ en spaties.
  • De bestandsnamen . en .. zijn niet toegestaan.
  • Hoofdletters en kleine letters blijven behouden.
  • Canonieke opslag en weergave: Jaarverslag 2026.pdf.

Een beheersbaar fundament

Niet iedere organisatie heeft iedere data class nodig en per attribuut kunnen aanvullende functionele beperkingen gelden. De kracht zit vooral in het expliciet maken van de betekenis en in het centraal toepassen van dezelfde regels.

De definities vormen daarmee geen eindpunt, maar een beheersbaar fundament: duidelijk voor ontwerpers en ontwikkelaars, voorspelbaar voor gebruikers en herbruikbaar bij toekomstige databases.

Wilt u de afspraken rond uw data aanscherpen?

Een datamanagement-quickscan maakt zichtbaar waar definities, eigenaarschap en datakwaliteitsregels ontbreken of niet consequent worden toegepast.