Richtlinie: Datenmodell
Das Datenmodell erfasst das Design der vom System verwendeten persistenten Datenspeicher. Diese Richtlinie enthält eine Einführung in die Datenmodellierung und ihre Verwendung in RUP.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Übersicht

Datenmodelle werden verwendet, um die Struktur der vom System verwendeten persistenten Datenspeicher zu entwerfen. Das UML-Profil (Unified Modeling Language) für Datenbankdesign stellt Datenbankdesignern eine Reihe von Modellierungselementen zur Verfügung, mit denen das detaillierte Design von Tabellen in der Datenbank entwickelt und das physische Speicherlayout der Datenbank modelliert werden kann. Das UML-Datenbankprofil stellt außerdem Konstrukte für die Modellierung referenzieller Integrität (Bedingungen und Auslöser) sowie gespeicherte Prozeduren für die Verwaltung des Zugriffs auf die Datenbank bereit.

Datenmodelle können auf Unternehmens-, Abteilungs- oder Anwendungsebene erstellt werden. Datenmodelle auf Unternehmens- und Abteilungsebene können eingesetzt werden, um Standarddefinitionen für wichtige Geschäftsentitäten (z. B. Kunde und Mitarbeiter) bereitzustellen, die von allen Anwendungen in einem Geschäft oder einer Geschäftseinheit verwendet werden. Diese Typen von Datenmodellen können auch verwendet werden, um das System im Unternehmen, das "Eigner" der Daten für eine bestimmte Geschäftsentität ist, und die anderen Systeme zu definieren, die Benutzer (Subskribenten) der Daten sind.

Diese Richtlinie beschreibt die Modellelemente des UML-Profils für Datenmodellierung, die zum Erstellen eines Datenmodells für eine relationale Datenbank verwendet werden. Da es zahlreiche Veröffentlichungen zur allgemeinen Datenbanktheorie gibt, wird dieses Thema nicht behandelt. Hintergrundinformationen zu relationalen Datenmodellen und Objektmodellen finden Sie unter Konzept: Relationale Datenbanken und Objektorientierung.

Anmerkung: Die Darstellungen für Datenmodellierung, die in dieser Richtlinie verwendet werden, basieren auf UML 1.3. Zu dem Zeitpunkt, zu dem diese Richtlinie entwickelt wurde, war das Datenmodellierungsprofil von UML 1.4 noch nicht verfügbar.

Stadien der Datenmodellierung

Wie in [NBG01] beschrieben, gibt es drei generelle Stadien in der Entwicklung eines Datenmodells: konzeptionell, logisch und physisch. Diese Stadien der Datenmodellierung spiegeln die unterschiedlichen Detaillierungsgrade im Design des persistenten Datenspeichers und der Abrufmechanismen der Anwendung wider. Eine Erläuterung der konzeptionellen Datenmodellierung finden Sie unter KonzepteKonzeptionelle Datenmodellierung. Zusammenfassungen der logischen und physischen Datenmodellierung finden Sie in den folgenden beiden Abschnitten dieser Richtlinie.

Logische Datenmodellierung

Bei der logischen Datenmodellierung muss der Datenbankdesigner die Schlüsselentitäten und Beziehungen identifizieren, die die kritischen Informationen erfassen, die die Anwendung benötigt, um Daten persistent in der Datenbank zu speichern. Bei der der Anwendungsfallanalyse, beim Anwendungsfalldesign und beim Klassendesign müssen der Datenbankdesigner und der Designer zusammenarbeiten, um sicherzustellen, dass die entwickelten Designs der Analyse- und Designklassen für die Anwendung die Entwicklung der Datenbank adäquat unterstützen. Beim Klassendesign müssen der Datenbankdesigner und der Designer die Klassen im Designmodell identifizieren, die erforderlich sind, um Daten persistent in der Datenbank zu speichern.

Aus diesen persistenten Klassen im Designmodell ergibt sich eine Designmodellsicht, die, obwohl sie sich vom traditionellen logischen Datenmodell unterscheidet, zu einem großen Teil dieselben Anforderungen erfüllt. Die im Designmodell verwendeten persistenten Klassen funktionieren genauso wie die traditionellen Entitäten im logischen Datenmodell. Diese Designklassen spiegeln die persistent zu speichernden Daten, einschließlich aller persistent zu speichernden Datenspalten (Attribute) und Schlüsselbeziehungen exakt wider. Damit sind diese Designklassen ein ausgezeichneter Ausgangspunkt für das physische Datenbankdesign.

