Fachliche Zusammenhänge in tragfähige Datenstrukturen übersetzen

Geschäftsobjekte eindeutig beschreiben

Wir führen Fachbegriffe, Objekte, Attribute und Regeln zu einem gemeinsamen Informationsmodell zusammen. Gleichlautende Begriffe mit unterschiedlicher Bedeutung werden getrennt; unterschiedliche Bezeichnungen für dasselbe Objekt werden kenntlich gemacht.

Für jedes wesentliche Geschäftsobjekt betrachten wir:

• fachliche Definition
• Identität und Schlüssel
• Attribute und Wertebereiche
• Beziehungen und Kardinalitäten
• Status und zulässige Statusübergänge
• Entstehung und Änderung
• Gültigkeitsbeginn und Gültigkeitsende
• historische Nachvollziehbarkeit
• fachliche Verantwortung
• führendes System
• abhängige Anwendungen und Auswertungen

Ein Kunde, Auftrag, Vertrag, Betriebsmittel oder Messwert ist nicht allein durch seine Spalten definiert. Entscheidend sind seine Bedeutung, sein Lebenszyklus und seine Rolle im Geschäftsprozess.

Fachliche Regeln in Tabellen und Constraints übersetzen

Aus dem Informationsmodell entwickeln wir die relationale Struktur. Entitäten und Beziehungen werden auf Tabellen, Spalten, Schlüssel und Constraints abgebildet.

Dabei betrachten wir:

• natürliche und technische Schlüssel
• Primär- und Fremdschlüssel
• eindeutige Schlüssel
• Pflicht- und optionale Attribute
• Datentypen, Wertebereiche und Einheiten
• Referenz- und Stammdaten
• 1:1-, 1:n- und n:m-Beziehungen
• Check Constraints
• Lösch- und Änderungsregeln
• Null-Semantik
• Transaktionsgrenzen
• konkurrierende Änderungen
• Historien- und Gültigkeitstabellen

Integritätsregeln werden möglichst dort verankert, wo sie unabhängig von einer einzelnen Anwendung gelten. Eine fachliche Regel, die nur in einer Benutzeroberfläche geprüft wird, kann durch Schnittstellen, Batch-Verarbeitung oder andere Anwendungen umgangen werden.

Nicht jede Geschäftsregel gehört als Constraint in die Datenbank. Komplexe oder kontextabhängige Regeln können in Packages, Services oder Anwendungen liegen. Ihre Zuständigkeit und Wirkung müssen jedoch nachvollziehbar bleiben.

Redundanz vermeiden, ohne die reale Nutzung zu ignorieren

Normalisierung trennt unterschiedliche Sachverhalte und reduziert widersprüchliche Mehrfachspeicherung. Sie schafft klare Abhängigkeiten und erleichtert die Erhaltung der Datenintegrität.

Wir prüfen insbesondere:

• funktionale Abhängigkeiten
• wiederholte Attributgruppen
• vermischte Geschäftsobjekte
• mehrfach gespeicherte Fakten
• indirekte Abhängigkeiten
• Änderungs-, Einfüge- und Löschanomalien
• historisch gewachsene Hilfsspalten
• abgeleitete und berechnete Werte
• unkontrollierte Kopien und Zwischentabellen

Gezielte Denormalisierung kann sinnvoll sein, wenn eine nachgewiesene Arbeitslast dadurch wesentlich besser verarbeitet werden kann. Sie bleibt eine bewusste Architekturentscheidung mit dokumentierter Herkunft, Aktualisierungsregel und Verantwortlichkeit.

Eine redundante Information benötigt eine klare Antwort auf drei Fragen:

1. Wo liegt ihre führende Quelle?
2. Wann und wodurch wird die Kopie aktualisiert?
3. Wie werden Abweichungen erkannt und behandelt?

Ohne diese Regeln wird Denormalisierung zu unkontrollierter Datenvervielfältigung.

Aktuelle Wahrheit und zeitliche Entwicklung unterscheiden

Geschäftsdaten besitzen häufig mehr als einen Zeitbezug. Ein Datensatz kann heute erfasst werden, fachlich aber seit gestern gelten. Eine spätere Korrektur darf den damals bekannten Informationsstand nicht zwingend überschreiben.

Wir unterscheiden deshalb, soweit fachlich erforderlich:

• Erfassungszeitpunkt
• technische Änderungszeit
• fachlicher Gültigkeitsbeginn
• fachliches Gültigkeitsende
• aktuellen Zustand
• früheren Zustand
• geplanten zukünftigen Zustand
• Korrektur und echte fachliche Änderung

Historisierung wird nicht pauschal für jede Tabelle eingeführt. Wir klären, welche zeitlichen Fragen der Geschäftsprozess, die Revision, Abrechnung oder Analyse tatsächlich beantworten muss.

Daraus können einfache Änderungshistorien, Gültigkeitszeiträume, Ereignismodelle oder getrennte fachliche und technische Zeitachsen entstehen.

Zusammengehörige Veränderungen auch gemeinsam behandeln

Eine Transaktion beschreibt nicht nur eine technische Folge von SQL-Anweisungen. Sie muss einen fachlich konsistenten Zustandsübergang abbilden.

Wir untersuchen:

• welche Änderungen fachlich zusammengehören
• wann ein Vorgang vollständig ist
• welche Zwischenzustände sichtbar sein dürfen
• welche Prüfungen vor dem Commit erforderlich sind
• wie konkurrierende Änderungen behandelt werden
• welche Fehler einen Rollback verlangen
• wie Wiederholungen und Mehrfachverarbeitung erkannt werden
• welche Verarbeitung nach einem Abbruch wiederaufgenommen werden kann

Zu große Transaktionen erhöhen Sperr-, Undo- und Wiederanlaufrisiken. Zu kleine Transaktionen können fachlich unvollständige Zustände sichtbar machen. Die geeignete Grenze ergibt sich aus Geschäftsregel, Mengengerüst, Parallelität und Fehlerbehandlung.

Das Modell für seine tatsächliche Nutzung vorbereiten

Das fachlich korrekte Modell wird mit den erwarteten Verarbeitungsvorgängen abgeglichen. Wir betrachten, wie Anwendungen Daten suchen, verbinden, verändern, laden und archivieren.

Dazu gehören:

• häufige Such- und Filterkriterien
• Join-Beziehungen
• Sortierungen und Gruppierungen
• Online- und Batch-Verarbeitung
• Schreib- und Leseverhältnis
• Datenvolumen und Wachstum
• parallele Zugriffe
• historische Abfragen
• Lade- und Archivierungsverfahren
• zeitkritische Geschäftsprozesse

Aus diesen Zugriffsmustern ergeben sich Anforderungen an Indizes, Partitionierung, Materialisierung und physisches Datenbanklayout. Diese Maßnahmen verändern nicht die fachliche Bedeutung des Modells. Sie bestimmen, wie effizient und betreibbar es auf einer konkreten Datenbankplattform umgesetzt wird.

Die detaillierte Bewertung ihrer Wirkung erfolgt im Datenbank-Tuning unter realer beziehungsweise repräsentativer Last.