Een database is een gestructureerde verzameling van informatie die is opgeslagen zodat deze kan worden geraadpleegd, gewijzigd en benut door applicaties of geautoriseerde gebruikers. Het databasebeheersysteem (DBMS) is de software die deze operaties coördineert: het creëren van tabellen, lezen, schrijven, toegangscontrole, en het handhaven van consistentie. Het begrijpen van databasebeheer begint met het begrijpen van het onderscheid tussen de container (de database) en het mechanisme dat deze laat functioneren (het DBMS).
Traceerbaarheid van gegevens in niet-productieve omgevingen
De meeste gidsen over databasebeheer richten zich op productie: prestaties van queries, optimalisatie van indexen, hoge beschikbaarheid. Kopieën van databases blijven vaak in de schaduw.
Back-ups, testklonen, en sandboxen die zijn gemaakt om een AI-model te trainen of een migratie te valideren, bevatten echter dezelfde gevoelige gegevens als de primaire omgeving. Recente aanbevelingen benadrukken de noodzaak om ook exports, replica’s en testomgevingen te traceren, omdat daar de echte risico-oppervlakte voor compliance ontstaat.
Een databaseklon die in januari is gemaakt en nooit is verwijderd, kan persoonlijke gegevens bevatten die sindsdien gewist hadden moeten worden. Wanneer een AI-agent een staging-omgeving ondervraagt om een rapport te voeden, controleert niemand of de gegevens die hij verbruikt actueel zijn of voldoen aan de retentiebeleid. Voor een diepere verkenning van dit onderwerp legt een gedetailleerd artikel over databasebeheer op Tech Mafia de fundamentele principes uit die ten grondslag liggen aan deze traceerbaarheidskwesties.
De beste praktijk is om een register bij te houden van alle kopieën van een productie-database, met hun creatiedatum, eigenaar, doel en verwachte vervaldatum. Zonder dit register wordt elke vergeten klon een stille regelgevende last.
Observability van een database: verder dan klassieke monitoring
Het monitoren van de responstijd van queries of het CPU-gebruik is monitoring. Observability gaat verder: het houdt in dat de versheid van gegevens, de conformiteit van het schema, de distributieafwijkingen en het volume van records per tabel continu worden gevolgd.
Concreet zegt een observability-alert niet alleen “de database is traag”. Het signaleert dat een klanten tabel in drie dagen geen invoer heeft ontvangen terwijl de normale frequentie dagelijks is, of dat een kolom die postcodecodes van vijf cijfers zou moeten bevatten plotseling waarden van drie cijfers vertoont.
Wat een observability-systeem monitort
- Versheid van gegevens: tijd sinds de laatste update van een tabel of partitie, vergeleken met de verwachte frequentie
- Schema conformiteit: automatische detectie van kolommen die zijn toegevoegd, verwijderd of waarvan het type is veranderd zonder validatieprocedure
- Distributieafwijking: abnormale variatie van waarden in een kolom (bijvoorbeeld, een veld “land” dat van tien verschillende waarden naar twee verandert van de ene op de andere dag)
- Koppeling aan een eigenaar: elke alert moet een persoon of team aanwijzen dat verantwoordelijk is, met de bijbehorende zakelijke impact
Deze aanpak transformeert databasebeheer in een proactief proces. In plaats van een kwaliteitsprobleem te ontdekken wanneer een maandrapport abnormale resultaten toont, wordt de anomalie gedetecteerd op het moment dat deze verschijnt.
Beheer van schemawijzigingen in gereguleerde omgevingen
Het wijzigen van de structuur van een database (een kolom toevoegen, een datatype wijzigen, een tabel verwijderen) lijkt onschuldig in een ontwikkelingsproject. In een gereguleerde omgeving moet elke wijziging van het schema worden gedocumenteerd, getest en goedgekeurd voordat deze wordt uitgerold.
De DORA-regelgeving, die van toepassing is op de Europese financiële sector, stelt expliciete eisen aan het beheer van ICT-wijzigingen. Dit betekent dat een eenvoudige toevoeging van een kolom in een bankdatabase een formele procedure vereist: beschrijving van de wijziging, regressietests, goedkeuring door een verantwoordelijke, en archivering van het goedkeuringsbewijs.
Versiebeheer toepassen op het schema
Het principe is hetzelfde als voor de broncode: elke wijziging van het schema wordt vastgelegd in een versie-script. Het script wordt herzien, getest in een pre-productieomgeving, en vervolgens in productie toegepast met een terugrolmechanisme.
Een niet-geversioneerd schema maakt elke audit trail onmogelijk. Als een kolom met persoonlijke gegevens wordt verwijderd zonder spoor, kan niemand bewijzen wanneer en waarom deze verwijdering heeft plaatsgevonden. Schema-migratietools (Flyway, Liquibase of equivalente tools geïntegreerd in DBMS) maken het mogelijk om deze geschiedenis zonder onevenredige handmatige inspanning te behouden.
Beveiliging en governance van gegevens in een DBMS
De beveiliging van een database steunt op drie aanvullende mechanismen: authenticatie (wie kan inloggen), autorisatie (wie kan wat lezen of wijzigen) en encryptie (bescherming van gegevens in rust en tijdens verzending).
Governance voegt een organisatorische laag toe. Het definieert wie verantwoordelijk is voor de kwaliteit van een dataset, welke retentieregels van toepassing zijn, en hoe de toegang in de tijd wordt herzien. Zonder governance beschermt de technische beveiliging slechts gedeeltelijk: een gebruiker met legitieme rechten kan gegevens exfiltreren als er geen gebruiksbeleid is dat zijn activiteit kadert.
- Toegangscontrole op basis van rollen: elke gebruiker of applicatie krijgt alleen de permissies die nodig zijn voor zijn functie, nooit standaard een beheerderstoegang
- Toegangslogboeken: elke gevoelige lezing of wijziging wordt vastgelegd met de identiteit van de gebruiker, de tijdstempel en de aard van de operatie
- Periodieke herziening van rechten: inactieve accounts of overbodige permissies worden regelmatig ingetrokken, niet alleen bij het vertrek van een medewerker
Deze praktijken zijn van toepassing op de productie-database, maar ook, en dat is het vaak verwaarloosde punt, op elke kopie en elke testomgeving die echte gegevens bevat.
Databasebeheer beperkt zich niet langer tot het optimaliseren van queries of het plannen van back-ups. De toename van kopieën, het toenemende gebruik van gegevens door AI-systemen en de verscherping van regelgeving vereisen dat elke omgeving, inclusief die waarvan we denken dat ze tijdelijk zijn, met hetzelfde niveau van zorgvuldigheid wordt behandeld als de productie. De zwakke schakel is zelden de hoofd-database, maar de klon die iedereen is vergeten.