Die Erstellung eines separaten logischen Datenmodells ist optional. Im besten Fall werden dieselben Informationen in unterschiedlicher Form erfasst. Im schlimmsten Fall erfasst das logische Datenmodell nicht dieselben Informationen und würde damit nicht die geschäftlichen Anforderungen der Anwendung erfüllen. Wenn die Datenbank für eine einzelne Anwendung bestimmt ist, kann die Datensicht der Anwendung der beste Ausgangspunkt sein. Der Datenbankdesigner erstellt aus den persistenten Datenklassen Tabellen, um ein erstes physisches Datenmodell zu formen.

Es können jedoch Situationen auftreten, in denen der Datenbankdesigner ein idealisiertes Design der Datenbank erstellen muss, das vom Anwendungsdesign unabhängig ist. In diesem Fall wird das logische Datenbankdesign in einem separaten logischen Datenmodell dargestellt, das Teil des gesamten Datenmodells ist. Dieses logische Datenmodell zeigt die wichtigsten logischen Entitäten und ihre Beziehungen, die erforderlich sind, um die Systemanforderungen bezüglich einer konsistenten persistenten Datenspeicherung für die gesamte Architektur der Anwendung zu erfüllen. Das logische Datenmodell kann mit den Modellierungselementen des UML-Profils für Datenbankdesign erstellt werden, die später in dieser Richtlinie noch beschrieben werden. Für Projekte, die diesen Ansatz wählen, ist eine enge Zusammenarbeit von Anwendungsdesignern und Datenbankdesignern für eine erfolgreiche Entwicklung des Datenbankdesigns unerlässlich.

Das logische Datenmodell kann durch Anwenden der Standardregeln für Normalisierung, die unter Normalisierung beschrieben sind, präzisiert werden, bevor die Elemente des logischen Datenmodells für das physische Design der Datenbank entwickelt werden.

Die folgende Abbildung veranschaulicht den primären Ansatz, bei dem zum Erstellen eines ersten physischen Datenmodells Designmodellklassen als Informationsquelle zum logischen Datenbankdesign verwendet werden. Sie zeigt außerdem den alternativen Ansatz mit der Verwendung eines separaten logischen Datenmodells.   

Im Begleittext beschriebene Abbildung

Ansätze für die logische Datenmodellierung

Physische Datenmodellierung

Die physische Datenmodellierung ist das letzte Entwicklungsstadium im Design der Datenbank. Das physische Datenmodell setzt sich aus den detaillierten Designs der Datenbanktabellen und ihren Beziehungen zusammen, die aus den persistenten Designklassen und ihren Beziehungen erstellt wurden. Das Verfahren für die Umwandlung der Designmodellklassen in Tabellen ist in Richtlinie: Relationale Datenbanken entwickeln beschrieben. Das physische Datenmodell ist Teil des Datenmodells und kein separates Artefakt.

Die Tabellen im physischen Datenmodell haben klar strukturierte Spalten und bei Bedarf Schlüssel und Indizes. Für die Tabellen können bei Bedarf Auslöser definiert werden, um die Datenbankfunktionalität und die referenzielle Integrität des Systems zu unterstützen. Zusätzlich zu den Tabellen wurden gespeicherte Prozeduren erstellt, dokumentiert und der Datenbank zugeordnet, in denen die gespeicherten Prozeduren angewendet werden.

Die folgende Abbildung zeigt Beispiele für einige Elemente des physischen Datenmodells. Dieses Beispielmodell ist ein Teil des physischen Datenmodells einer fiktiven Onlineauktionsanwendung. Es zeigt vier Tabellen (Auction, Bid, Item und AuctionCategory) zusammen mit einer gespeicherten Prozedur (sp_Auction) und ihrer Containerklasse (AuctionManagement). Die Abbildung zeigt auch die Spalten der einzelnen Tabelle, die Integritätsbedingungen über Primär- und Fremdschlüssel sowie die Indizes, die für die Tabellen definiert sind.  

