13. Relatie-index

Deze relatie-index is een controleerbare tabelvorm naast de diagrammen. Diagrammen zijn bedoeld voor begrip; deze index is bedoeld om te controleren of een verwijzing als harde database-FK, soft link, soft link + snapshot, FK + snapshot of logische verwijzing bedoeld is.

Door de keuze voor een modulaire monoliet geldt: een functionele verwijzing is niet automatisch een harde database-FK. Harde foreign keys horen in principe binnen één module, één DbContext en één schema. Verwijzingen over modulegrenzen worden standaard als soft link of soft link + snapshot gedocumenteerd.

13.1 Interpretatie van relatietypen

Type relatie	FK in veldtabel	Hoe herkennen?	Waar documenteren?	Hoe tekenen?
Harde FK	J	De brontabel en doeltabel horen bij dezelfde module, DbContext en schema, of er is een expliciete uitzondering vastgelegd.	Veldtabel, Foreign keys op databaseniveau en deze index.	Normale crow's-foot ERD-relatie.
FK + snapshot	J	Domeininterne FK met aanvullende snapshotvelden voor historische leesbaarheid.	Veldtabel, snapshottoelichting en deze index.	FK tekenen; snapshot tekstueel toelichten.
Soft link	N	Veld bevat een id uit een andere module, DbContext of schema.	Veldtabel, Functionele / logische verwijzingen zonder harde FK en deze index.	Flowchart, gestippelde contextlijn of tekstuele verwijzing.
Soft link + snapshot	N	Cross-module id plus snapshotvelden die historische context vastleggen.	Veldtabel, snapshottoelichting en deze index.	Geen harde FK-lijn; soft link en snapshot samen benoemen.
Logische verwijzing	N	Betekenis ontstaat door applicatielogica, bijvoorbeeld EntityType + EntityId.	Domeinpagina en cross-domeinpagina.	Flowchart of gestippelde contextlijn.
Readmodel/teller	N	Waarde wordt uit brondata afgeleid.	Domeinpagina of readmodeldocumentatie.	Niet als bronrelatie tekenen.

13.2 Harde FK-verwijzingen binnen modulegrenzen

Deze sectie bevat de harde FK-categorieën die binnen modulegrenzen blijven. De detailrijen blijven in de brondocumenten per databasehoofdstuk leidend en moeten dezelfde classificatie gebruiken.

Domein / schema	Harde FK-categorieën	Voorbeelden	Bron
identity	Profiel- en gebruikersinstellingen binnen identity.	Users.ProfileAvatarId -> ProfileAvatars.Id, UserSettings.UserId -> Users.Id wanneer UserSettings binnen identity blijft.	01_identiteit-en-autorisatie.md
authorization	Rol- en autorisatiebronnen binnen authorization.	UserRoles.RoleId -> Roles.Id; de verwijzing naar Users.Id wordt als soft link naar identity beoordeeld wanneer UserRoles in authorization blijft.	01_identiteit-en-autorisatie.md
relationships	Relatiebronnen, uitnodigingen en relatie-events binnen relationships.	RelationshipInvitations.RelationshipTypeId -> RelationshipTypes.Id, RelationshipEvents.RelationshipId -> UserRelationships.Id.	02_relatiebeheer.md
catalog	Niveaus, categorieën, oefeningen, modules en catalogushistorie binnen catalog.	TeacherLevelCategories.TeacherLevelId -> TeacherLevels.Id, Exercises.ExerciseModuleId -> ExerciseModules.Id, ExerciseHistory.ExerciseId -> Exercises.Id.	03_docentstructuur-en-leerlingtoegang.md
communication	Privéthreads, deelnemers, berichten en thread-events binnen communication.	PrivateMessages.ThreadId -> PrivateMessageThreads.Id, PrivateMessageThreadParticipants.ThreadId -> PrivateMessageThreads.Id.	04_communicatie-en-notificaties.md
admin	Beheerbare content, popups, footer, links, featuretoggles, notificaties en history binnen admin.	PopupDetailsHistory.PopupDetailsId -> PopupDetails.Id, FooterLinkAssignments.SiteLinkId -> SiteLinks.Id.	05_configuratie-en-contentbeheer.md
support	Tickets, ticketstatussen, discussies, sluitingen, heropenverzoeken en technische snapshots binnen support.	TicketAssignments.TicketId -> Tickets.Id, TicketClosures.ResolutionTypeId -> TicketResolutionTypes.Id.	06_ticket-en-meldingsbeheer.md
practice	Oefenruns, voortgang, gedeelde oefeningen en duplicaten binnen practice.	ExerciseRunProgress.ExerciseRunId -> ExerciseRuns.Id, ExerciseRuns.DuplicateOfExerciseRunId -> ExerciseRuns.Id.	07_oefenruns-delen-en-voortgang.md

