Vererbung in Datenbanken - Versionsgeschichte

Kowa am 16. Mai 2019 um 15:23 Uhr

2019-05-16T15:23:25Z

← Nächstältere Version		Version vom 16. Mai 2019, 15:23 Uhr
Zeile 1:		Zeile 1:
	{{~~In Bearbeitung~~}}		{{Qualität
			\|correctness = 3
			\|extent = 3
			\|numberOfReferences = 2
			\|qualityOfReferences = 2
			\|conformance =2
			}}

	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.

Kowa am 15. Oktober 2018 um 14:51 Uhr

2018-10-15T14:51:00Z

← Nächstältere Version		Version vom 15. Oktober 2018, 14:51 Uhr
Zeile 27:		Zeile 27:
	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===0		===Zugriff===

	'''1. Möglichkeit'''		'''1. Möglichkeit'''

Kowa am 15. Oktober 2018 um 14:50 Uhr

2018-10-15T14:50:44Z

← Nächstältere Version		Version vom 15. Oktober 2018, 14:50 Uhr
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~~(nicht empfohlen)~~
	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

Kowa am 9. Juli 2012 um 16:41 Uhr

2012-07-09T16:41:05Z

← Nächstältere Version		Version vom 9. Juli 2012, 16:41 Uhr
Zeile 89:		Zeile 89:
	*Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg		*Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg

	[[Kategorie:HowTo]]		[[Kategorie:HowTo]]]
	~~[[Kategorie:Informatik~~]]
	[[Kategorie:SQL]]		[[Kategorie:SQL]]
	~~[[Kategorie:Daten-Management]]~~

Kowa: /* Implementierungsvarianten Relationenschema */

2009-07-21T15:26:09Z

Implementierungsvarianten Relationenschema

← Nächstältere Version		Version vom 21. Juli 2009, 15:26 Uhr
Zeile 4:		Zeile 4:

	=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.

	==Implementierungsvarianten Relationenschema==		==Implementierungsvarianten Relationenschema==

Kowa: /* Implementierungsvarianten Relationenschema */

2009-07-21T15:24:39Z

Implementierungsvarianten Relationenschema

← Nächstältere Version		Version vom 21. Juli 2009, 15:24 Uhr
Zeile 8:		Zeile 8:
	'''1. Möglichkeit'''		'''1. Möglichkeit'''
	e: id, e1, e2		e: id, e1, e2
	f: id, e1, e2, f1, f2 (id ~~-> E: id~~)		f: id, e1, e2, f1, f2 (id kommt '''nicht''' in e vor)

	[.~~..]~~		Hierbei wird jedes Objekt in einer seperaten Tabelle gespeichert.

Jakobw am 17. Juli 2009 um 07:06 Uhr

2009-07-17T07:06:01Z

← Nächstältere Version		Version vom 17. Juli 2009, 07:06 Uhr
Zeile 11:		Zeile 11:

	[...]		[...]



Zeile 18:		Zeile 19:

	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(nicht empfohlen)		3. Möglichkeit(nicht empfohlen)
Zeile 27:		Zeile 30:

	==Zugriff==		==Zugriff==

	'''1. Möglichkeit'''		'''1. Möglichkeit'''

