MID GmbH

              Leistungen          Kundenservice          Downloads            Unternehmen

Sind relationale Datenbanken ein alter Hut oder wie sieht Datenmodellierung heute aus?

Relationale Datenbanken gibt es nun schon seit gefühlten Ewigkeiten, da stellt sich manchmal die Frage, ob sich bei der Datenmodellierung eigentlich noch was Neues tut, oder ob das alles „ein alter Hut“ ist. In diesem Beitrag wird deshalb geklärt, was bei der Datenmodellierung eigentlich zu tun ist und ob relationale Datenbanken  noch zeitgemäß sind.

Ebenen des Entwicklungsprozesses

Das grundsätzliche Vorgehen bei der Datenmodellierung ist traditionell angelehnt an die „Architektur nach ANSI/SPARC“, siehe auch https://de.wikipedia.org/wiki/Datenmodell. Es geht hier im Wesentlichen um die Gliederung des Entwicklungsprozesses von Datenmodellen in die folgenden Ebenen:

  1. Das „Konzeptuelle Schema“ (auch konzeptionelles bzw. semantisches Schema)
  2. Das „Datenbank-Schema“ (auch logisches Schema)
  3. Das „Interne Schema“ (auch physisches Schema)

 

Ebenen-Architektur-nach-ANSI_SPARC.png
 
Relationale Datenbanken: Ebenen Architektur nach ANSI/SPARC

 

Um einen Eindruck zu erhalten, ob diese Gliederung noch zeitgemäß ist, werden die einzelnen Ebenen im folgenden kurz beleuchtet:

1.      Konzeptuelles Modell oder auch  konzeptionelles bzw. semantisches Datenmodell

Das konzeptionelle Schema soll die Gesamtheit der Unternehmensdaten mit logischen Zusammenhängen beschreiben, und zwar unabhängig von der Verwendung und der technischen Realisierung.

Dieses implementierungsunabhängige Modell wird z.B. mit ER-Diagrammen (ursprünglich von Peter Chen) oder auch mit UML-Diagrammen dargestellt. Dieses „idealtypische“ Modell sollte redundanzfrei nach der Normalformenlehre erstellt werden. Hier ein Beispiel:

 

ER-Modell, hier bereits mit Vorschlägen für die physische Implementierung
 
ER-Modell, hier bereits mit Vorschlägen für die physische Implementierung

 

2.      (logisches) Datenbankschema

Das logische Datenbankschema beschreibt die Abbildung des konzeptionellen Schemas auf die Regeln des zu verwendenden Datenbankmanagementsystems, z. B. dem relationalen Datenmodell.

Hier ist die Entscheidung zu treffen, welche Datenbankart (relational, hierarchisch, …) anzuwenden ist. Ebenso sind aus den konzeptionellen Entitäten dann die physischen Tabellen zu erstellen. Dazu gehört auch, die technischen Komponenten wie Schlüsselvergabe, Datentypen usw. festzulegen. Zuletzt wird der Datenbankdesigner weitere Optimierungen durch z.B. Denormalisierungen und Fragmentierungen vornehmen wollen. Somit entwickelt sich das Beispiel wie folgt:

 

DB-Modell
DB-Modell

 

3.      internes Schema / physisches Datenbankschema

Das interne Schema enthält weitere, zum technischen Betrieb erforderliche oder zweckmäßige Festlegungen, z. B. Indexstrukturen zur Zugriffsoptimierung.

Sinn des Ganzen

Und was soll das Ganze bezwecken? Das wesentliche Ziel dieser Vorgehensweise ist, ein anwendungsunabhängiges Modell zu Laufen zu bekommen: Das Modell muss redundanzfrei, beliebig erweiterbar, gut zu warten und flexibel sein, zugleich aber performante und sichere Auswertungen unabhängig vom konkreten DB-Zielsystem ermöglichen. Das Modell muss für den fachlichen Anwender, aber zugleich für den Datenbankentwickler geschaffen sein.

Nun aber zurück zur Ausgangsfrage:

„Sind relationale Datenbanken, also Datenmodellierung nach diesen Ebenen, noch zeitgemäß?…  und falls ja, wie wird die Datenmodellierung gelebt?“

Es ist natürlich nach wie vor unabdingbar, dass die fachlichen und technischen Aspekte unabhängig voneinander, aber dennoch eng verwoben vorgehalten werden.

Aber: Es besteht eine Verschiebung der Fronten weg vom Datenbank-Schema!

Die Fronten haben sich zwischenzeitlich verschoben, denn die Stellung der Datenbankschema-Schicht ist zugunsten der konzeptionellen Schicht unbedeutender geworden. Die wichtigste Erkenntnis ist, dass klassischerweise ein (konzeptionelles) ER-Datenmodell in eine relationale Datenbank umgesetzt wird. Ebenso kann mit geeigneten Datenmodellierungswerkzeugen der Analyst der ersten Ebene Vorschläge für die Ausarbeitung in der zweiten Ebene tätigen.

