Database-informatie
Deze sectie beschrijft de database-informatielaag van OefenHub. De inhoud legt de beoogde tabellen, velden, relaties, sleutelsets, constraints, lifecycle-regels en databasegerichte ontwerpkeuzes vast. De database-informatie is geen zelfstandig Functioneel Ontwerp- of Software Requirements Specification-document, maar sluit aan op de vastgestelde Functioneel Ontwerp- en Software Requirements Specification-baseline en op het Technisch Ontwerp, waarin de modulaire monoliet, modulegrenzen, DbContexts, schema's, migraties en technische vertaalregels worden uitgewerkt.
De nadruk ligt op traceerbare intentie en structuur: welke data wordt persistent vastgelegd, welke relaties bestaan tussen domeinen, welke waarden zijn gesloten sleutelsets en welke businessregels moeten in databaseontwerp, applicatielogica of migraties worden geborgd. Exacte SQL-DDL, indexstrategie, performancekeuzes, caching, jobs en infrastructuurkeuzes worden uitgewerkt in het Technisch Ontwerp.
1. Doel en afbakening
Deze database-informatie beschrijft:
- tabeldoelen en verantwoordelijkheden;
- velddefinities en kernmetadata;
- foreign keys, logische verwijzingen en snapshotwaarden;
- uniqueness-, status- en enumregels;
- soft delete, audit en lifecyclegedrag;
- samenhang met Functioneel Ontwerp- en Software Requirements Specification-domeinregels;
- classificatie van harde foreign keys, soft links, soft links met snapshot en logische verwijzingen.
Deze database-informatie beschrijft niet de volledige technische implementatie. Zaken zoals concrete SQL-scripts, migratievolgorde, index-tuning, queryvormen, retentiebeleid op infrastructuurniveau, deployment en monitoring horen in het Technisch Ontwerp of beheerbeleid.
2. Standaardopbouw per tabel
Gebruik onderstaande opzet als standaard voor nieuwe tabellen. Deze opbouw is compact genoeg voor dagelijks gebruik, maar rijk genoeg om relaties, validaties, historie en ontwerpkeuzes expliciet te maken.
2.1 Tabelsamenvatting
| Tabelnaam | Categorie | Doel / verantwoordelijkheid | Gerelateerde tabellen |
|---|---|---|---|
| <Tabelnaam> | <Categorie> | <Korte beschrijving van doel en verantwoordelijkheid van de tabel.> | <Belangrijkste gerelateerde tabellen> |
2.2 Velddefinitie
In de veldtabellen staat J voor Ja en N voor Nee.
| Veldnaam | Type | Default | PK | FK | Verwijst naar | Unique | Nullable | Index | Opmerking |
|---|---|---|---|---|---|---|---|---|---|
| <Veldnaam> | <type> | <default> | J/N | J/N | <Tabel.Veld> | J/N | J/N | J/N | <Opmerking of business context> |
De kolom FK betekent uitsluitend dat de relatie als harde database-foreign-key wordt afgedwongen. Een veld kan dus functioneel naar een andere tabel verwijzen terwijl FK = N blijft. In dat geval blijft Verwijst naar gevuld, maar beschrijft de opmerking expliciet dat het om een soft link, soft link + snapshot of logische verwijzing gaat.
2.3 Relatieclassificatie bij modulegrenzen
Door de keuze voor een modulaire monoliet geldt in de database-informatie expliciet onderscheid tussen functionele verwijzing en technisch afgedwongen database-FK. De database-informatie moet voorkomen dat cross-module verwijzingen per ongeluk als harde EF Core-relaties worden gegenereerd.
| Relatieclassificatie | FK | Verwijst naar | Typische toepassing | Documentatieregel |
|---|---|---|---|---|
| Harde FK | J | Doeltabel en veld | Relaties binnen hetzelfde project, dezelfde DbContext en hetzelfde schema. | Opnemen onder Foreign keys op databaseniveau. |
| FK + snapshot | J | Doeltabel en veld | Relatie binnen dezelfde module waarbij historische leesbaarheid ook een snapshot vereist. | Zowel de harde FK als het snapshotveld toelichten. |
| Soft link | N | Doeltabel en veld | Verwijzing over module-, DbContext- of schemagrens heen. | In de opmerking beginnen met Soft link naar ...; geen harde database-FK .... |
| Soft link + snapshot | N | Doeltabel en veld | Cross-module verwijzing waarbij historische context stabiel moet blijven. | Soft link en snapshotvelden samen toelichten. |
| Logische verwijzing | N | Doeltabel alleen als dat eenduidig kan, anders tekstueel | Polymorfe of codegedreven verwijzingen zoals EntityType + EntityId. | Opnemen onder Functionele / logische verwijzingen zonder harde FK. |
| Snapshot zonder verwijzing | N | - | Momentopname zonder actuele relationele bron. | Snapshotdoel en vulmoment toelichten. |
Standaard geldt: binnen modulegrenzen zijn harde foreign keys toegestaan; over modulegrenzen zijn soft links of soft links met snapshot het uitgangspunt. Een cross-module harde FK mag alleen worden opgenomen wanneer daarvoor een expliciete en gemotiveerde uitzondering in het Technisch Ontwerp of databasehoofdstuk staat.
2.4 Ondersteunende uitwerking onder de veldtabel
Gebruik per tabel alleen de onderdelen die inhoudelijk relevant zijn.
- Validaties / constraints: toegestane enumwaarden, lengtebeperkingen, samengestelde uniqueness-regels en formele randvoorwaarden.
- Business rules: regels die niet aan één veld hangen, maar wel bepalend zijn voor systeemgedrag.
- Lifecycle / gedrag: soft delete, statusovergangen, expiry, cleanup en historisch gedrag.
- Designkeuzes: motivatie voor sleutelkeuzes, scheiding van verantwoordelijkheden en technische afwegingen op databaseniveau.
- Foreign keys op databaseniveau: harde relationele constraints die binnen de modulegrens worden afgedwongen.
- Functionele / logische verwijzingen zonder harde FK: soft links, polymorfe verwijzingen, codewaarden, snapshotvelden of payloads die bewust niet via één harde foreign key worden afgedwongen.
- FK + snapshot / soft link + snapshot: combinaties waarbij een relationele of functionele verwijzing wordt aangevuld met een historische tekst-/waarde-snapshot.
3. Praktische invulrichtlijnen
- Gebruik Doel / verantwoordelijkheid om in één zin vast te leggen waarom de tabel bestaat.
- Leg PK en FK expliciet vast. Dat maakt de tabelschets direct bruikbaar voor implementatie en review.
- Leg soft delete en auditvelden vast bij alle tabellen waar historie relevant is.
- Houd business rules buiten individuele veldopmerkingen als het gedrag tabelbreed is.
- Verwijs waar nodig naar Functioneel Ontwerp en Software Requirements Specification voor functionele betekenis en houd implementatiedetails voor het Technisch Ontwerp.
- Beschrijf database-intentie en ontwerpstructuur; exacte SQL-implementatie wordt in het Technisch Ontwerp uitgewerkt.
4. Inhoudsopgave database-informatie
| Onderdeel | Gebruik |
|---|---|
| Identiteit en autorisatie | Tabellen en regels voor gebruikers, rollen, profiel, instellingen en autorisatiecontext. |
| Relatiebeheer | Relaties, uitnodigingen, relatie-events en contextafhankelijke koppelingen tussen accounts. |
| Docentstructuur en leerlingtoegang | Niveaus, categorieën, oefeningen, collaborators en niveauautorisaties. |
| Communicatie en notificaties | Systeemberichten, privéberichten, threads, notificaties en communicatieverwijzingen. |
| Configuratie en contentbeheer | Beheerbare content, popups, templates, features, instellingen, vaste pagina's en footerdata. |
| Ticket- en meldingsbeheer | Tickets, discussie, sluitingen, heropeningen, doorzetten en technische snapshots. |
| Oefenruns, delen en voortgang | Runs, voortgang, resultaten, gedeelde oefeningen, PDF-context en modulepayloads. |
| Audit, historie en technische uitgangspunten | Auditlagen, historiepatronen, actorverwijzingen, soft links en technische datagrondslagen. |
| Nog uit te werken tabellen en domeinen | Restcategorie voor bewust geparkeerde of later te materialiseren datadetails. |
| Mailafhandeling en templates | Applicatiegestuurde e-mail, mailtemplates, templatehistory en verzendpogingen. |
| ERD en relatiemodel | Visuele en tekstuele ERD-uitwerking, deel-ERD's, cross-domeinrelaties en relatie-index. |
5. ERD en relatiemodel
Voor het visuele relatiemodel en de stapsgewijze ERD-uitwerking is een aparte submap toegevoegd: 'erd'. Deze submap start met een helikopteroverzicht en werkt daarna per domein richting deel-ERD's, cross-domeinrelaties en een relatie-index.