Zeile 36:		Zeile 40:
	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 49:		Zeile 55:
	=Direkte Vererbung in SQL=		=Direkte Vererbung in SQL=

	=~~Quellen~~=		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.
	~~Wenn die Definitionen~~ und~~/oder die Anmerkungen nicht~~ von ~~einem selbst stammen~~, ~~sollte man die Quellen angeben~~
	~~(das sind natürlich nur Beispiele~~, ~~keine echten Quellen dieses Artikels :-) ):~~		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==

	*~~Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931~~		SELECT * FROM e

	~~Besser ist es spezielle Quellendokumente zu erstellen~~ (~~und diese dann auch mit Inhalt zu füllen~~):		Auf diese Art und Weise werden alle Tupel von e einschließlich der Tupel von f(reduziert auf die geerbten Attribute von e) selektiert.

	*~~[[Kowarschick, W. et al.~~ (~~2005~~)~~: Musterquelle (Buch)]]~~		SELECT * FROM ONLY(e)
	*[[Goldratt, E.; Cox , J. (2004): The Goal]]
	*[[Leach, L. (2005): Critical Chain Project Management]]

	~~Auch externe Quellen können zitiert werden~~.		Hierbei erhält man ausschließlich die Tupel von e, nicht aber Tupel von Subklassen wie f.

	*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke] (besser als eigenes Quellen-Dokument, basierend auf der [[Vorlage:Quelle:URL]])
	*[http://de.wikipedia.org/ Wikipedia] ('''so nicht''', da zu allgemein und außerdem nicht der Wikipedia-Verweis benutzt wurde)
	*[[Wikipedia:Vorlage (Datenverarbeitung)]] (sondern eher so, aber noch besser auch als eigenes Quellen-Dokument)

	=~~Siehe auch~~=		=Quellen=
	~~Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.~~
	~~Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel~~
	~~in [[GlossaryWiki:Main Page\|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.~~

	*~~[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen~~-~~Dokument)~~		*Kowarschick, "Multimedia-Datenbanksysteme", Sommersemester 2009, Hochschule Augsburg
	*[[Wikipedia:Wikipedia:Formatvorlagen\|Wikipedia: Formatvorlagen]]

	[[Kategorie:~~Glossar~~]]		[[Kategorie:HowTo]]
	[[Kategorie:~~GlossarWiki~~]]		[[Kategorie:Informatik]]
	[[en:~~GlossaryWiki~~:~~Sample Page~~]]		[[Kategorie:SQL]]
			[[Kategorie:Daten-Management]]

Jakobw: Die Seite wurde neu angelegt: {{In Bearbeitung}} Es gibt verschiedene Möglichkeiten wie man Vererbungen, sogenannte IS-A-Beziehungen, in Datenbanken realisieren kann. Die unterschiedlichen Impleme...

2009-07-17T06:56:49Z

Die Seite wurde neu angelegt: {{In Bearbeitung}} Es gibt verschiedene Möglichkeiten wie man Vererbungen, sogenannte IS-A-Beziehungen, in Datenbanken realisieren kann. Die unterschiedlichen Impleme...

Neue Seite

{{In Bearbeitung}}

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=
==Implementierungsvarianten Relationenschema==

'''1. Möglichkeit'''
e: id, e1, e2
f: id, e1, e2, f1, f2 (id -> E: id)

[...]

'''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(nicht empfohlen)
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==
'''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=

=Quellen=
Wenn die Definitionen und/oder die Anmerkungen nicht von einem selbst stammen, sollte man die Quellen angeben
(das sind natürlich nur Beispiele, keine echten Quellen dieses Artikels :-) ):

*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931

Besser ist es spezielle Quellendokumente zu erstellen (und diese dann auch mit Inhalt zu füllen):

*[[Kowarschick, W. et al. (2005): Musterquelle (Buch)]]
*[[Goldratt, E.; Cox , J. (2004): The Goal]]
*[[Leach, L. (2005): Critical Chain Project Management]]

Auch externe Quellen können zitiert werden.

*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke] (besser als eigenes Quellen-Dokument, basierend auf der [[Vorlage:Quelle:URL]])
*[http://de.wikipedia.org/ Wikipedia] ('''so nicht''', da zu allgemein und außerdem nicht der Wikipedia-Verweis benutzt wurde)
*[[Wikipedia:Vorlage (Datenverarbeitung)]] (sondern eher so, aber noch besser auch als eigenes Quellen-Dokument)

=Siehe auch=
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.

*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]

[[Kategorie:Glossar]]
[[Kategorie:GlossarWiki]]
[[en:GlossaryWiki:Sample Page]]