Im Begleittext beschriebene Abbildung

Beispiel für (physische) Datenmodellelemente

Das physische Datenmodell enthält außerdem Zuordnungen der Tabellen zu physischen Speichereinheiten (Tabellenbereiche) in der Datenbank. Die folgende Abbildung zeigt ein Beispiel für diese Zuordnung. In diesem Beispiel sind die Tabellen Auction und OrderStatus einem Tabellenbereich mit dem Namen PRIMARY zugeordnet. Die Abbildung veranschaulicht auch, wie die Realisierung der Tabellen in der Datenbank (PearlCircle in diesem Beispiel) modelliert wird.

Im Begleittext beschriebene Abbildung

Beispiel für Modellelemente für Datenspeicher

In Projekten, in denen bereits eine Datenbank vorhanden ist, kann der Datenbankdesigner die vorhandene Datenbank rückentwickeln, um das physische Datenmodell zu füllen. Weitere Informationen hierzu finden Sie in Richtlinie: Relationale Datenbanken rückentwickeln.

Datenmodellelemente

Dieser Abschnitt beschreibt die allgemeinen Modellierungsrichtlinien für die wichtigsten Elemente des Datenmodells basierend auf dem UML-Profil für Datenbankmodellierung. Der Kurzbeschreibung jedes Modellelements folgt eine Beispielabbildung des UML-Modellelements. Der Abschnitt Beziehungen dieser Richtlinie enthält eine Beschreibung zur Verwendung der Modellelemente.

Paket

Standard-UML-Pakete werden verwendet, um Elemente des Datenmodells zu gruppieren und zu organisieren. Pakete können beispielsweise definiert werden, um das Datenmodell in gesonderte logische und physische Datenmodelle zu unterteilen. Pakete können auch verwendet werden, um logische zusammengehörende Gruppen von Tabellen im Datenmodell zu gruppieren, die die wichtigsten "Themenbereiche" für den Geschäftsbereich der entwickelten Anwendung bilden. Die folgende Abbildung zeigt ein Beispiel der beiden Pakete für die Themenbereiche Auction Management und UserAccount Management, die für die Organisation der Sichten und Tabellen im Datenmodell verwendet werden.

Im Begleittext beschriebenes Diagramm

Beispiel für Pakete zu Themenbereichen

Tabelle

Im UML-Profil für Datenmodellierung wird eine Tabelle als Klasse mit dem Stereotyp <<Tabelle>> (Table) modelliert. Die Spalten in der Tabelle werden als Attribute mit dem Stereotyp <<Spalte>> (Column) modelliert. Eine oder mehrere Spalten können als Primärschlüssel für die Gewährleistung eindeutiger Zeileneinträge in der Tabelle bestimmt werden. Spalten können auch als Fremdschlüssel bestimmt werden. Primärschlüsseln und Fremdschlüsseln sind Bedingungen zugeordnet, die als stereotype Operationen <<Primärschlüssel>> (Primary Key) bzw. <<Fremdschlüssel>> (Foreign Key) modelliert werden. Die folgende Abbildung zeigt die Struktur einer Beispieltabelle, die für die Verwaltung von Informationen über Artikel verwendet wird, die in einer Auktion in einem fiktiven Onlineauktionssystem verkauft werden.  

Im Begleittext beschriebene Abbildung

Tabellenbeispiel

Tabellen können mit Hilfe der folgenden Typen von Beziehungen mit anderen Tabellen verknüpft werden:

  • identifizierend (Kompositionsaggregation)
  • nicht identifizierend (Assoziation)

Der Abschnitt Beziehungen dieser Richtlinie enthält Beispiele für die Verwendung dieser Beziehungen. Informationen dazu, wie diese Typen von Beziehungen den Elementen im Designmodell zugeordnet werden, finden Sie in Richtlinie: Relationale Datenbanken rückentwickeln.

Auslöser

Ein Auslöser ist eine prozedurorientierte Funktion, die als Ergebnis einer Aktion für die Tabelle ausgeführt wird, in der sich der Auslöser befindet. Ein Auslöser wird ausgeführt, wenn eine Zeile in der Tabelle eingefügt, aktualisiert oder gelöscht wird. Ein weiterer Auslöser wird vor oder nach der Ausführung des Tabellenbefehls ausgeführt. Auslöser werden als Operationen in einer Tabelle definiert. Die Operationen haben den Stereotyp <<Auslöser>> (Trigger). 

