• Home   /  
  • Archive by category "1"

Physisches Datenmodell Beispiel Essay

Explore Psp, Management, and more!

Online lernen – Management lernen – Management by Techniken und Führung…

Online lernen – Management lernen – Strategisches Management und der Managementprozess Strategisches Management und die 7 Elemente im Managementprozess Das strategische Management und die damit verbundenen Managementprozesse bestehen aus 7 Bestandteilen oder Elementen. Dazu zählen die Umweltanalyse, die Analyse der Unternehmung, die strategischen Optionen, die strategische Wahl, das strategische Programm, die Realisationsphase und die strategische Kontrolle. Hier erfahren Sie ……

Eine differenzierte Kundenbearbeitung wird erreicht, indem an den Differenzierungspunkten segmentspezifische, die Kundenbedürfnisse erfüllende Kundenerfahrungen definiert werden

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)

 

 

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

 

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

 

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

 

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

One thought on “Physisches Datenmodell Beispiel Essay

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *