Datenmodelle für interne Apps

Ein Datenmodell für eine interne App klärt vier Fragen: Welche Dinge werden erfasst, welche Angaben gehören zu ihnen, wie hängen Datensätze zusammen und wo wird jeder aktuelle Wert verbindlich gepflegt? Beginnen Sie mit einem konkreten Arbeitsfall. Eine Liste gewünschter Eingabefelder beantwortet diese Fragen noch nicht.

Vom Arbeitsfall zu Datensätzen

Angenommen, Beschäftigte reichen Materialanforderungen ein. Eine Anforderung hat einen Status und eine zuständige Person. Sie kann mehrere Positionen enthalten; jede Position nennt einen Artikel und eine Menge.

Ein erster Entwurf umfasst daher Anforderung, Position und Artikel. Ob Beschäftigte eigene Datensätze in der App brauchen oder aus einem bestehenden Verzeichnis kommen, hängt von der gewählten Datenquelle ab.

Beschreiben Sie jede Datensatzart in einem Satz: „Ein Datensatz steht für genau …“. Eine Position steht beispielsweise für eine bestimmte Artikelzeile innerhalb einer Anforderung. Diese Definition hilft zu entscheiden, ob ein Feld zur Position, zur Anforderung oder zum Artikel gehört.

Felder mit überprüfbaren Regeln versehen

Ordnen Sie einem Feld nicht nur einen Namen, sondern auch einen passenden Datentyp und eine fachliche Regel zu. Ein Datentyp schränkt ein, welche Art von Wert gespeichert werden kann; für viele Anforderungen ist diese Grenze allein zu grob. Bei einer Menge kann etwa zusätzlich festgelegt werden, dass sie einen positiven Wert haben muss.

PostgreSQL kann solche Bedingungen mit Einschränkungen wie CHECK durchsetzen. Eine CHECK-Regel prüft einen Ausdruck und weist einen Schreibvorgang zurück, wenn die Bedingung nicht erfüllt ist. Das gilt laut PostgreSQL-Dokumentation auch dann, wenn der unzulässige Wert aus einer Vorgabe stammt.

Wichtige Datenmodellierungsregeln nach PostgreSQL

Beziehungen und Regeln sichtbar machen

Eine Position braucht einen Verweis auf ihre Anforderung. Wenn derselbe Artikel in mehreren Anforderungen vorkommen kann, verweist die Position auch auf den Artikel. So bleiben Angaben zum Vorgang und Angaben zum Artikelstamm getrennt.

Klären Sie, welche Zustände erlaubt sind: Darf eine Anforderung zunächst ohne Position gespeichert werden, und muss jede gespeicherte Position einer Anforderung zugeordnet sein? Ein Verweis allein legt nicht fest, ob die Angabe verpflichtend ist. Halten Sie außerdem fest, was mit Positionen geschieht, wenn eine Anforderung zurückgenommen wird. PostgreSQL führt Primärschlüssel- und Fremdschlüssel-Einschränkungen als eigene Typen auf.

Für Felder und Beziehungen lassen sich unterschiedliche Regeln kombinieren: Ein Wert kann erforderlich und zugleich eindeutig sein; eine Bedingung kann außerdem mehrere Felder gemeinsam prüfen. PostgreSQL unterscheidet unter anderem CHECK-, NOT-NULL-, UNIQUE-, Primärschlüssel- und Fremdschlüssel-Einschränkungen.

Datenverantwortung festlegen

Klären Sie je Datensatzart, wer Begriffe und zulässige Werte fachlich festlegt und wer die Daten im Alltag pflegt. Die Zuständigkeit sollte auch umfassen, wer bei widersprüchlichen oder unvollständigen Angaben entscheidet. So wird aus der Frage „Wer kann das Feld bearbeiten?“ zusätzlich die Frage, wer für einen verlässlichen Wert einsteht.

Legen Sie außerdem fest, wer die Daten nutzen darf und nach welchen Regeln sie verarbeitet werden. Ein Data-Governance-Rahmen kann Verantwortlichkeiten, Prozesse und Qualitätsstandards verbindlich machen. Für den Modellentwurf reicht zunächst eine knappe Zuordnung: Datensatzart, verantwortliche Stelle und geltende Qualitätsregel.

Aktuelle Werte und frühere Stände unterscheiden

Wird die aktuelle Artikelbezeichnung im Artikelstamm gepflegt, kann die App sie in einer Position über den Artikelverweis anzeigen. Eine zweite frei bearbeitbare Bezeichnung würde Änderungen an mehreren Stellen nötig machen.

Eine freigegebene Anforderung kann dagegen den damals bestätigten Artikeltext als Beleg benötigen. Kennzeichnen Sie ihn als historischen Stand und legen Sie fest, wann er übernommen wird.

Fragen Sie bei jeder Wiederholung, ob sie ein Verweis, eine berechnete Anzeige, eine unnötige zweite Pflegestelle oder eine bewusst gespeicherte Momentaufnahme ist.

Vergleich: Aktueller Wert vs. historischer Stand

Vorteile und Risiken von freigegebenen Artikelbezeichnungen

Kennungen vor der Datenübernahme festlegen

Für jede dauerhaft gespeicherte Datensatzart ist ein stabiles Identitätsmerkmal sinnvoll. Bearbeitbare Namen, Titel und Zeilennummern einer Ansicht eignen sich schlecht, wenn sie sich ändern oder mehrfach vorkommen können.

Eine interne Kennung lässt sich von einer sichtbaren Vorgangsnummer trennen. Bei einer Datenübernahme muss die Zuordnung alter und neuer Kennungen erhalten bleiben, damit Beziehungen nachvollziehbar bleiben.

Eindeutigkeit ist eine durchzusetzende Regel, kein Zahlenformat. In PostgreSQL garantiert auch eine automatisch erzeugte Identity-Spalte für sich genommen keine eindeutigen Werte; dafür braucht sie einen Primärschlüssel oder eine Eindeutigkeitsregel.

Den Entwurf an Fällen prüfen

Gehen Sie eine neue Anforderung mit zwei Positionen, die Korrektur eines Artikelnamens und die Rücknahme einer Anforderung durch. Halten Sie jeweils fest, welcher Datensatz entsteht oder sich ändert, welche Werte nur angezeigt werden und welche Beziehungen bestehen bleiben. Ergänzen Sie einen Fall mit fehlender Angabe und einen mit unbekanntem Artikel.

Das Ergebnis sollte die Datensatzarten, wichtigen Felder, Kennungen, Beziehungen, verbindlichen Quellen und erlaubten Änderungen beschreiben. Darauf lassen sich Formulare und Bearbeitungsansichten aufbauen.

Ergänzen Sie beim Prüfen einen ungültigen Wert, etwa eine nicht positive Menge, und beobachten Sie, ob die vorgesehene Datenquelle ihn tatsächlich zurückweist. Notieren Sie für jede Regel, ob sie technisch durchgesetzt wird oder als fachliche Vereinbarung bestehen bleibt.

Prüfliste für die Datenmodellierung