Navision-Datenmodell -- Joins die nicht joinen
Aktiv 3 Subject Matter v1.0.0
Kurator
Marc Dupont
Responsable IT, Hopital du Leman
2026-03-01
Geltungsbereich: *
Narrativ
Navision verwendet überall stringbasierte natürliche Schlüssel. `No_`
ist der Primärschlüssel für Service-Aufträge, `Item_No_` für Material,
`Resource_No_` für Personal. Diese sind nicht numerisch -- es sind
alphanumerische Codes wie "SO-2026-04523".
Die Herausforderung: Navision verknüpft Entitäten über Buchungs-
gruppen, nicht über direkte Fremdschlüssel. Um "welches Material wurde
in welchem Fall verwendet" zu rekonstruieren, muss man traversieren:
Service-Auftrag → Service-Posten → Artikelposten → Artikel.
Dieser Multi-Hop-Join ist fragil. Wenn ein Posten fehlt (häufig bei
Monatsabschluss-Korrekturen), bricht die Verknüpfung stillschweigend.
Subject Matter in diesem Dossier (3)
1. Navision verwendet stringbasierte natuerliche Schluessel (No_, Item_No_) -- andere Join-Semantik als numerische FKs
Stringbasierte Schlüssel (No_, Item_No_) erfordern andere Join-Semantik als numerische FKs
System Statement
Marc Dupont
2. Navision verknuepft Entitaeten ueber Buchungsgruppen, nicht FKs -- Multi-Hop-Join durch Posten
Entitäten über Buchungsgruppen verknüpft, nicht FKs -- Multi-Hop-Pfad durch Posten
System Statement
Marc Dupont
3. Monatsabschluss-Korrekturen koennen Posten loeschen -- bricht Multi-Hop-Join stillschweigend
Monatsabschluss-Korrekturen können Posten löschen -- bricht Multi-Hop-Join stillschweigend
System Statement
Marc Dupont
navisiondata_modelnatural_keysposting_groupsjoinsledger