Im Begleittext beschriebene Abbildung

Beispiel für Auslöser

Index

Indizes sind ein Mechanismus, um einen schnelleren Zugriff auf Daten zu ermöglichen, wenn bestimmte Spalten zum Durchsuchen der Tabelle verwendet werden. Ein Index wird als Operation in der Tabelle mit dem Stereotyp <<Index>> modelliert. Indizes können als eindeutige Indizes oder als Cluster- bzw. Nicht-Cluster-Indizes definiert werden. Cluster-Indizes werden verwendet, um die Reihenfolge der Datenzeilen in der Tabelle an die Reihenfolge der Indexwerte anzugleichen. Ein Beispiel für eine Indexoperation (IX_auctioncategory) wird in der folgenden Abbildung gezeigt.

Im Begleittext beschriebene Abbildung

Beispiel für Index

Sicht

Eine Sicht ist eine virtuelle Tabelle ohne unabhängigen persistenten Speicher. Eine Sicht hat die Merkmale und das Verhalten einer Tabelle und greift auf die Daten in den Spalten der Tabellen zu, zu denen die Sicht definierte Beziehungen hat. Sichten werden für einen effizienteren Zugriff auf Informationen in einer oder mehreren Tabellen verwendet und können auch eingesetzt werden, um Geschäftsregeln für einen eingeschränkten Zugriff auf Daten in den Tabellen umzusetzen. Im folgenden Beispiel ist AuctionView als Sicht für Informationen in der Tabelle Auction definiert, die im Abschnitt über die physische Datenmodellierung in dieser Richtlinie vorgestellt wurde.

Sichten werden als Klassen mit dem Stereotyp <<Sicht>> (View) modelliert. Die Attribute der Sichtklassen sind die Spalten aus den von der Sicht referenzierten Tabellen. Die Datentypen der Spalten in der Sicht werden von den Tabellen mit einer definierten Abhängigkeit von der Sicht übernommen.

 Im Begleittext beschriebene Abbildung

Beispiel für Sicht

Domäne

Eine Domäne ist ein Mechanismus, mit dem benutzerdefinierte Datentypen erstellt und auf Spalten in mehreren Tabellen angewendet werden können. Eine Domäne wird als Klasse mit dem Stereotyp <<Domäne>> (Domain) modelliert. Im folgenden Beispiel wurde eine Domäne für eine Postleitzahl "Zip_Plus_4" definiert.  

Im Begleittext beschriebene Abbildung

Beispiel für Domäne

Container für gespeicherte Prozeduren

Ein Container für gespeicherte Prozeduren ist eine Gruppierung gespeicherter Prozeduren im Datenmodell. Ein Container für gespeicherte Prozeduren wird als UML-Klasse mit dem Stereotyp <<SP-Container>> (SP Container, Container für gespeicherte Prozeduren) modelliert. Es können mehrere Container für gespeicherte Prozeduren in einem Datenbankdesign erstellt werden. Jeder Container für gespeicherte Prozeduren muss mindestens eine gespeicherte Prozedur haben.

Gespeicherte Prozedur

Eine gespeicherte Prozedur ist eine unabhängige Prozedur, die sich normalerweise auf einem Datenbankserver befindet. Gespeicherte Prozeduren werden als Operationen dokumentiert, die in Klassen mit dem Stereotyp <<SP-Container>> (SP Container) gruppiert werden. Die Operationen haben den Stereotyp <<SP>>. Das folgende Beispiel zeigt eine gespeicherte Prozedur (SP_Auction) in einer Containerklasse mit dem Namen AuctionManagement. Beim Entwerfen gespeicherter Prozeduren muss der Datenbankdesigner die Namenskonventionen für das jeweilige RDBMS berücksichtigen.

Im Begleittext beschriebene Abbildung

Beispiel für Container für gespeicherte Prozeduren und gespeicherte Prozedur

Tabellenbereich