Die Frage, in wie weit Optimierungen mittels z.B. Denormalisierungen überhaupt noch vorgenommen werden müssen, wird in einem weiteren Blog-Beitrag ausgeführt.

 „Tektonische“ Verschiebung der Begriffe

In der Praxis hat sich folglich eingebürgert, das konzeptionelle Modell als reines Geschäftsobjektmodell umzusetzen; hier werden die grundsätzlichen Objekte einer Organisation mit den jeweiligen fachlichen Schlüsseln in Verbindung gesetzt. Die hier erstellten Objekte werden i.A. auf mehrere Objekte des Datenmodells umgesetzt, wobei die fachlichen Schlüssel durch technische ersetzt werden können. Idealerweise erfolgt die Umsetzung natürlich toolgestützt.

Dieses Modell ist die Basis der Kommunikation zwischen dem Fachbereich und der IT. Hier unser Beispiel in ER-Notation:

 

Geschäftsobjektmodell
 
Geschäftsobjektmodell

 

Das führt zu einer Verschiebung der Begrifflichkeit. Die ursprünglich ausführlichere Modellierung des konzeptionellen Modells wird dann in das logische Schema verlagert, die Datenbankumsetzung wird in das physische Schema verlagert.

Zusammenfassung

Die Antwort auf die Ausgangsfrage ist aus meiner Sicht also: Ja, es gibt diese Schichten noch, aber

  • das konzeptionelle Schema wird durch ein Geschäftsobjektmodell abstrahiert
  • das konzeptionelle Schema und das Datenbankschema kann bei einem ER-Datenmodell, einer relationalen Datenbank und einem Modellierungswerkzeug, das diese Ebenen bündelt, effektiv „in einem Guss“ modelliert werden.

Das Datenmodell muss integriert sein: Änderungen der Fachwelt müssen auf die Technik abbildbar sein. Die Anforderungen sind dokumentiert. Und so wird vorgegangen:

  • Es wird ein Geschäftsobjektmodell mit den Kernentitäten erstellt
  • Aus diesem Modell wird das konzeptionelle Schema erstellt
  • Wenn sich das konzeptionelle Schema vom Datenbankschema nicht unterscheidet, dann erfolgt ein automatisches Mapping, das Datenbankschema ist „ready to use“.
  • Wenn sich die Ebenen automatisierbar unterscheiden, so erfolgt über eine Engineering-Aktion eine Anpassung des Datenbankschemas. Intern sind die Strukturen weiterhin verknüpft.
  • Anpassungen und Optimierungen können jederzeit „additiv“ im Datenbankschema vorgenommen werden

Das Ergebnis ist ein ganzheitliches Modell über die Ebenen der Datenmodellierung:

  1. mit einem Geschäftsobjektmodell zur Kommunikation mit dem Fachbereich
  2. das Modell ist, wenn möglich, bereits im konzeptionellen Schema vordefiniert
  3. ansonsten ist das Modell für das Datenbankschema automatisiert angepasst und erweitert
  4. zu guter Letzt werden die wenigen verbleibenden Anpassungen für das Datenbankschema manuell vorgenommen

_________________________________________________________________________________________________________

Weitere Informationen

Die Grundlagen der Datenmodellierung sind hier gut beschrieben:
https://de.wikipedia.org/wiki/Datenmodell
https://en.wikipedia.org/wiki/Data_model
https://de.wikipedia.org/wiki/Semantisches_Datenmodell

Die Verschiebung der Begrifflichkeit der Schichten („Tektonik“) ist z.B. hier nachzulesen
http://www.agiledata.org/essays/dataModeling101.html
http://www.1keydata.com/datawarehousing/data-modeling-levels.html

Arnulf Zitzelsberger

geschrieben von Arnulf Zitzelsberger

Arnulf Zitzelsberger ist als Senior Consultant bei der MID GmbH tätig. Er beschäftigt sich seit über 20 Jahren im Datenbankbereich mit Datenmodellierung, Datenbankkonzeption und Datenarchitektur. Sein Schwerpunkt ist die Entwicklung von großen DWH-Projekten. Aktuell bereät er in einem Kundenprojekt der öffentlichen Verwaltung.

<< Zurück

Relevante Posts:

MID Blog

Hier bloggen Mitarbeiter der MID und eingeladene Gastautoren zu Themen rund um die Modellierung. Bleiben Sie auf dem Laufenden und lassen Sie sich per Email über neue Blogbeiträge informieren.

Neue Beiträge per Mail

Autoren

Interessieren Sie sich für ein Thema, dass wir bisher noch nicht behandelt haben? Oder haben Sie Fragen oder Anmerkungen zu einem bestimmten Beitrag?

Schreiben Sie uns gerne einen Kommentar, wir werden das Thema in der Zukunft aufgreifen.

Die neuesten Posts

MID Newsletter abonnieren