Trennung der Datenmodellierung in konzeptionelles Schema und Datenbank-Schema

In dem Blogeintrag „Sind relationale Datenbanken ein alter Hut oder wie sieht Datenmodellierung heute aus?“ wurde die Trennung der Datenmodellierung in die Schichten nach ANSI diskutiert. Wir waren der Meinung, dass der Übergang vom konzeptionellen Schema in das Datenbank-Schema in vielen Fällen automatisch „in einem Guss“ erfolgen kann.

Aber wofür ist diese Trennung der Datenmodellierung eigentlich gut?

Konzeptionelles Schema = Grundlage

Wir gehen davon aus, dass der Modellierer des konzeptionellen Schemas sich mit dem Datenmodell hinreichend auseinandergesetzt und mit einem geeigneten Modellierungswerkzeug bereits festgelegt hat.

Die technischen Tabellen- und Attributnamen sind bereits als Vorschlag vorbelegt, oder können generiert werden. Bei dieser Generierung können Projekt- oder Unternehmensstandards und –konventionen ohne manuellen Eingriff im Datenbankschema zentral verwaltet und gesteuert werden.

Die Datentypen sind fachlich spezifiziert und können ebenfalls automatisch auf das DB-System übertragen werden. Die Schlüsselkandidaten sind gefunden und festgelegt.

Datenbank-Schema = Performance-Optimierung

Was bleibt dann überhaupt noch für das Datenbank-Schema? Wir stehen vor der Aufgabe, widersprüchliche Zielkonflikte zu lösen:

Genauer gesagt stellt sich die Frage, was für den Datenbank-Konzeptionisten dann noch an Modellierungsarbeit verbleibt. Eigentlich nicht viel!

Zu erledigen sind Performance-Optimierungen verschiedenster Art. Dabei ist aber darauf zu achten, dass man nicht über das Ziel hinausschießt:

• Vom Zusammenführen von mehreren Attributen (z.B. aus Straße + Hausnummer ein Attribut erstellen) raten wir ab. Was ist, wenn sich der Straßenname ändert?
• Werden redundante Felder zur Beschleunigung des Datenzugriffs eingeführt („Lookupattribute“), so muss man berücksichtigen, dass diese redundante Datenhaltung gepflegt werden muss. In vielen Fällen sind die Datenbanken schnell genug und das Risiko redundanter Daten ist nicht gerechtfertigt. Oft sind diese Attribute „Falltüren“, die Inkonsistenzen hervorrufen.
• Das gleiche gilt für Denormalisierungen. Auch hier empfehlen wir dringend, die Vorteile eines normalisierten Modelles mit den Performanceverlusten abzuwägen.
• Vertikale Fragmentierungen mit fachlichem Hintergrund (per Attributen, die sich oft/wenig ändern) können, sollten bereits im konzeptionellen Schema oder gar nicht gemacht werden. Fragmentierungen aus „Performancegründen“ sollten wirklich nur im Notfall stattfinden, da sonst ohne Zwang das Modell aufgeweicht wird.
• Die horizontale Fragmentierung ist allerdings wirklich eine Aufgabe für den DB-Spezialisten und findet im internen Schema statt.
• Nur die Einführung neuer Tabellen und Attribute verbleibt als grundsätzliche Aufgabe des Datenbank-Schemas, wenn diese keine konzeptionelle Entsprechung haben. Das Gleiche gilt für die die Vergabe von Triggern und Indices. Bei Triggern muss die Einschränkung betont werden, dass ein Trigger keine Mängel des konzeptionellen Schemas beheben darf.

Ergebnis

Es gibt keine wirkliche Trennung in der Datenmodellierung in ein konzeptionelles  Schema und dem Datenbank-Schema mehr.

Die grundsätzliche Idee verbietet im Grunde auch gar nicht, dass eine 1:1-Abbildung vorgenommen wird; die Abweichungen, die erlaubt sind, dienen der Lösung des klassischen Dilemmas  „Speicherplatz versus Performance“.

Aber die Datenbanken sind schnell geworden. Und der Speicherplatz ist billig geworden.

Was bleibt, ist die fachlich korrekte, sichere und dauerhafte Pflege der Daten und des Datenmodells. Und hier tut man sich erheblich leichter, wenn ein ordentliches konzeptionelles Schema modelliert ist. Keiner tut sich einen Gefallen, im Datenbank-Schema noch einmal ein zweites Modell zu pflegen. Keiner tut sich einen Gefallen, Redundanzen im Datenbank-Schema einzuführen, die letztendlich niemand überblickt, die nicht wartbar und nicht nachvollziehbar sind.

Fazit: „Schlicht modelliert ist gut modelliert“

Und um die Ausgangsfrage zu beantworten:  Eine Trennung in zu viele Modelle bedeutet Aufwand und ist fehleranfällig.

Deshalb sollte man

• viel Sorgfalt bei der Erstellung des konzeptionellen Schemas aufwenden
• und das Datenbankschema direkt ohne viele Schnörkel daraus ableiten