Konzept: Konzeptionelle Datenmodellierung
Das konzeptionelle Datenmodell beschreibt die wichtigen Entitäten und deren Beziehungen, um die Domänenkonzepte, die den Umfang des von der Systemlösung zu lösenden Problems definieren, mit den Projekt-Stakeholdern zu ermitteln.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Laut Definition in der Veröffentlichung [NBG01] repräsentiert die konzeptionelle Datenmodellierung das Anfangsstadium in der Entwicklung des Designs der persistenten Daten sowie des persistenten Datenspeichers für das System. In vielen Fällen werden die persistenten Daten für das System von einem Managementsystem für relationale Datenbanken (Relational Database Management System, RDBMS) verwaltet. Die Geschäfts- und Systementitäten, die auf konzeptioneller Ebene aus den Geschäftsmodellen und Systemanforderungen entwickelt werden, werden durch die Analyse der Anwendungsfälle, das Anwendungsfalldesign und das Datenbankdesign zu detaillierten Designs für physische Tabellen weiterentwickelt, die schließlich im RDBMS implementiert werden. Beachten Sie, dass das konzeptionelle Datenmodell in diesem Konzeptdokument kein separates Arbeitsergebnis darstellt. Stattdessen ist es eine Kompositionssicht von Daten, die in den vorhandenen Arbeitsergebnissen der Disziplinen Geschäftsmodellierung, Anforderungen und Analyse und Design, die für die Entwicklung des Datenmodells relevant sind, enthalten sind.  

Das Datenmodell wird normalerweise in drei Abschnitten entwickelt:

  • Konzeptionell - Dieser Abschnitt umfasst die Angabe der wesentlichen Geschäfts- und Systementitäten auf hoher Ebene sowie deren Beziehungen, die den Umfang des von der Systemlösung zu lösenden Problems definieren. Diese wesentlichen Geschäfts- und Systementitäten werden mit den Modellierungselementen des UML-Profils für die Geschäftsmodellierung, enthalten im Geschäftsanalysemodell, und mit den Modellelementen der Analyseklassen des Analysemodells definiert.
  • Logisch - Dieser Abschnitt beinhaltet die Verfeinerung der konzeptionellen Geschäfts- und Systementitäten auf hoher Ebene zu detaillierteren logischen Entitäten. Diese logischen Entitäten und deren Beziehungen können optional mit den Modellierungselementen des UML-Profils für Datenbankdesign in einem logischen Datenmodell definiert werden, wie in Richtlinie: Datenmodell beschrieben. Das logische Datenmodell ist Teil des Datenmodells (siehe Arbeitsergebnis: Datenmodell) und kein separates RUP-Arbeitsergebnis.
  • Physisch - Dieser Abschnitt umfasst die Umsetzung der Designs für die logischen Klassen in detaillierte und optimierte Designs für physische Datenbanktabellen. Der physische Abschnitt beinhaltet auch die Zuordnung der Designs für die Datenbanktabellen zu Tabellenbereichen und zur Datenbankkomponente im Design für den Datenbankspeicher.

Die Aufgaben im Kontext des Datenbankdesigns umfassen den gesamten Lebenszyklus der Softwareentwicklung. Die ersten Aufgaben für das Datenbankdesign können in der Konzeptionsphase beginnen. Für Projekte, bei denen die Geschäftsmodellierung eingesetzt wird, um den Geschäftskontext der Anwendung zu beschreiben, kann das Datenbankdesign auf konzeptioneller Ebene beginnen - mit der Angabe der Geschäftsakteure und Geschäftsanwendungsfälle im Geschäftsanwendungsfallmodell sowie der Angabe der Mitarbeiter und Geschäftsentitäten im Geschäftsanalysemodell. Für Projekte, bei denen keine Geschäftsmodellierung eingesetzt wird, kann das Datenbankdesign auf konzeptioneller Ebene beginnen - und zwar mit der Angabe der Systemakteure und Systemanwendungsfälle im Anwendungsfallmodell sowie der Angabe der Analyseklassen im Analysemodell der Anwendungsfallrealisierungen.

Die nachfolgende Abbildung zeigt die Elementgruppe des konzeptionellen Datenmodells, die sich in den Geschäftsmodellen, den Anforderungsmodellen und im Analysemodell befinden.

Diagramm ist im Inhalt beschrieben.

Die folgenden Abschnitte beschreiben die Elemente des Geschäftsmodells, des Anwendungsfallmodells und des Analysemodells, die verwendet werden können, um das erste konzeptionelle Datenmodell für persistente Daten im System zu definieren.

Elemente der konzeptionellen Datenmodellierung

Geschäftsmodelle

Geschäftsanwendungsfallmodell

Das Geschäftsanwendungsfallmodell setzt sich aus Geschäftsakteuren und Geschäftsanwendungsfällen zusammen. Die Geschäftsanwendungsfälle repräsentieren wichtige Geschäftsprozesse, mit denen der Kontext für das zu entwickelnde System definiert wird. Geschäftsakteure sind wichtige externe Entitäten, die über die Geschäftsanwendungsfälle mit dem Geschäft interagieren. Die nachfolgende Abbildung zeigt ein sehr einfaches Beispiel für ein Geschäftsanwendungsfallmodell für eine Auktionsanwendung.



