Das Datenmodell – die Strukturen eines Anwendungsbereiches eindeutig erfassen
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.
„All models are wrong, but some are useful.“
– George Edward Pelham Box, britischer Statistiker
DataAcademy.in: Conceptual, Logical & Physical Data Models (14min)
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. Als stabiles Artefakt sorgt es unternehmensweit für Datenkonsistenz und beeinflusst das Design Ihrer IT-Systeme.
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. Ein Logisches Datenmodell ist stabil. Als organisationsspezifisches Artefakt sorgt es für IT-Systemübergreifende Datenkonsistenz.
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.
„Sorgen Sie für ein einheitliches Verständnis und flankieren Sie Ihr Datenmodell mit einem Glossar. In diesem definieren Sie in kurzen prägnanten Sätzen die Geschäfts-, Informations- bzw. Datenobjekte sowie ihre Synonyme.“
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.
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).
„Mindestens genauso wichtig wie das resultierende Datenmodell ist der iterative Modellierungsprozess. Sorgen Sie dafür das Schlüsselpersonen von Anfang an in die Konzeptionseinarbeiten eingebunden sind und gemeinsam ein Verständnis entwickeln.“
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ß.
„Ein Bild sagt mehr als 1.000 Worte. Analog beantwortet Ihnen ein Datenmodell auf einen Blick zahlreiche Fragen, die sonst verteilt auf mehrere Seiten Papier zu finden wären.“
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.
Ebenfalls interessant
Two-Speed IT – Unternehmens-IT mit zwei Geschwindigkeiten bereitstellen
Was ist eine Two-Speed IT? Und wie nützt Unternehmen eine IT der zwei Geschwindigkeiten? Alles Wichtige für bimodale IT-Erbringung.
Der Enterprise Architect – alle Aufgaben, Kompetenzen & Verantwortungen eines Unternehmensarchitekten
Welche Aufgaben, Kompetenzen & Verantwortung hat ein Enterprise Architect? Umfassende Rollenbeschreibung für moderne Unternehmensarchitekten.
Schnittstellenbeschreibung – den System-zu-System-Datenaustausch verbindlich definieren
Was enthält eine gute Schnittstellenbeschreibung? Struktur, Elemente und Tipps für die Spezifikation eines System-zu-System-Datenaustausches.
Leseempfehlungen
- Anderson, D.: Data Model Design and Best Practices – Part 1+2, 2017 (letzter Abruf: 10.04.2020)
- DataAcademy.in: Conceptual, Logical & Physical Data Models, 2017, YouTube (letzter Abruf: 10.04.2020)
- Kemper, A., Eickler, A.: Datenbanksysteme: Eine Einführung, De Gruyter Oldenbourg, 2015
- Manhart, K./Computerwoche: Grundlagenserie Business Intelligence: Datenmodellierung – Relationale und Multidimensionale Modelle, 2008 (letzter Abruf: 10.04.2020)
- Schulz, C.: Das Data Migration Canvas: Auf Reisen mit (Big) Data, OBJEKTspektrum (03) 2016
- Stachowiak, H.: Allgemeine Modelltheorie, Springer, 1973
- Wikipedia: Datenmodellierung, Wikimedia Foundation Inc. (letzter Abruf: 10.04.2020)
Sie wollen ein Datenmodell effizient entwickeln und effektiv einsetzen?
Gerne unterstützen wir Sie!
Dr. Christopher Schulz
Business Analyst, Enterprise Architect & Projektmanager
Bitte akzeptieren Sie unsere Datenschutzerklärung.