Vererbung und Polymorphie mit relationalen Datenbanken.

Relationale Datenbanken sind nicht objektorientiert und es gibt keine Vererbung.

In objektorientierten Programmiersprachen (z.B. Java) ist Vererbung üblich, zum Beispiel um über Methoden der Oberklasse Funktionalitäten aller Objekte anzusprechen (die pro Unterklasse unterschiedlich implementiert sein können: Polymorphie).

Es gibt verschiedene Wege, Vererbungshierarchien objektorientierter Modelle auf Datenbanktabellen abzubilden. Diese verschiedenen Methoden können auch gemischt vorkommen.

Eine Tabelle pro Klasse

OO-Modell (z.B. Java-Klassen)

Datenbanktabellen

Artikel

id		int
name		String
preis		double

ARTIKEL

ID		INTEGER
NAME		VARCHAR
PREIS		NUMERIC
DISCRIMINATOR		VARCHAR

Δ
|

↓

Speise

zutaten		String
zubereitzeit		double

Getraenk

volumen		double
hersteller		String

SPEISEN

ZUTATEN		VARCHAR
ZUBEREITZEIT		NUMERIC

GETRAENKE

VOLUMEN		NUMERIC
HERSTELLER		VARCHAR

Sowohl für Interfaces und abstrakte Oberklassen (im Beispiel "Artikel") als auch für die davon abgeleiteten Klassen (im Beispiel "Speise" und "Getraenk") wird jeweils eine Datenbanktabelle angelegt. Die Daten konkreter Objekte werden auf die Tabellen zu den Ober- und Unterklassen verteilt.

Vorteile:

1:1-Abbildung des OO-Modells.
Leicht erweiterbar um weitere Unterklassen.
Polymorphe Abfragen (z.B. Namen/Preise aller Artikel) sind einfach.

Nachteile:

Lese- und Speicherzugriffe betreffen mehrere Tabellen und erfordern Joins. Das kann zu unübersichtlichen Strukturen und SQL-Kommandos sowie zu geringerer Performance führen.
Nicht-polymorphe Abfragen (z.B. Namen/Preise nur der Getraenke) sind umständlich (z.B. Unterscheidung per Diskriminator).

Beispiel für Hibernate-Mapping (per 'joined-subclass'):

<class name="entity.Artikel">
  <id name="id"><generator class="native" /></id>
  <property name="..." />
  <joined-subclass name="entity.Speise" table="SPEISEN">
    <key column="id" />
    <property name="..." />
  </joined-subclass>
  <joined-subclass name="entity.Getraenk" table="GETRAENKE">
    <key column="id" />
    <property name="..." />
  </joined-subclass>
</class>

Eine Tabelle pro konkreter Klasse

OO-Modell (z.B. Java-Klassen)

Datenbanktabellen

Artikel

id		int
name		String
preis		double

Δ
|

Speise

zutaten		String
zubereitzeit		double

Getraenk

volumen		double
hersteller		String

SPEISEN

ID		INTEGER
NAME		VARCHAR
PREIS		NUMERIC
ZUTATEN		VARCHAR
ZUBEREITZEIT		NUMERIC

GETRAENKE

ID		INTEGER
NAME		VARCHAR
PREIS		NUMERIC
VOLUMEN		NUMERIC
HERSTELLER		VARCHAR

Für die abstrakte Oberklasse (im Beispiel "Artikel") wird keine Datenbanktabelle angelegt. Nur für die konkreten Klassen, von denen Objekte erzeugt werden können (im Beispiel "Speise" und "Getraenk"), werden Datenbanktabellen angelegt. Die Daten konkreter Objekte werden nicht auf mehrere Tabellen verteilt.

Vorteile:

Leicht erweiterbar um weitere Unterklassen.
Lese- und Speicherzugriffe betreffen nur einzelne Tabellen und erfordern keine Joins. Die Struktur und die SQL-Kommandos sind einfach und übersichtlich. Die Performance ist gut.
Nicht-polymorphe Abfragen (z.B. Namen/Preise nur der Getraenke) sind einfach.

Nachteile:

Polymorphe Abfragen (z.B. Namen/Preise aller Artikel) sind schwieriger: Die Abfrage muss aufgeteilt werden auf mehrere Tabellen.

Beispiel für Hibernate-Mapping (per 'union-subclass'):

<class name="entity.Artikel">
  <id name="id"><generator class="native" /></id>
  <property name="..." />
  <union-subclass name="entity.Speise" table="SPEISEN">
    <property name="..." />
  </union-subclass>
  <union-subclass name="entity.Getraenk" table="GETRAENKE">
    <property name="..." />
  </union-subclass>
</class>

Eine Tabelle pro Klassenhierarchie

OO-Modell (z.B. Java-Klassen)

Datenbanktabellen

Artikel

id		int
name		String
preis		double

ARTIKEL

ID		INTEGER
NAME		VARCHAR
PREIS		NUMERIC
DISCRIMINATOR		VARCHAR
ZUTATEN		VARCHAR
ZUBEREITZEIT		NUMERIC
VOLUMEN		NUMERIC
HERSTELLER		VARCHAR

Δ
|

Speise

zutaten		String
zubereitzeit		double

Getraenk

volumen		double
hersteller		String

Die Daten aller Klassen einer Klassenhierarchie werden in einer gemeinsamen "breiten" Datenbanktabelle abgebildet. Je nach gespeichertem Objekt bleiben für den jeweiligen Typ nicht benötigte Datenbankspalten leer.

Vorteile:

Lese- und Speicherzugriffe betreffen nur eine einzelne Tabelle und erfordern keine Joins. Solange nur wenige Klassen zusammengeführt werden, sind die Struktur und die SQL-Kommandos einfach und übersichtlich.
Polymorphe Abfragen (z.B. Namen/Preise aller Artikel) sind einfach.

Nachteile:

Werden viele Klassen auf nur eine Datenbanktabelle abgebildet, wird diese unübersichtlich und schwer wartbar.
Fehlende "Normalisierung" kann Speicherplatzverschwendung bedeuten.
Nicht-polymorphe Abfragen (z.B. Namen/Preise nur der Getraenke) sind umständlich (z.B. Unterscheidung per Diskriminator).

Beispiel für Hibernate-Mapping (per 'subclass'):

<class name="entity.Artikel">
  <id name="id"><generator class="native" /></id>
  <property name="..." />
  <discriminator column="discriminator" type="string" length="1" />
  <subclass name="entity.Speise" discriminator-value="S">
    <property name="..." />
  </subclass>
  <subclass name="entity.Getraenk" discriminator-value="G">
    <property name="..." />
  </subclass>
</class>