Das Datenmodell – die Strukturen eines Anwendungsbereiches eindeutig erfassen

von Business-IT-Alignment

Management Summary

  • Ein Datenmodell beschreibt die aktuellen oder zukünftigen Datenstrukturen eines Anwendungsbereiches. Dieser kann fachlicher und/oder technischer Natur sein.
  • Wissenschaft und Praxis unterscheiden zwischen einem Konzeptionellen, Logischen und Physischen Datenmodell. Der Unterschied der Modelle liegt in ihren Nutzergruppen, den Anwendungsfälle sowie dem Betrachtungselementen. Nur das Physische Datenmodell wird letztlich in ein Softwaresystem überführt.
  • Die Datenmodellierung ist die schrittweise und verfeinernde Entwicklung eines Datenmodells. Sowohl fachliche als auch technische Stakeholder treiben arbeitsteilig den Prozess.

Application Landscape Management

 

In einer IT-Systemlandschaft stecken 2 Mio. Dollar Optimierungspotential.
Wie viel können Sie realisieren?

Bestimmen Sie in weniger als 8 Minuten mit 14 Einzelfragen die Optimierungshebel im Management Ihres Applikationsportfolios.

Was ist ein Datenmodell?

Mit Hilfe eines Datenmodells (auch Datenschema oder Datenbankschema) beschreiben Sie die verarbeitenden Daten, ihre Eigenschaften und Beziehungen eines existierenden oder noch zu erschaffenden Anwendungsbereiches. Der Anwendungsbereich kann dabei

  • fachlicher (z.B. Geschäftsprozess, Organisationseinheit, Business Service) bzw.
  • technischer (z.B. Smartphone App, IT-Plattform, Web-Service) sein.

Zum Einsatz kommt eine Modellierungssprache, als Ergebnis erhalten Sie eine eindeutige grafische Analyse-, Entwicklungs- und Diskussionsrundlage, welche auf die Datenstrukturen des Anwendungsbereiches fokussiert.

Wissend, dass es in einschlägiger Literatur viel präzisere, aber auch viel umfangreichere Beschreibungen für Datenmodell-Basiskonzepte wie Datenbeschreibungssprache, Datenschema, Datenwörterbuch, Datenbankmanagementsystem oder Normalisierung gibt, wollen wir es in diesem Beitrag bei der oberen pragmatische Erklärung belassen. Viel wichtiger als eine Definitionsarie sind aus unserer Sicht ein gemeinsames Verständnis zu den benötigten Datenstrukturinformationen sowie ein Konsens zu den Aufgaben und Nutzen eines zu erstellenden Datenmodells.

Ein Datenmodell kann in der Praxis sehr einfach und klein, aber auch sehr umfassend und feingliedrig ausfallen. Wesentliche Scope- und Detailtreiber sind…

  • Umfang und Kompliziertheit (bzw. gar Komplexität) des Anwendungsbereiches,
  • Menge, Diversität und Wachstumsrate der Daten,
  • bestehende Datenmodelle auf fachlicher und technischer Ebene sowie
  • nutzenden Bereiche und Stakeholder.

Worin liegt der Nutzen eines Datenmodells?

Mit einem Datenmodell konzentrieren Sie sich auf das ‚Was‘ eines Anwendungsbereiches. Der Modelltyp liefert Ihnen eine statisch strukturelle Sicht auf die Daten eines soziotechnisches Systems (Menschen, Abläufe, IT-Systeme), wahlweise im Ist-, Plan- oder Ziel-Zustand.

Nutzen Sie ein Datenmodell als verbindliche Kommunikationsgrundlage zwischen

  • Fach- und IT-Vertretern,
  • Linien- und Projektorganisationen sowie
  • Einzelakteuren, Teams und Bereichen unterschiedlicher Hierarchieebenen.

Das Modell verankert bei den Stakeholdern ein gemeinsames Vokabular und fördert in der Zusammenarbeit ein geteiltes Verständnis. Fachliche und technische Anforderungen können präzise formuliert, Informationen unmissverständlich und schnell ausgetauscht werden, Entscheidungsdiskussionen konsistent und effektiv geführt werden.