Ein Tabellenbereich entspricht dem Speicherplatz, der für Elemente wie Tabellen, gespeicherte Prozeduren und Indizes reserviert werden muss. Tabellenbereiche sind über eine Abhängigkeitsbeziehung mit einer bestimmten Datenbank verknüpft. Wie viele Tabellenbereiche benötigt und wie die einzelnen Tabellen diesen Tabellenbereichen zugeordnet werden, richtet sich nach der Komplexität des Datenmodells. Tabellen, auf die häufig zugegriffen wird, müssen möglicherweise auf mehrere Tabellenbereiche verteilt werden. Tabellen, die keine großen Mengen von Daten enthalten, auf die häufig zugegriffen wird, können einem einzelnen Tabellenbereich zugeordnet werden.

Für jeden Tabellenbereich wird ein Tabellenbereichscontainer definiert. Der Tabellenbereichscontainer ist die physische Speichereinheit für den Tabellenbereich. Obwohl mehrere Tabellenbereichscontainer für einen einzigen Tabellenbereich existieren können, wird empfohlen, einen Tabellenbereichscontainer immer nur einem einzigen Tabellenbereich zuzuordnen. Tabellenbereichscontainer werden als Attribute des Tabellenbereichs definiert und nicht explizit modelliert.

Im Begleittext beschriebene Abbildung

Beispiel für Tabellenbereich

Schema Seitenanfang

Ein Schema dokumentiert die Organisation oder Struktur der Datenbank. Ein Schema wird als Paket mit dem Stereotyp <<Schema>> dargestellt. Wenn ein Schema als Paket definiert wird, müssen die Tabellen für dieses Paket in diesem Schema enthalten sein. Es wird eine Abhängigkeit zwischen der Datenbank und dem Schema erstellt, um die Beziehung zwischen der Datenbank und dem Schema zu dokumentieren.  

Im Begleittext beschriebene Abbildung

Beispiel für Schema

Datenbank Seitenanfang

Eine Datenbank ist eine Sammlung von Daten, die so strukturiert ist, dass die in ihr enthaltenen Informationen aufgerufen und verwaltet werden können.   Für das Management der Datenbank und den Zugriff auf die Informationen in der Datenbank wird ein kommerzielles Datenbankmanagementsystem (DBMS) verwendet. Eine Datenbank wird im Datenmodell als Komponente mit dem Stereotyp <<Datenbank>> (Database) dargestellt.

Im Begleittext beschriebene Abbildung

Beispiel Datenbank

Beziehungen Seitenanfang

Das UML-Profil für Datenbankmodellierung definiert die gültigen Beziehungen zwischen den Hauptelementen des Datenmodells. Die folgenden Abschnitte enthalten Beispiele für die unterschiedlichen Beziehungstypen.  

Nicht identifizierende Beziehung

Eine nicht identifizierende Beziehung ist eine Beziehung zwischen zwei Tabellen, die unabhängig voneinander in der Datenbank existieren. Eine nicht identifizierende Beziehung wird mit einer Assoziation zwischen den Tabellen dokumentiert. Die Assoziation hat den Stereotyp <<Nicht identifizierend>> (Non-Identifying). Das folgende Beispiel zeigt eine nicht identifizierende Beziehung zwischen der Tabelle Item und der Tabelle AuctionCategory.

Im Begleittext beschriebene Abbildung

Beispiel für nicht identifizierende Beziehung

Identifizierende Beziehung

Eine identifizierende Beziehung ist eine Beziehung zwischen zwei Tabellen, in der die untergeordnete Tabelle zusammen mit der übergeordneten Tabelle auftreten muss. Eine identifizierende Beziehung wird mit einer Kompositionsaggregation zwischen zwei Tabellen dokumentiert. Die Kompositionsaggregation hat den Stereotyp <<Identifzierend>> (Identifying). Die folgende Abbildung zeigt ein Beispiel für eine identifizierende Beziehung. Das Beispiel zeigt, dass Instanzen der untergeordneten Tabelle (CreditCard) einen zugeordneten Eintrag in der übergeordneten Tabelle (UserAccount) haben müssen.

Im Begleittext beschriebene Abbildung

Beispiel für identifizierende Beziehung

