Einführung
Diese Richtlinie beschreibt Methoden für die Zuordnung persistenter Designklassen im Designmodell zu Tabellen im Datenmodell.
Designmodellelemente in Datenmodellelemente umwandeln
Persistente Klassen aus dem Designmodell können in Tabellen im Datenmodell umgewandelt werden. Die folgende Tabelle
zeigt eine Zusammenfassung der Zuordnung zwischen Designmodellelementen und Datenmodellelementen.
Designmodellelement
|
Entsprechendes Datenmodellelement
|
Klasse
|
Tabelle
|
Attribut
|
Spalte
|
Assoziation
|
Nicht identifizierende Beziehung
|
Assoziationsklasse
|
Assoziationstabelle
|
Kompositionsaggregation
|
Identifizierende Beziehung
|
N:N-Assoziation
|
Assoziationstabelle
|
Multiplizität
|
Kardinalität
|
Qualifizierte Assoziation
|
Assoziationstabelle
|
Generalisierung (Vererbung)
|
Gesonderte Tabelle
|
Persistente Klassen zu
Tabellen zuordnen
Die persistenten Klassen im Designmodell stellen die Informationen dar, die das System speichern muss. Konzeptionell
können diese Klassen einem relationalen Design gleichen. (Die Klassen im Designmodell können beispielsweise als
Entitäten im relationalen Schema dargestellt werden.) Wenn ein Projekt von der Ausarbeitung zur Konstruktion übergeht,
laufen die Ziele des Designmodells und des relationalen Datenmodells jedoch auseinander. Diese Abweichung kommt dadurch
zustande, dass die Zielsetzung der Entwicklung relationaler Datenbanken die Normalisierung von Daten ist, wohingegen
das Designmodell das Ziel verfolgt, zunehmend komplexes Verhalten zu kapseln. Diese beiden voneinander abweichenden
Perspektiven - Daten und Verhalten - führen dazu, dass eine Zuordnung zusammengehöriger Elemente in den beiden Modellen
erfolgen muss.
In einer relationalen Datenbank, die in der dritten Normalform geschrieben wird, ist jede Zeile in den Tabellen (jedes
Tupel) ein Objekt. Eine Spalte in einer Tabelle entspricht einem persistenten Attribut einer Klasse. (Beachten Sie
bitte, dass eine persistente Klasse transiente Attribute haben kann.) Wenn es keine Assoziationen zu anderen Klassen
gibt, ist die Zuordnung der beiden Welten recht einfach. Der Datentyp des Attributs entspricht einem der zulässigen
Datentypen für Spalten.
Beispiel
In dem folgenden Beispiel wird die Klasse Kunde verwendet:
Bei der Modellierung dieser Klasse im RDBMS wird die Klasse in eine Tabelle mit dem Namen Kunde umgewandelt mit den
Spalten Kunden_ID, Name und Adresse.
Eine Instanz dieser Tabelle kann wie folgt visualisiert werden:
Für jedes persistente Attribut müssen gewisse Fragen beantwortet werden, um zusätzliche Informationen zu erhalten, die
dann verwendet werden, um das persistente Objekt entsprechend in einem relationalen Datenmodell zu modellieren.
Beispiel:
-
Kann dieses persistente als Schlüssel oder Teil eines Schlüssels dienen? Beispiel: "Attribut X bezeichnet zusammen
mit Attribut Z eindeutig das Objekt." In der Tabelle Kunde ist die Kunden_ID ein Primärschlüssel.
-
Wie sind die Mindest- und Maximalwerte für das Attribut?
-
` Ist es möglich, dieses Attribut beim Suchen als Schlüssel zu verwenden? Das Attribut kann beispielsweise Teil
eines Filters in einer Select-Anweisung sein, z. B. "Es ist üblich, nach allen Instanzen zu suchen, wenn Y >
1000 ist."
-
Hat das Attribut eine Beschreibung, z. B. "Attribut X gibt die Anzahl der Neuübertragungen pro 100.000 übertragenen
Zeichen an"?
-
Hat das Attribut mögliche numerische Werte und gewünschte Konvertierungen zwischen unterschiedlichen numerischen
Werten?
-
Wer darf das Attribut aktualisieren? Beispiel: "T kann nur von Personen mit der Berechtigungsklasse nn geändert
werden."
-
Wer darf das Attribut lesen? Beispiel: "P kann von Personen mit den Berechtigungsklassen yy und zz gelesen werden"
oder "P ist in den Sichten Vi und Vj enthalten"
-
Liegen genügend Informationen zu Anzahl und Häufigkeit vor? Beispiele: "Es sind bis zu 50.000 Vorkommen von A
vorhanden" oder "Durchschnittlich werden 2000 As pro Tag geändert"
-
Ist das Attribut eindeutig? Beispiel: Eine Führerscheinnummer kann nur einer Person zugewiesen sein.
Assoziationen zwischen zwei persistenten Objekten werden als Fremdschlüssel zu den zugeordneten Objekten realisiert.
Ein Fremdschlüssel ist eine Spalte in einer Tabelle, die den Wert des Primärschlüssels des zugeordneten Objekts
enthält.
Beispiel:
Schauen Sie sich die folgende Assoziation zwischen Auftrag und Kunde an:
Wenn diese Assoziation auf relationale Tabellen abgebildet wird, ist das Ergebnis eine Tabelle Auftrag und eine Tabelle
Kunde. Die Tabelle Auftrag hat Spalten für die aufgelisteten Attribute und eine zusätzliche Spalte mit dem Namen
Kunden_ID, die die Fremdschlüsselreferenzen auf den Primärschlüssel der zugeordneten Zeile in der Tabelle Kunde
enthält. Die Spalte Kunden_ID enthält für einen bestimmten Auftrag die ID des Kunden, dem der Auftrag zugeordnet ist.
Mit Fremdschlüsseln kann das RDBMS zusammengehörige Informationen verknüpfen.
Aggregation wird ebenfalls mit Fremdschlüsselbeziehungen modelliert.
Beispiel:
Schauen Sie sich die folgende Assoziation zwischen Auftrag und Artikel an:
Wenn diese Assoziation auf relationale Tabellen abgebildet wird, ist das Ergebnis eine Tabelle Auftrag und eine Tabelle
Artikel. Die Tabelle Artikel enthält Spalten für die aufgelisteten Attribute und eine zusätzliche Spalte mit dem Namen
Auftrags_ID, die eine Fremdschlüsselreferenz auf die zugeordnete Zeile in der Tabelle Auftrag enthält. Die Spalte
Auftrags_ID enthält für einen bestimmten Artikel die Auftrags-ID des Auftrags, dem der Artikel zugeordnet ist. Mit
Fremdschlüsseln kann das RDBMS Operationen verknüpfen.
Außerdem ist es wichtig, eine Bedingung für kaskadierendes Löschen zu implementieren, die für die referenzielle
Integrität im Datenmodell sorgt. Wenn ein Auftrag gelöscht wird, werden auch alle zugehörigen Artikel gelöscht.
Das relationale Standarddatenmodell bietet keine Unterstützung für die direkte Modellierung der Vererbung. Für die
Modellierung von Vererbung stehen mehrere Strategien zur Verfügung: Diese können wie folgt zusammengefasst werden:
-
Verwenden Sie separate Tabellen für die Darstellung von Superklasse und Unterklasse. Die Tabelle für die
Unterklasse muss eine Fremdschlüsselreferenz auf die Tabelle der Superklasse haben. Zum Instanzieren eines
Unterklassenobjekts müssen die beiden Tabellen verknüpft sein. Dieser Ansatz ist konzeptionell einfach und
vereinfacht Änderungen am Modell, aber aufgrund des zusätzlichen Aufwands häufig der Leistung abträglich.
-
Duplizieren Sie alle geerbten Attribute und Assoziationen als separate Spalten in der Unterklassentabelle. Dieser
Ansatz ist mit der Denormalisierung im relationalen Standarddatenmodell vergleichbar.
Eine Standardtechnik bei der relationalen Modellierung ist die Verwendung einer Assoziationsentität für die Darstellung
von n:n-Assoziationen. Derselbe Ansatz kann hier angewendet werden: Für die Darstellung der Assoziation wird eine
Assoziationstabelle verwendet.
Beispiel:
Wenn Lieferanten viele Produkte liefern können und ein Produkt von vielen Lieferanten geliefert werden kann, liegt die
Lösung in der Erstellung einer Lieferant/Produkt-Tabelle. Diese Tabelle enthält nur die Primärschlüssel der Tabellen
Lieferant und Produkt und dient dazu, die Lieferanten und die zugehörigen Produkte zu verknüpfen. Das Objektmodell hat
kein analoges Konstrukt für diese Tabelle. Sie wird nur dazu verwendet, um die Assoziationen im relationalen
Datenmodell darzustellen.
Datenmodell präzisieren
Nachdem die Designklassen in Tabellen und die entsprechenden Beziehungen im Datenmodell umgewandelt wurden, wird das
Modell bei Bedarf präzisiert, um referenzielle Integrität zu implementieren und den Datenzugriff durch Sichten und
gespeicherte Prozeduren zu optimieren. Weitere Informationen finden Sie unter Richtlinie:
Datenmodell.
Die meisten Designtools für Anwendungen unterstützen die Generierung von DDL-Scripts (Data Definition Language) aus
Datenmodellen und/oder die Generierung der Datenbank aus dem Datenmodell. Die Entwicklung (Forward Engineering) der
Datenbank muss ihm Rahmen der Gesamtanwendungsentwicklung und der Integrationsaufgaben geplant werden. Wann und wie oft
die Datenbank aus dem Datenmodell entwickelt wird, richtet sich nach der spezifischen Projektsituation. In neuen
Anwendungsentwicklungsprojekten, die eine neue Datenbank erstellen, müssen die ersten Forward-Engineering-Aufgaben
während der Implementierung einer stabilen Architekturversion der Anwendung am Ende der Ausarbeitungsphase ausgeführt
werden. In anderen Fällen kann die Entwicklung der Datenbank in den frühen Iterationen der Konstruktionsphase erfolgen.
Die Typen von Modellelementen im Datenmodell, die bei der Entwicklung berücksichtigt werden können, variieren je nach
Designtools und RDBMS, die im Projekt eingesetzt werden. Im Allgemeinen können die wichtigsten strukturellen Elemente
des Datenmodells, einschließlich Tabellen, Sichten, gespeicherten Prozeduren, Auslösern und Indizes durch Forward
Engineering in der Datenbank abgebildet werden.
|