2. Helikopteroverzicht

Onderstaand overzicht toont de belangrijkste datadomeinen van OefenHub. Het is bewust geen tabel-ERD, maar een leesbare kaart van de functionele datagebieden.

2.1 Interpretatie

Domein	Kernvraag
Identiteit & autorisatie	Wie is de gebruiker en welke rollen/contexten bezit die gebruiker?
Relatiebeheer	Welke formele relaties bestaan tussen gebruikers en vanuit welke rolcontext?
Docentstructuur & leerlingtoegang	Welke niveaus, categorieën, oefeningen, collaborators en autorisaties bepalen onderwijsinhoud en toegang?
Communicatie & notificaties	Welke mailbox-, thread-, template- en sitebrede communicatie bestaat er?
Configuratie & contentbeheer	Welke beheerbare content, modules, popups, features en instellingen zijn beschikbaar?
Ticket- en meldingsbeheer	Hoe worden meldingen, discussie, oplossing, sluiting en heropening vastgelegd?
Oefenruns, delen & voortgang	Welke oefenuitvoeringen, voortgang, resultaten en gedeelde oefeningen zijn vastgelegd?
Audit, historie & technische uitgangspunten	Welke historische, auditbare of technische randvoorwaarden gelden over domeinen heen?

2.2 Centrale hubtabellen

Niet iedere tabel is even belangrijk om het model te begrijpen. De volgende tabellen vormen de belangrijkste oriëntatiepunten wanneer je vanuit het helikopterbeeld wilt inzoomen.

Hubtabel	Domein	Waarom belangrijk?
Users	Identiteit & autorisatie	Centrale identiteit voor rollen, relaties, communicatie, tickets, oefenruns en auditvelden.
UserRelationships	Relatiebeheer	Functionele bron voor vriendschap, ouder-/voogdrelaties, docentrelaties en docent-docentrelaties.
TeacherLevels	Docentstructuur & leerlingtoegang	Hoofdingang naar niveaus, categorieën, oefeningen, collaborators en leerlingautorisaties.
Exercises	Docentstructuur & leerlingtoegang	Concrete configureerbare oefening die naar een technische module verwijst.
ExerciseRuns	Oefenruns, delen & voortgang	Historische bron voor resultaten, geschiedenis, PDF-export, live meekijken en duplicaten.
SharedExercises	Oefenruns, delen & voortgang	Administratief record voor ontvangen gedeelde oefeningen voordat de ontvanger een eigen run start.
SystemMessages	Communicatie & notificaties	Mailboxbron voor systeemberichten, met beperkte logische verwijzing via EntityType + EntityId.
PrivateMessageThreads	Communicatie & notificaties	Hoofdrecord van een privégesprek; deelnemers, berichten, leespositie en thread-events hangen hier onder.
Tickets	Ticket- en meldingsbeheer	Hoofdrecord van een melding, met discussie, sluiting, heropening en history eromheen.
ContentBlocks	Configuratie & contentbeheer	Uniforme tekstuele bron voor frontpages, vaste pagina's en footercontent zonder vrije pagebuilder te worden.
PopupDetails	Configuratie & contentbeheer	Beheerbare popuptekst en knoplabels voor bestaande codegedreven popupkeys.
SiteFeatureToggles	Configuratie & contentbeheer	Sitebrede schakelaars die functies beschikbaar maken of tijdelijk blokkeren zonder domeindata te verwijderen.
SystemMessageTemplates	Configuratie & contentbeheer	Beheerbare sjablooninhoud voor systeemcommunicatie; geen runtime mailboxbericht.
SiteNotifications	Configuratie & contentbeheer	Planbare frontpage-overlays per doelgroep, los van mailbox-systeemberichten en popupregister-popups.

2.3 Zoomprincipe

Het ERD-hoofdstuk gebruikt bewust geen één groot diagram. In plaats daarvan is het zoommodel opgebouwd in drie lagen:

1. Helikopterlaag: deze pagina toont de domeinen en hubtabellen.
2. Domeinlaag: iedere domeinpagina toont de tabellen en kernrelaties binnen één databasehoofdstuk.
3. Contextlaag: wanneer een domein sterk met andere domeinen samenhangt, toont de domeinpagina een compact contextdiagram naast het interne ERD.

Voor Oefenruns, delen en voortgang is die derde laag belangrijk: het domein heeft zelf maar drie tabellen, maar raakt identiteit, docentstructuur, relatiebeheer, communicatie en live meekijken.

Voor Communicatie en notificaties is dezelfde contextlaag nodig om een andere reden: het interne communicatiemodel is klein, maar SystemMessages.EntityType + EntityId verwijst functioneel naar relatie-uitnodigingen, tickets, privéthreads en gedeelde oefeningen. Daarnaast bestaan sitebrede notificaties en templates in het configuratie-/contentdomein, terwijl zij functioneel wel communicatiegedrag sturen.

Voor Ticket- en meldingsbeheer is de contextlaag nodig omdat het interne ticketmodel een duidelijke lifecycle heeft, maar tegelijkertijd veel actoren en neveneffecten raakt. Tickets is het hoofdrecord, TicketAssignments vormt de behandelcontext, TicketClosures is de formele sluitbron, en doorzetten naar docent kan reguliere privéberichtrecords genereren zonder dat ticketdiscussie en privéberichten hetzelfde domein worden.

