Vererbung in Datenbanken: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 3: | Zeile 3: | ||
Es gibt verschiedene Möglichkeiten wie man Vererbungen, sogenannte IS-A-Beziehungen, in Datenbanken realisieren kann. Die unterschiedlichen Implementierungsmöglichkeiten bringen jeweils Vor- und Nachteile, insbesondere beim Zugriff auf die jeweiligen Tabellen, mit sich. | Es gibt verschiedene Möglichkeiten wie man Vererbungen, sogenannte IS-A-Beziehungen, in Datenbanken realisieren kann. Die unterschiedlichen Implementierungsmöglichkeiten bringen jeweils Vor- und Nachteile, insbesondere beim Zugriff auf die jeweiligen Tabellen, mit sich. | ||
=Manuelle Definition= | ==Manuelle Definition== | ||
Voraussetzung: <code>f isa e</code>, <code>f</code> erbt alle Attribute von <code>e</code> und kann weitere Attribute besitzen. | Voraussetzung: <code>f isa e</code>, <code>f</code> erbt alle Attribute von <code>e</code> und kann weitere Attribute besitzen. | ||
==Implementierungsvarianten Relationenschema== | ===Implementierungsvarianten Relationenschema=== | ||
'''1. Möglichkeit''' | '''1. Möglichkeit''' | ||
Zeile 13: | Zeile 13: | ||
Hierbei wird jedes Objekt in einer seperaten Tabelle gespeichert. | Hierbei wird jedes Objekt in einer seperaten Tabelle gespeichert. | ||
'''2. Möglichkeit''' | '''2. Möglichkeit''' | ||
Zeile 22: | Zeile 20: | ||
Hierbei ist die Auflistung aller Objekte der Tabelle e einfacher, für alle Objekte und f und deren zugehörigen von e geerbten Attribute ist ein einfacher Join möglich. Die zweite Variante ist die sauberste aller Implementierungsmöglichkeiten und wird empfohlen. | Hierbei ist die Auflistung aller Objekte der Tabelle e einfacher, für alle Objekte und f und deren zugehörigen von e geerbten Attribute ist ein einfacher Join möglich. Die zweite Variante ist die sauberste aller Implementierungsmöglichkeiten und wird empfohlen. | ||
'''3. Möglichkeit''' | |||
3. Möglichkeit | |||
e: id, e1, e2, f1*, f2* | e: id, e1, e2, f1*, f2* | ||
Es ist theoretisch möglich für die gesamte Vererbungs-Hierachie nur eine einzige Tabelle zu definieren. Diese enthält dann alle Attribute der Basisklasse sowie aller Subklassen. Die Attribute der Subklassen dürfen NULL werden. | Es ist theoretisch möglich, für die gesamte Vererbungs-Hierachie nur eine einzige Tabelle zu definieren. Diese enthält dann alle Attribute der Basisklasse sowie aller Subklassen. Die Attribute der Subklassen dürfen NULL werden. | ||
Der große Nachteil dieser Variante: Es können Inkonsistenzen auftreten. Attribute wie f1 und f2, welche bei einem Objekt der Klasse f nicht undefiniert sein dürften; können nun den WERT NULL annehmen. Denkbar wäre z.B. dass f1 mit einem richtigen Wert initialisiert wird, während f2 leer bleibt. | Der große Nachteil dieser Variante: Es können Inkonsistenzen auftreten. Attribute wie f1 und f2, welche bei einem Objekt der Klasse f nicht undefiniert sein dürften; können nun den WERT NULL annehmen. Denkbar wäre z.B. dass f1 mit einem richtigen Wert initialisiert wird, während f2 leer bleibt. | ||
==Zugriff== | ===Zugriff===0 | ||
'''1. Möglichkeit''' | '''1. Möglichkeit''' | ||
Zeile 42: | Zeile 38: | ||
Alle Informationen über f-Objekte: | Alle Informationen über f-Objekte: | ||
SELECT id, e1, e2, f1, f2 FROM f | SELECT id, e1, e2, f1, f2 FROM f | ||
'''2. Möglichkeit''' | '''2. Möglichkeit''' | ||
Zeile 54: | Zeile 48: | ||
WHERE e.id = f.id | WHERE e.id = f.id | ||
==Direkte Vererbung in SQL== | |||
=Direkte Vererbung in SQL= | |||
Seit SQL:1999 wird einfache Attributvererbung auch direkt unterstützt. Man muss sich nicht mehr darum kümmern welche Attribute in welche Tabelle gehören. Auch ist der Zugriff ohne zusätzliche JOIN- oder UNION-Operationen möglich. | Seit SQL:1999 wird einfache Attributvererbung auch direkt unterstützt. Man muss sich nicht mehr darum kümmern welche Attribute in welche Tabelle gehören. Auch ist der Zugriff ohne zusätzliche JOIN- oder UNION-Operationen möglich. | ||
Zeile 61: | Zeile 54: | ||
Jedoch unterstützen einige Datenbank-Management-Systeme Vererbung gar nicht oder nicht standard-konform. Im Folgenden wird deshalb der SQL-Standard sowie PostgreSQL behandelt. | Jedoch unterstützen einige Datenbank-Management-Systeme Vererbung gar nicht oder nicht standard-konform. Im Folgenden wird deshalb der SQL-Standard sowie PostgreSQL behandelt. | ||
==Erstellung== | ===Erstellung=== | ||
'''SQL-Standard:''' | '''SQL-Standard:''' | ||
Zeile 74: | Zeile 67: | ||
f kann, abgesehen vom Primärschlüssel, weitere Attribute und Integritätsbedingungen definieren. | f kann, abgesehen vom Primärschlüssel, weitere Attribute und Integritätsbedingungen definieren. | ||
==Zugriff== | ===Zugriff=== | ||
SELECT * FROM e | SELECT * FROM e | ||
Zeile 84: | Zeile 77: | ||
Hierbei erhält man ausschließlich die Tupel von e, nicht aber Tupel von Subklassen wie f. | Hierbei erhält man ausschließlich die Tupel von e, nicht aber Tupel von Subklassen wie f. | ||
==Quellen== | |||
=Quellen= | |||
*Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg | *Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg |
Version vom 15. Oktober 2018, 16:50 Uhr
Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.
Es gibt verschiedene Möglichkeiten wie man Vererbungen, sogenannte IS-A-Beziehungen, in Datenbanken realisieren kann. Die unterschiedlichen Implementierungsmöglichkeiten bringen jeweils Vor- und Nachteile, insbesondere beim Zugriff auf die jeweiligen Tabellen, mit sich.
Manuelle Definition
Voraussetzung: f isa e
, f
erbt alle Attribute von e
und kann weitere Attribute besitzen.
Implementierungsvarianten Relationenschema
1. Möglichkeit
e: id, e1, e2 f: id, e1, e2, f1, f2 (id kommt nicht in e vor)
Hierbei wird jedes Objekt in einer seperaten Tabelle gespeichert.
2. Möglichkeit
e: id, e1, e2 f: id, f1, f2 (id -> E: id)
Hierbei ist die Auflistung aller Objekte der Tabelle e einfacher, für alle Objekte und f und deren zugehörigen von e geerbten Attribute ist ein einfacher Join möglich. Die zweite Variante ist die sauberste aller Implementierungsmöglichkeiten und wird empfohlen.
3. Möglichkeit
e: id, e1, e2, f1*, f2*
Es ist theoretisch möglich, für die gesamte Vererbungs-Hierachie nur eine einzige Tabelle zu definieren. Diese enthält dann alle Attribute der Basisklasse sowie aller Subklassen. Die Attribute der Subklassen dürfen NULL werden.
Der große Nachteil dieser Variante: Es können Inkonsistenzen auftreten. Attribute wie f1 und f2, welche bei einem Objekt der Klasse f nicht undefiniert sein dürften; können nun den WERT NULL annehmen. Denkbar wäre z.B. dass f1 mit einem richtigen Wert initialisiert wird, während f2 leer bleibt.
===Zugriff===0
1. Möglichkeit
Alle Objekte der Art e:
SELECT id, e1, e2 FROM e UNION SELECT id, e1, e2 FROM F
Alle Informationen über f-Objekte:
SELECT id, e1, e2, f1, f2 FROM f
2. Möglichkeit
Alle Objekte der Art e:
SELECT id, e1, e2 FROM e
Alle Informationen über f-Objekte:
SELECT id, e1, e2, f1, f2 FROM e, f WHERE e.id = f.id
Direkte Vererbung in SQL
Seit SQL:1999 wird einfache Attributvererbung auch direkt unterstützt. Man muss sich nicht mehr darum kümmern welche Attribute in welche Tabelle gehören. Auch ist der Zugriff ohne zusätzliche JOIN- oder UNION-Operationen möglich.
Jedoch unterstützen einige Datenbank-Management-Systeme Vererbung gar nicht oder nicht standard-konform. Im Folgenden wird deshalb der SQL-Standard sowie PostgreSQL behandelt.
Erstellung
SQL-Standard:
CREATE TABLE e(...); CREATE TABLE f UNDER e(...);
PostgreSQL:
CREATE TABLE e(...); CREATE TABLE f(...) inherits (e)
Hierbei erbt f alle Attribute und Integritätsbedingungen von e, auch den Primärschlüssel. f kann, abgesehen vom Primärschlüssel, weitere Attribute und Integritätsbedingungen definieren.
Zugriff
SELECT * FROM e
Auf diese Art und Weise werden alle Tupel von e einschließlich der Tupel von f(reduziert auf die geerbten Attribute von e) selektiert.
SELECT * FROM ONLY(e)
Hierbei erhält man ausschließlich die Tupel von e, nicht aber Tupel von Subklassen wie f.
Quellen
- Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg]