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.
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.
Ansätze für die logische 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.
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.
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.
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.
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.
Beispiel für Pakete zu Themenbereichen
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.
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.
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).
Beispiel für Auslöser
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.
Beispiel für Index
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.
Beispiel für Sicht
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.
Beispiel für Domäne
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.
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.
Beispiel für Container für gespeicherte Prozeduren und gespeicherte Prozedur
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.
Beispiel für Tabellenbereich
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.
Beispiel für Schema
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.
Beispiel Datenbank
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.
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.
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.
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.
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.
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.
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.
Beispiel für eine Abhängigkeitsbeziehung zwischen dem Container für gespeicherte Prozeduren und einer Tabelle
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.
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.
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.
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.
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.
|