Sowohl für die Assoziation als auch für die Kompositionsaggregation muss eine Multiplizität definiert werden, um die Anzahl der Zeilen in der Beziehung zu dokumentieren. In dem vorherigen Beispiel kann es für jede Zeile in der Tabelle UserAccount 0 oder mehr CreditCard-Zeilen in der Tabelle CreditCard geben. Für jede Zeile in der Tabelle CreditCard gibt es genau eine Zeile in der Tabelle UserAccount. Multiplizität wird auch als Kardinalität bezeichnet.

Datenbanksichten

Wenn Sie eine Beziehung zwischen einer Datenbanksicht zu einer Tabelle definieren, wird eine Abhängigkeitsbeziehung verwendet, die von der Sicht zur Tabelle gezeichnet wird. Der Stereotyp der Abhängigkeit ist <<Ableiten>> (Derive). In der Regel wird die Sichtabhängigkeit benannt, und der Name der Abhängigkeit entspricht dem Namen der Tabelle, die in der Abhängigkeitsbeziehung mit der Datenbanksicht definiert ist.

Im Begleittext beschriebene Abbildung

Beispiel für Abhängigkeitsbeziehung zwischen Sicht und Tabelle

Tabellenbereich

Eine Abhängigkeitsbeziehung wird verwendet, um einen Tabellenbereich mit einer bestimmten Datenbank zu verknüpfen. Wie in der folgenden Abbildung gezeigt, wird die Beziehung so gezeichnet, dass erkennbar ist, dass die Datenbank vom Tabellenbereich abhängig ist. Es können mehrere Tabellenbereiche mit einer einzelnen Datenbank im Modell verknüpft werden.

Im Begleittext beschriebene Abbildung

Beispiel für eine Abhängigkeitsbeziehung zwischen einem Tabellenbereich und einer Datenbank

Eine Abhängigkeitsbeziehung wird verwendet, um die Beziehungen zwischen Tabellenbereichen und den Tabellen in einem Tabellenbereich zu dokumentieren. Es ist möglich, eine oder mehrere Tabellen mit einem Tabellenbereich oder eine Tabelle mit mehreren Tabellenbereichen zu verknüpfen. Das folgende Beispiel zeigt, dass die Tabelle Auction nur dem Tabellenbereich PRIMARY zugeordnet ist.

Im Begleittext beschriebene Abbildung

Beispiel für eine Abhängigkeitsbeziehung zwischen einer Tabelle und einem Tabellenbereich

Realisierungen

Realisierungen werden verwendet, um die Beziehung zwischen einer Datenbank und den Tabellen in dieser Datenbank einzurichten. Eine Tabelle kann von mehreren Datenbanken im Datenmodell realisiert werden.

Im Begleittext beschriebene Abbildung

Beispiel für eine Realisierungsbeziehung zwischen einer Tabelle und einer Datenbank

Gespeicherte Prozeduren

Eine Abhängigkeitsbeziehung wird verwendet, um die Beziehung zwischen dem Container für gespeicherte Prozeduren und den Tabellen zu dokumentieren, mit denen die gespeicherten Prozeduren im Container arbeiten. Das folgende Beispiel veranschaulicht diesen Typ von Beziehung anhand der gespeicherten Prozedur SP_Auction, die verwendet wird, um auf Daten in der Tabelle Auction zuzugreifen.

Im Begleittext beschriebene Abbildung

Beispiel für eine Abhängigkeitsbeziehung zwischen dem Container für gespeicherte Prozeduren und einer Tabelle

Weiterentwicklung des Datenmodells

Konzeptionsphase

In der Konzeptionsphase können erste Datenmodellierungsaufgaben während der Entwicklung von Prototypen für die Machbarkeitsstudie im Rahmen der Architektursynthese ausgeführt werden. In Projekten, in denen bereits eine Datenbank vorhanden ist, kann der Datenbankdesigner die vorhandene Datenbank rückentwickeln, um ein erstes physisches Datenmodell auf der Basis der Struktur der vorhandenen Datenbank zu erstellen. Weitere Informationen hierzu finden Sie in Richtlinie: Relationale Datenbanken rückentwickeln. Elemente des physischen Datenmodells können bei Bedarf in Designmodellelemente umgewandelt, um Prototypen für die Machbarkeitsstudie zu erstellen.

