Datenmodelle
Teil von Datenmodelle für interne Apps
Eindeutige Datensatzkennungen festlegen
Stabile IDs für interne Apps auswählen: Geltungsbereich, Vergabe, Eindeutigkeitsregeln, Beziehungen und Importzuordnung festlegen.
Eine Datensatzkennung sollte in ihrem festgelegten Geltungsbereich eindeutig sein, beim Anlegen vergeben und bei späteren Änderungen stabil bleiben. Trennen Sie sie von Anzeigenamen und Vorgangsnummern, deren Inhalt oder Format sich ändern kann. Legen Sie außerdem fest, welche Datenregel die Eindeutigkeit erzwingt und welche Beziehungen die Kennung verwenden.
Wichtige Fakten zur Datensatzkennung
- Stabilität
- Kennung bleibt nach Änderungen konstant
- Einmalige Vergabe
- Einzelner Datensatz = eine Kennung
- Geltungsbereich
- Kann tabellenweit, mandantenbasiert oder über Systeme hinweg gelten
- Importfähigkeit
- Kennung muss beim Wechsel zwischen Plattformen erhalten bleiben
Zuerst den Geltungsbereich bestimmen
„Eindeutig“ kann innerhalb einer Tabelle, eines Mandanten oder über mehrere Datenquellen hinweg gelten. Eine Fallnummer 184 kann in zwei Abteilungen vorkommen. Arbeiten beide Abteilungen in einer gemeinsamen Tabelle, reicht die Fallnummer allein nicht als eindeutiger Schlüssel.
Das Modell kann eine tabellenweit eindeutige interne Fall-ID und daneben die fachliche Kombination aus Abteilung und Fallnummer führen. Für diese Kombination kann eine zusätzliche Eindeutigkeitsregel sinnvoll sein, sofern ihre Teile fachlich stabil sind. Klären Sie vor der Wahl des Formats:
- Wer vergibt die Kennungeine zentrale Datenquelle, mehrere getrennte Stellen oder ein Import?
- Kann ein Datensatz umbenannt, verschoben oder zusammengeführt werden?
- Welche anderen Datensätze verweisen auf ihn?
- Welche Kennung muss bei Export und Plattformwechsel erhalten bleiben?
Für Nutzer kann die App eine lesbare Vorgangsnummer anzeigen. Beziehungen brauchen ein Identitätsmerkmal, das die vorgesehenen Änderungen übersteht.
Format und Datenregel unterscheiden
Eine fortlaufende Zahl kann bei zentraler Vergabe genügen. Werden Kennungen unabhängig an mehreren Stellen erzeugt, braucht es eine abgestimmte Vergabe oder ein geeignetes Verfahren für verteilte Erzeugung. Korrekt erzeugte UUIDs sind dafür eine Möglichkeit: Kollisionen sind sehr unwahrscheinlich, aber nicht logisch ausgeschlossen. Eine UUID entscheidet auch nicht, ob zwei Datensätze denselben realen Fall beschreiben.
Automatisch erzeugte Werte sollten durch eine Datenregel abgesichert werden. PostgreSQL weist ausdrücklich darauf hin, dass eine Identity-Spalte allein keine Eindeutigkeit garantiert. Ein Primärschlüssel erzwingt dort eindeutige, nicht leere Werte. Eine zusätzliche UNIQUE-Regel kann eine fachliche Nummer oder Feldkombination schützen.
Bei optionalen Feldern ist die Behandlung leerer Werte vorab zu klären: Ob und wie viele leere Werte eine Eindeutigkeitsregel zulässt, hängt von der konkreten Regel und vom jeweiligen System ab und sollte im vorgesehenen System geprüft werden.
Format und Datenregel unterscheiden
- Fortlaufende Zahl
- Erforderlich: zentrale Vergabe oder abgestimmtes Verfahren; keine Kollision bei zentraler Erzeugung
- UUID
- Sehr unwahrscheinliche Kollisionen; geeignet für verteilte Systeme; erzwingt keine fachliche Eindeutigkeit
- Identity-Spalte (PostgreSQL)
- Garantiert keine Eindeutigkeit allein; nur mit Primärschlüssel oder UNIQUE-Regel
- Zusammengesetzter Schlüssel
- Muss aus stabilen, eindeutigen Teilen bestehen; z. B. Abteilung + Fallnummer
Beziehungen und Importe an der Kennung ausrichten
Angenommen, ein Fall hat mehrere Notizen. Jede Notiz verweist auf die interne Fall-ID. Ändert sich der sichtbare Falltitel, bleibt die Zuordnung bestehen.
Beim Import muss dieselbe Quellzeile demselben Zieldatensatz zugeordnet werden können. Halten Sie dafür Quellsystem, Geltungsbereich der Quellkennung und Zielkennung fest. Klären Sie vorab, was bei fehlenden, doppelt vergebenen oder widersprüchlichen Quellkennungen geschieht. Eine neue Ziel-ID bei jedem Importlauf würde bestehende Beziehungen und die Wiedererkennung erschweren.
Ein zusammengesetzter Schlüssel kann passen, wenn seine Teile zusammen eindeutig und stabil sind. Kann etwa eine Abteilung umbenannt oder ein Fall verschoben werden, entstehen zusätzliche Aufgaben für Verweise und Importe. Eine unveränderliche interne ID und eine separat geschützte fachliche Kombination trennen diese Aufgaben.
Grenzfälle vor der Nutzung prüfen
Legen Sie erwartete Ergebnisse für vier Fälle fest: derselbe Importdatensatz zweimal, zwei verschiedene Fälle mit gleichem Namen, dieselbe lokale Nummer in zwei Abteilungen und ein Fall mit geänderter sichtbarer Nummer. Prüfen Sie im vorgesehenen System, welche Anlage abgewiesen, welcher Eintrag wiedererkannt und welcher als neuer Fall gespeichert werden soll.
Dokumentieren Sie Kennungsfeld, Geltungsbereich, Vergabestelle, Eindeutigkeitsregel und Importzuordnung. Die Kennung erleichtert die Zuordnung; über Lese- oder Bearbeitungsrechte entscheidet sie nicht.