Diagramm ist im Inhalt beschrieben.

Da Entitäten viel Speicherplatz im System beanspruchen können, sind Geschäftsakteure geeignete Entitäten für das konzeptionelle Datenmodell. Im obigen Beispiel sind die Geschäftsakteure "Käufer" und "Verkäufer" geeignete Entitäten, für die die Onlineaktionsanwendung Daten speichern muss.

Geschäftsanalysemodell

Das Geschäftsanalysemodell enthält Klassen, die die Mitarbeiter und Geschäftsentitäten modellieren, die über die Analyse des Workflows im Geschäftsanwendungsfall identifiziert werden. Mit Mitarbeitern sind die Personen gemeint, die die für den Workflow erforderlichen Aktivitäten ausführen. Geschäftsentitäten sind "Sachen", die die Mitarbeiter während des Workflows verwenden oder erstellen. In vielen Fällen stellen die Geschäftsentitäten Datentypen dar, die das System persistent speichern muss.  

Die nachfolgende Abbildung zeigt ein beispielhaftes Ablaufdiagramm, das Mitarbeiter und Geschäftsentitäten in einem Szenario des Geschäftsanwendungsfalls "Onlineauktion bereitstellen", das sich mit der Steuerung einer Auktion befasst, beschreibt.

Diagramm ist im Inhalt beschrieben.

In diesem vereinfachten Beispiel stellt das Objekt "Auktionsmanager" eine Mitarbeiterrolle dar, die wahrscheinlich vom Managementsystem für Onlineauktionen selbst übernommen wird. Die Objekte "Auktion" und "Auktionselement" sind Geschäftsentitäten, die vom Mitarbeiter "Auktionsmanager", der als Agent für die Geschäftsakteure "Käufer" und "Verkäufer" fungiert, verwendet oder erstellt werden. Aus der Perspektive des Datenbankdesigns betrachtet sind die Geschäftsentitäten "Auktion" und "Auktionselement" geeignete Entitäten für das konzeptionelle Datenmodell.  

Anforderungsmodell und Analysemodell

Für Projekte, bei denen keine Geschäftsmodellierung eingesetzt wird, enthalten das Anforderungsmodell (Systemanwendungsfall) und das Analysemodell Modellelemente, die verwendet werden können, um ein erstes konzeptionelles Datenmodell zu entwickeln. Für Projekte, bei denen die Geschäftsmodellierung praktiziert wird, werden die in den Geschäftsanalysemodellen angegebenen Geschäftsentitäten und Beziehungen im Analysemodell als Entitätsklassen verfeinert und im Detail dargestellt.   

Systemanwendungsfallmodell

Das Systemanwendungsfallmodell enthält Systemakteure und Systemanwendungsfälle, die die primären Interaktionen der Benutzer mit dem System definieren. Die Systemanwendungsfälle definieren die funktionalen Voraussetzungen für das System.

Aus der Perspektive der konzeptionellen Datenmodellierung betrachtet, stellen die Systemakteure systemexterne Entitäten dar, für die das System möglicherweise persistente Daten speichern muss. Dies ist wichtig in den Fällen, in denen der Systemakteur ein externes System ist, das Daten an das zu entwickelnde System liefert und/oder von diesem empfängt. Systemakteure können von den Geschäftsakteuren im Geschäftsanwendungsfallmodell und den Mitarbeitern im Geschäftsanalysemodell abgeleitet werden können.  

Die nachfolgende Abbildung beschreibt das Geschäftsanwendungsfallmodell für das Onlineauktionssystem. In diesem Modell werden die Geschäftsakteure "Käufer" und "Verkäufer" jetzt vom generischen Geschäftsakteur "Benutzer" abgeleitet. Ein neuer Systemakteur mit dem Namen "Kreditbüro" wurde hinzugefügt, um der Notwendigkeit, Zahlungen über eine externe Entität abzuwickeln, Rechnung zu tragen. Dieser neue Systemakteur ist eine andere geeignete Entität für das konzeptionelle Datenmodell.



Diagramm ist im Inhalt beschrieben.



Analysemodell

Das Analysemodell enthält die Analyseklassen, die in den Anwendungsfallrealisierungen für die Systemanwendungsfälle definiert sind. Die Typen der Analyseklassen, die aus der Perspektive der konzeptionellen Datenmodellierung besonders interessant sind, sind die Entitätsanalyseklassen. Laut Definition in Richtlinie: Analyseklassen repräsentieren Entitätsanalyseklassen vom System verwaltete Informationen, die persistent gespeichert werden müssen. Die Entitätsanalyseklassen und deren Beziehungen bilden die Basis des ersten Datenmodells für die Anwendung. 

Die konzeptionellen Entitätsanalyseklassen im Analysemodell können in logischen persistenten Designklassen im Designmodell verfeinert und detailliert dargestellt werden. Diese Designklassen sind geeignete Tabellen im Datenmodell. Die Attribute der Klassen sind geeignete Spalten für die Tabellen und fungieren für sie auch als geeignete Schlüssel. Im Abschnitt Richtlinie: Forward-Engineering Relational Databases wird beschrieben, wie Elemente im Designmodell Datenmodellelementen zugeordnet werden können.