Ein weiterer Mehrwert des Modells ist das präzise Scoping. Ein Datenmodell bildet Teile des Anwendungsbereichs ab, lässt dabei Aspekte weg bzw. fasst sie zusammen. Bestimmen Sie mittels Datenmodell, welche Elemente, Merkmale und Verbindungen der realen bzw. virtuellen Welt berücksichtigt werden müssen und welche nicht im Betrachtungsbereich liegen. Verkürzen und Abstrahieren Sie.

Schließlich übernimmt das Datenmodell für Sie eine Validierungsfunktion. Mit ihm betrachten Sie eine fachliche bzw. technische Domäne aus struktureller Sicht. Sowohl aktuelle als auch zukünftige Zustände können geprüft werden. Im Fokus stehen dabei die Daten, nicht die Funktionen, Fähigkeiten, Prozesse oder Verhaltensweisen.

Einheitliche Begriffe

Klarheit in Kommunikation und Entwicklung

Visuelles Scoping

Eindeutigkeit in Umfang und Detailtiefe

Geprüfte Anforderungen

Strukturelle Validierung des Systems

Welche Datenmodelltypen gibt es?

 

Geschäftsobjektmodell? Informationsmodell? Datenbankmodell? Was hätten Sie heute gern?

Schieben wir den Humor zur Seite. Tatsächlich ist der Term ‚Datenmodell‘ ein Überbegriffe für verschiede Modelltypen. Leider verwenden Wissenschaft und Industrie verschiedene Bezeichnungen, wie auch der Wikipedia-Eintrag Stand 04/2020 belegt. Bleiben wir an dieser Stelle erneut mit beiden Beinen in der Praxis und gehen knapp auf die einzelnen Modellvertreter und ihre Nutzergruppen ein.

Konzeptionelles Datenmodell

Mit einem Konzeptionellen Datenmodell (auch fachliches/semantisches Datenmodell, Informationsmodell oder engl. Conceptual/Semantical Data Model) beschreiben Sie die Daten eines Anwendungsbereiches aus fachlicher Perspektive. Im Zentrum steht das Geschäftsobjekt, ein reales oder virtuelles Element aus den Geschäftsprozessen. Geschäftsobjekte besitzen einen eindeutigen Namen (z.B. Fahrzeug, Werk) sowie Eigenschaften (z.B. Farbe, Alter) und Beziehungen zueinander. Das Konzeptionelle Datenmodell ist unabhängig von einer technischen Realisierung.

Nutzen Sie das Entity Relationship (ER) Diagramm oder das Unified Modeling Language (UML) Klassendiagramm für eine Visualisierung. Wichtigste Zielgruppe sind die Fachbereiche.

Logisches Datenmodell

Als Verbindungsglied zwischen Konzeptionellen und Physischen Datenmodell konkretisiert das Logische Datenmodell (engl. Logical Data Model) die Datenstrukturen für ein Softwareherstellerneutrales Datenbankmanagementsystem. Seine Elemente sind die Informationsobjekte samt relevanter Details wie Name, Attribute, Schlüsseleigenschaften (Primär, Fremd), Einschränkungen und Relationen. Mit den Informationsobjekten bilden Sie einzelne Geschäftsobjekte, Teile eines Geschäftsobjektes oder mehrere Geschäftsobjekte ab.

Beschreiben Sie ein Logisches Datenmodell erneut mit Hilfe eines ER Diagramms bzw. UML Klassendiagramms. Erweitern Sie dazu den ersten Diagrammtyp an den Relationen um die Krähenfuß-Notation (auch Martin-Notation). Bei UML ergänzen Sie Schlüsselangaben in Klammern an den Attributen bzw. notieren Einschränkungen als Textboxen direkt im Diagramm. Das Logische Datenmodell stiftet sowohl technisch affinen Fachbereichsvertretern als geschäftsinteressierten IT-Personal einen Nutzen.

Physisches Datenmodell

Last but not least steht beim Physischen Datenmodell (auch Technisches Datenmodell, Datenbankschema oder engl. Physical Data Model) die umsetzungsrelevanten Datenobjekte für ein herstellerspezifisches Datenbankmanagementsystem im Zentrum. Beispielsweise gehören bei den in Unternehmen weit verbreiteten relationalen Datenbank die Tabellen und Spalten (inkl. Namen, Datentypen, Standardwerte, Primär-Fremdschlüsselangaben), Datenbankindizes (inkl. Eigenschaften), Berechtigungen, Auslöser (engl. Trigger), Sichten (engl. Views), gespeicherte Vorgänge (engl. Stored Procedures), Speicherzuweisung auf dem Datenträger sowie Details zu den Verteilungsparametern dazu.

Das physische Datenmodell ist das einzige Modell, welches Sie in lauffähige Software überführen. Es greift die Informationsobjekte des Logischen Modells auf und bildet es auf physische Datenobjekte ab. Nutzen Sie erneut das ER-Diagramm nebst Krähenfußnotion oder ein angepasstes UML Klassendiagramm für die Modellierungsarbeit. Bei einem Relationalen Datenbankmanagementsystem können Sie alternativ direkt auf ein Relationales Datenmodell samt Tabellen und Spalten wechseln. Hauptanwender des resultierenden Modells sind IT-Entwickler sowie der IT-Betrieb.

Konzeptionelles Datenmodell

für Fachexperten, Product Owner und Enterprise Architekten 

Logisches Datenmodell

für Business Analysten, Data Scientists und Enterprise Architekten

Physisches Datenmodell

für IT-Entwickler, Data Engineers und Datenbankadministratoren

Was gilt es bei der Entwicklung von Datenmodellen zu beachten?

Die Aktivität der Entwicklung eines Datenmodells ist die Datenmodellierung. Aus unserer Erfahrung verläuft dieser Vorgang im Optimalfall inkrementell und iterativ, also schrittweise verfeinernd.

Datenmodellierung ist mindestens genauso wichtig wie das resultierende Datenmodell. Ein guter Modellierungsprozess auf Basis von Diagrammen sorgt für…

  • ein einheitliches Begriffsverständnis zum Anwendungsbereich und dessen notwendigen Scope und Detailtiefe unter den Stakeholdern,
  • ein gemeinsames Lernen über die Besonderheiten des Anwendungsbereiches,
  • Klarheit über die Notwendigkeit von neuen bzw. bestehenden Daten sowie
  • das abgestimmte Fällen von Entwurfsentscheidungen auf fachlicher und technischer Ebene.

Gehen Sie dabei Top-Down vor, beginnend mit dem Konzeptuellen Modell. Schaffen Sie Konsens zu den Geschäftsobjekten, modellieren Sie dieses und bringen Sie es zur Abstimmung. Anschließend widmen Sie sich den Logischen Modell, verfeinern, prüfen und geben Sie frei. Schließlich implementieren Sie das Physische Datenmodell in Software und testen. Möglich sind Änderungsrücksprünge zwischen den Modellen. Beispielsweise kann die Prüfung im Logischen Datenmodell zu Änderungen im Konzeptuellen Modell führen.

Versionieren Sie die Datenmodelle. Moderne Modellierungswerkzeuge erlauben neben dem Protokollieren von Modellanpassungen zudem eine Verfolgbarkeit (engl. Tracebility) zwischen Business, Informations- und Datenobjekten.

Achten Sie auf redundanzfreie Datenspeicherung und Datenkonsistenz. Erstere liegt vor, falls jedes Datum in einer Datenbank genau einmal vorkommt. Letztere ist bei korrekten und eindeutigen Daten sichergestellt. Weitere Kriterien finden Sie in der diesem Beitrag beigefügten Datenmodell Checkliste. Fordern Sie diese einfach per E-Mail an. 

Datenmodell

Schrittweise Top-Down Entwicklung von Datenmodellen (in Orange mögliche Rücksprünge)

Welches sind typische Einsatzszenarien für ein Datenmodell?

Datenmodelle haben ein breites Einsatzspektrum. Eine unvollständige Auswahl von Anwendungsfällen aus unseren Business/IT Engagements:

  • Erweiterung eines Fachverzeichnisses/-glossars um Begriffsbeziehungen
  • Inhaltliche Präzisierung und Scoping eines von Homonymen und Synonymen geprägten fachlichen Anwendungsbereichs
  • Definition der Datenanforderungen an ein IT-System im Zuge einer Softwareauswahl
  • (Weiter-)Entwicklung und Betrieb eines IT-Systems
  • Schnittstellenentwicklung zwischen zwei oder mehreren IT-Systemen
  • Migrationen von Datenbeständen von einem Vorgänger auf ein Nachfolgersystem