13.3 Soft links over modulegrenzen

Deze verwijzingen blijven functioneel belangrijk, maar worden niet als harde database-FK afgedwongen. De kolom Verwijst naar in de veldtabel mag gevuld blijven, terwijl FK = N wordt gebruikt en de opmerking expliciet de soft link benoemt.

Brondomein	Verwijzingstype	Typische velden	Doeldomein	Reden voor soft link
Alle domeinen	Actor-, eigenaar-, deelnemer-, ontvanger- of beheerdervelden naar gebruikers.	CreatedByUserId, ChangedByUserId, ClosedByUserId, RecipientUserId, TeacherUserId, StudentUserId.	identity.Users.Id	Voorkomt harde afhankelijkheid van identity en ondersteunt account lifecycle/anonimisering.
Relationships	Rolcontextvelden.	FromRoleId, ToRoleId, ActorRoleId, TargetRoleId.	authorization.Roles.Id	Relatiebeheer gebruikt rolcontext, maar authorization blijft eigenaar van rollen.
Authorization	Geselecteerde of geautoriseerde onderwijscontext.	SelectedTeacherLevelId, niveau-autorisatievelden.	catalog.TeacherLevels.Id	Authorization/context mag catalogusdata gebruiken zonder catalog als harde FK-afhankelijkheid.
Practice	Historische runcontext.	UserId, LevelId, CategoryId, ExerciseId, ExerciseModuleId.	identity, catalog	Runs moeten historisch leesbaar blijven na account-, catalogus- of modulewijzigingen.
LiveMonitoring	Meekijkcontext.	ViewerUserId, ObservedUserId, ViewerRoleId, ExerciseRunId.	identity, authorization, practice	Live-audit moet domeinoverstijgend herleidbaar zijn zonder harde FK-koppeling.
Support	Ticketactoren en gegenereerde communicatie.	CreatedByUserId, AdminUserId, GeneratedPrivateMessageThreadId, GeneratedPrivateMessageId.	identity, communication	Support blijft eigenaar van ticketdata; communication blijft eigenaar van privéthreads.
Admin	Beheeractoren.	CreatedByUserId, UpdatedByUserId, DeletedByUserId, ChangedByUserId.	identity.Users.Id	Beheerhistorie blijft domeinspecifiek en mag identity niet hard koppelen.

13.4 Soft link + snapshot

Soft link + snapshot wordt gebruikt wanneer de actuele bron kan wijzigen of verdwijnen, terwijl historische weergave stabiel moet blijven.

Brontabel / model	Soft link	Snapshotvelden / context	Doel
ExerciseRuns	UserId, LevelId, CategoryId, ExerciseId, ExerciseModuleId	leerling-/niveau-/categorie-/oefening-/modulecontext op de run	Resultaatweergave, geschiedenis, PDF-export en live meekijken blijven historisch juist.
SharedExercises	SharedByUserId, SharedToUserId, bronrun/contextvelden	tekstuele momentopname van gedeelde oefeningcontext	Ontvangen gedeelde oefeningen blijven herkenbaar na latere migraties of naamwijzigingen.
LiveViewAudit	ViewerUserId, ObservedUserId, ViewerRoleId, ExerciseRunId	ViewerRoleNameSnapshot en sessiecontext	Meekijkhistorie blijft leesbaar zonder harde FK naar identity/authorization/practice.
TicketTechnicalSnapshots	TicketId blijft domeinintern; technische context is snapshot	user agent, page URL, IP-adres, rollenmomentopname	Technische context hoort bij het meldmoment en wordt niet live herberekend.

13.5 Logische verwijzingen zonder harde FK

Brontabel	Velden	Toegestane doelen	Validatie
SystemMessages	EntityType + EntityId	RelationshipInvitations, Tickets, PrivateMessageThreads, SharedExercises	Applicatielogica valideert doeltabel, objectstatus en actuele rechten.
Beheerbare contentblokken	DomainType, ContextType, BlockKey	Codevaste frontpage- of vaste-paginaposities	Applicatielogica en beheerregels valideren bekende keys.
Popups/templates/features/settings	PopupKey, TemplateKey, FeatureKey, SettingKey	Codegedreven applicatiegebruik	Applicatielogica gebruikt stabiele keys; geen generieke FK naar runtime-objecten.

13.6 Onderhoudsregel

Wanneer een veld functioneel naar een andere tabel verwijst, moet de database-informatie steeds expliciet maken of dit een harde FK, soft link, soft link + snapshot, FK + snapshot of logische verwijzing is. Een veld met FK = J mag door implementatie als database-foreign-key worden aangemaakt. Een veld met FK = N en gevulde Verwijst naar-kolom is een functionele verwijzing zonder harde FK; implementatie mag daar hoogstens indexen, applicatievalidatie en publieke modulecontracten op baseren.