Ausarbeitungsphase

Die Ausarbeitungsphase hat das Ziel, technische Risiken zu minimieren und eine stabile (Referenz-) Architektur für das System zu erstellen. In größeren Systemen ist eine mangelhafte Leistung, die auf ein schlechtes Datenmodelldesign zurückzuführen ist, ein wichtige Problemstellung für die Architektur. Deshalb sind die Datenmodellierung und die Entwicklung eines Architekturprototyps, mit dem die Leistung der Datenbank bewertet werden kann, die wichtigsten Grundlagen für eine stabile Architektur. Wenn die für die Architektur relevanten Anwendungsfälle in den einzelnen Iterationen ausgearbeitet und analysiert werden, werden die Datenmodellelemente basierend auf der Entwicklung der persistenten Klassendesigns aus den Anwendungsfällen definiert. Mit zunehmender Stabilität der Klassendesigns kann der Datenbankdesigner die Klassendesigns regelmäßig in Tabellen im Datenmodell umwandeln und die entsprechenden Modellelemente für den Datenspeicher definieren.

Am Ende der Ausarbeitungsphase müssen die wichtigsten Datenbankstrukturen (Tabellen, Indizes sowie Primär- und Fremdschlüsselspalten) existieren, um die Durchführung der definierten architektonisch relevanten Szenarios für die Anwendung zu unterstützen. Außerdem müssen für die architekturbezogenen Leistungstests repräsentative Datenmengen in die Datenbank geladen werden. Basierend auf den Ergebnissen der Leistungstests muss das Datenmodell möglicherweise mit Hilfe von Optimierungsverfahren einschließlich Denormalisierung, Optimierung der Attribute und Verteilung des physischen Speichers und Indexierung angepasst werden.

Konstruktionsphase

In der Konstruktionsphase darf keine bedeutende Umstrukturierung des Datenmodells vorgenommen werden. In den Iterationen der Konstruktionsphase können basierend auf dem detaillierten Design der Anwendungsfälle und genehmigten Änderungsanfragen zusätzliche Tabellen und Datenspeicherelemente definiert werden. Der Schwerpunkt des Datenbankdesigns während der Konstruktionsphase liegt auf der kontinuierlichen Überwachung der Datenbankleistung und der unter Umständen erforderlichen Optimierung des Datenbankdesigns durch Denormalisierung, Definieren von Indizes, Erstellen von Datenbanksichten und andere Optimierungsverfahren.

Das physische Datenmodell ist das Designartefakt, das der Datenbankdesigner in der Konstruktionsphase verwaltet. Der Datenbankdesigner kann direkte Aktualisierungen im Modell vornehmen oder ein Tool verwenden, das Aktualisierungen liest, die direkt an der Datenbank vorgenommen wurden.

Übergangsphase

Das Datenmodell wird wie das Designmodell in der Übergangsphase als Reaktion auf genehmigte Änderungsanfragen gepflegt. Der Datenbankdesigner muss das Datenmodell mit der Datenbank synchron halten, während die Anwendung dem endgültigen Abnahmetest unterzogen wird und zur Produktion freigegeben wird.

Hinweise zum Round-Trip-Engineering

Wenn ein Entwicklerteam moderne Tools für visuelle Modellierung verwendet, die Klassen in Tabellen konvertieren können (und umgekehrt) und das Entwickeln (Forward-Engineering) und Rückentwickeln (Reverse-Engineering) von Datenbanken unterstützen, muss das Team Richtlinien für die Verwaltung der Konvertierung und der Engineering-Prozesse aufstellen. Die Richtlinien werden hauptsächlich für große Projekte benötigt, in denen ein Team parallel am Datenbank- und am Anwendungsdesign arbeitet. Das Entwicklerteam muss die Punkte in der Entwicklung der Anwendung (Build/Release-Zyklus) definieren, an denen es sich anbietet, die Klassen/Tabellen-Konvertierung und Entwicklung der Datenbank durchzuführen. Nachdem die erste Datenbank erstellt wurde, muss das Entwicklerteam Richtlinien für die Verwaltung der Synchronisation von Datenmodell und Datenbank für das Team definieren, da Design und Code während des Projekts weiterentwickelt werden.