Richtlinie: Relationale Datenbanken entwickeln
Diese Richtlinie beschreibt Methoden für die Zuordnung persistenter Designklassen im Designmodell zu Tabellen im Datenmodell.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

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:

Klasse Kunde

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:

Abbildung, die einen Teil der neuen Objekttabelle Kunde zeigt

Persistente Attribute und Schlüssel

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 persistenten Objekten zum Datenmodell zuordnen

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:

UML-Diagramm, das die Assoziation zwischen Auftrag und Kunde zeigt

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.

Aggregationsassoziationen dem Datenmodell zuordnen

Aggregation wird ebenfalls mit Fremdschlüsselbeziehungen modelliert.

Beispiel:

Schauen Sie sich die folgende Assoziation zwischen Auftrag und Artikel an:

Klassen Auftrag und Artikel

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.

Generalisierungsbeziehung im Datenmodell modellieren

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.

n:n-Assoziationen im Datenmodell modellieren

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.

Datenmodell entwickeln

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.