Voor Configuratie en contentbeheer is de contextlaag nodig omdat het domein vooral brondata voor ander gedrag bevat. SystemMessageTemplates sturen inhoud van toekomstige systeemberichten, PopupDetails sturen gebruikersfeedback, SiteNotifications sturen tijdelijke frontpage-overlays, SiteFeatureToggles beïnvloeden functiebeschikbaarheid en ContentBlocks leveren tekstuele pagina-inhoud. Die effecten ontstaan meestal via applicatielogica en niet via directe FK's naar de runtime-objecten.

2.4 Communicatie als brugdomein

Communicatie is in dit ERD-hoofdstuk een brugdomein. Het bevat zelf maar vijf tabellen, maar verbindt meerdere functionele flows:

• relatie-uitnodigingen informeren gebruikers via SystemMessages;
• gedeelde oefeningen gebruiken SystemMessages als ingang naar SharedExercises;
• tickets gebruiken SystemMessages voor meldingsupdates;
• doorzetten naar docent kan een PrivateMessageThreads- en PrivateMessages-record genereren;
• badges en mailboxreadmodels combineren systeemberichten, privéberichten en thread-events zonder aparte tellertabel.

Deze brugfunctie is de reden dat de communicatiepagina naast een intern ERD ook flowdiagrammen en logische verwijzingen bevat.

2.5 Tickets als lifecycle-domein

Ticket- en meldingsbeheer is minder een statisch tabellencluster en meer een lifecycle-domein rond één hoofdrecord: Tickets. De tabellen eromheen hebben duidelijk gescheiden rollen:

• TicketAssignments bepaalt of er een actieve behandelcontext met beheerders bestaat;
• TicketDiscussionMessages bevat inhoudelijke interne en externe communicatie;
• TicketHistory bevat compacte auditregels en geen volledige discussie;
• TicketClosures is de formele bron voor oplossen, sluiten, accepteren en heropentermijn;
• TicketReopenRequests maakt heropenacties expliciet en overschrijft eerdere sluitingen niet;
• TicketForwardedToTeacher legt de uitzonderlijke doorzetflow vast en koppelt naar reguliere privéberichtrecords;
• TicketTechnicalSnapshots bewaart de technische context op het moment van melden.

Daarom bevat de ticketpagina naast het interne ERD ook lifecycle- en flowdiagrammen voor sluiten, heropenen, doorzetten en systeemcommunicatie.

2.6 Configuratie als brondata voor runtimegedrag

Configuratie en contentbeheer is een ondersteunend brondomein. De tabellen leggen beheerbare waarden vast die elders in de applicatie worden gebruikt, maar zij zijn meestal niet zelf het runtime-object dat de gebruiker ziet of ontvangt.

• SystemMessageTemplates leveren tekst en placeholderstructuur voor toekomstige SystemMessages, maar bestaande mailboxberichten worden niet herschreven door een templatewijziging.
• PopupDetails leveren tekst, knoplabels en beperkte inputdefinities voor bekende popupkeys; popupacties en custom renderers blijven codegedreven.
• SiteNotifications zijn tijdelijke frontpage-overlays met doelgroep, planning en displayregel; zij zijn geen mailbox-systeemberichten.
• SiteFeatureToggles en SystemSettings sturen sitebreed gedrag, maar vervangen geen autorisatiecontrole en verwijderen geen domeindata.
• ContentBlocks, SiteLinks, FooterSections en FooterLinkAssignments leveren beheerbare tekst en linkplaatsingen binnen codevaste pagina- en footerstructuren.

Daarom gebruikt de configuratiepagina naast een intern ERD ook flowdiagrammen voor contentwijzigingen, footerplaatsingen, systeemnotificaties, featuretoggles en templategebruik.

2.7 Audit, historie en technische uitzonderingen

Audit en historie vormen geen losstaand functioneel domein naast de rest, maar een overkoepelende validatielaag. De belangrijkste patronen zijn:

• actor-audit naar Users, bijvoorbeeld ChangedByUserId, ClosedByUserId of AssignedByUserId;
• append-only historytabellen zoals CategoryHistory, ExerciseHistory, RelationshipEvents, TicketHistory en configuratie-history;
• formele lifecyclebronnen zoals TicketClosures, TicketReopenRequests en TicketAssignments;
• FK + snapshot-combinaties zoals LiveViewAudit.ViewerRoleId met ViewerRoleNameSnapshot;
• logische verwijzingen zonder harde FK, vooral SystemMessages.EntityType + EntityId;
• JSON/base64-payloads voor modulespecifieke oefen- en voortgangsdata;
• readmodels, tellers en badges die uit brondata worden afgeleid.

De auditpagina helpt vooral om deze patronen consequent te lezen in alle deel-ERD's.

2.8 Gebruik na ronde 9

Gebruik de domeinkaart om van dit helikopterbeeld naar een concreet deel-ERD te navigeren. Voor impactanalyse over domeingrenzen heen zijn vooral Cross-domein relaties en de Relatie-index bedoeld.

De eerste versie van het ERD-hoofdstuk is compleet genoeg voor review. Doorlopend onderhoud bestaat vooral uit validatie tegen EF/migrations, verdere opsplitsing van te grote diagrammen en het actueel houden van de relatie-index wanneer tabeldefinities wijzigen.