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.
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.
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.
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.
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.
|