Dabei reichten die von uns erstellten Datenmodellen von einer einstelligen Zahl von Elementen und Beziehungen bis zu über 70 Entitäten. Wir nutzten sowohl Standard-Tools wie Microsoft PowerPoint und Visio als auch Modellierungswerkzeuge wie NoMagics MagicDraw und Sparx Enterprise Architect (EA).

Worin bestehen die Stärken & Schwächen von Datenmodellen?

Vorteile

  • Das Datenmodell ist eine einfache, aber ausdrucksstarke Darstellung von Daten, ihren Eigenschaften und Beziehungen. Es vereinfacht die Analyse und Kommunikation.
  • Eine erste Diskussionsfassung eines Datenmodells lässt sich in wenigen Minuten am Whiteboard erstellen. Als Tool reicht für den Anfang Microsofts PowerPoint. Auch spezielle Modellierungswerkzeuge sind erschwinglich.
  • Die Schwäche von rein textuellen Glossaren – die Darstellung von Beziehungen zwischen verschiedenen Konzepten – gleicht das visuelle Datenmodell mit seinen exzellent aus.
  • Welche Geschäftsobjekte stehen im Fokus? Wie stehen diese in Beziehung? Welche Eigenschaften zeichnen sie aus? Ein Datenmodell zwingt zur Präzision und Eindeutigkeit. Optisch ist sofort klar, wo noch Lücken klaffen.

Nachteile

  • Nicht jeder Stakeholder kann und will sich auf das Datenmodell einlassen. Wir empfehlen ein sanftes Heranführen. Beginnen Sie mit den Geschäftsobjekten und Beziehungen des konzeptionellen Modells. Sobald das Hilfsmittel vertraut ist, ergänzen Sie die weitere Elemente und Modelltypen.
  • Ein Datenmodell bleibt ein Modell der aktuellen bzw. noch zu erschaffenden Wirklichkeit. Es lässt Inhalte aus, stellt diese nur abstrakt da, bzw. erfüllt eine spezifische Aufgabe.
  • Das Modell visualisiert ausschließlich statisch strukturelle Informationen. Für dynamische Aspekte, wie Prozessabläufe, Wechselwirkungen oder Zustandsübergänge, müssen Sie andere Modelltypen heranziehen.
  • Gerade zu Beginn der Arbeit mit Datenmodell fällt es schwer den richtigen Detaillierungsgrad zu treffen. Oft wird zu viel modelliert, jeder Aspekt aus der realen Welt im Diagramm reflektiert. Agieren Sie hier mit Augenmaß.

Fazit

“Data is stable – functions are not.”. In der Regel haben Datenmodelle eine deutlich längere Nutzungsdauer als Prozess- und Funktionsmodelle. Eine sorgfältige Datenmodellierung entlang der Informationsbedarfe der Stakeholder zahlt sich für Sie mehrfach aus.

Dabei generiert die Erstellung von Datenmodellen nicht nur in Software Engineering Projekten einen Mehrwert. Auch Strategie- und Fachbereichsinitiativen profitieren von dem mit einem Datenmodell einhergehenden einheitlichen Begriffsverständnis und dem visualisierten Scope.

Leseempfehlungen

Sie wollen ein Datenmodell effizient entwickeln und effektiv einsetzen?
Gerne unterstützen wir Sie!

Dr. Christopher Schulz

Dr. Christopher Schulz

Managing Partner

Dr. Christopher Schulz berät seit 2007 Kunden in der Automobil- und Bankenbranche an der Schnittstelle zwischen Business und IT.

Er studierte Informatik am KIT in Karlsruhe und an der INSA de Lyon. Seine Consulting Schwerpunkte liegen im Enterprise Architecture Management sowie der Business Analyse.

Neben Kundenprojekten gibt Christopher seine Expertise mittels Fachartikeln, Vorträgen und Trainings weiter. Christopher bloggt leidenschaftlich gerne. Er ist verheiratet und hat zwei Kinder.

Bitte akzeptieren Sie unsere Datenschutzerklärung.

11 + 4 =