konzepte objektorientierter datenbanken
DESCRIPTION
Konzepte objektorientierter Datenbanken. Strukturteil. objektorientierter Bereich komplexe Objekte Objektidentität Einkapselung Typen und Klassen Klassenhierarchien Überladen von Methoden Erweiterbarkeit optional: Mehrfachvererbung. Datenbankbereich Persistenz - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/1.jpg)
Konzepte objektorientierter Datenbanken
Strukturteil
![Page 2: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/2.jpg)
Vorderungen an OODBS
objektorientierter Bereich
• komplexe Objekte
• Objektidentität
• Einkapselung
• Typen und Klassen
• Klassenhierarchien
• Überladen von Methoden
• Erweiterbarkeit
optional:
• Mehrfachvererbung
Datenbankbereich
• Persistenz
• Sekundärspeicher-Verwaltung
• Nebenläufige Transaktionen
• Recovery-Mechanismen
• Anfragesprachen
• Datenbankoperationen
optional:
• verteilte Datenbank
• Versionsverwaltung
![Page 3: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/3.jpg)
3.1 Typkonstruktoren, komplexe Objekte
• Um viele Objekte speichern und bearbeiten zu können, braucht man einen Mengenkonstruktor
• Typ einer relationalen TabelleSET OF (TUPLE OF (Typ1 A1, . . . , Typn An))
• In OODBS können außer Grundtypen auch benutzerdefinierte Klassen verwendet werden.
• TUPLE OF entspricht der Aggregation.• Unterschiedliche Realisierung des Mengenkonstruktors
bei verschiedenen OODBMs
![Page 4: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/4.jpg)
Überblick Typkonstruktoren
• Tupelkonstruktor TUPLE OF– fasst mehrere Komponenten unterschiedlicher Typen zusammen
– entspricht der Aggregation
• Mengenkonstruktor SET OF– mehrere Elemente eines Typs bilden eine Menge
– jedes Element ist nur einmal in der Menge enthalten
• Multimengenkonstruktor BAG OF: wie Menge, aber– ein Element kann mehrfach vorkommen
• Listenkonstruktor LIST OF: wie Multimenge, aber– Reihenfolge interessant
Typkonstruktoren werden rekursiv angewendet
![Page 5: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/5.jpg)
Beispiel komplexer Typ in O2: Personen
SET OF
(TUPLE OF
(Name: TUPLE OF (Vorname: STRING,
Nachname: STRING),
Adresse: TUPLE OF (PLZ: STRING,
Ort: STRING,
Straße: STRING,
Hausnr: STRING),
Hobbies: SET OF (Hobby: STRING),
Geburtsdatum: DATE))
![Page 6: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/6.jpg)
Beispiel Personen: Graphik
TupelMenge
![Page 7: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/7.jpg)
Beispiel Personen in Object Store
• CLASS Namen{public: STRING Vorname; STRING Nachname};
• CLASS Adressen{public: STRING PLZ; STRING Ort; STRING Straße; STRING Hausnummer};
• CLASS Personen{public: Namen Name; Adressen Adresse; os_Set <STRING> Hobby; DATE Geburtsdatum};
• os_Set <Personen*> Personenmenge
![Page 8: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/8.jpg)
Typkonstruktoren in Objekt Store
• Aggregation durch Klassenbildung• Mengenkonstruktoren durch vordefinierte generische
Klassen os_Collection mit den Unterklassen• Mengenkonstruktor: os_Set• Multimengenkonstruktor: os_Bag• Listenkonstruktor: os_List• Elementtypen sind Zeiger auf andere Klassen
![Page 9: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/9.jpg)
Übung
• Stellen Sie den Objekttyp Bücher als komplexen Typ in O2-Syntax dar!
• Verwenden Sie für die Autoren den Listenkonstruktor!• Stellen Sie den Objekttyp Bücher graphisch dar!• Geben Sie den gleichen Objekttyp in Object-Store an!• Machen Sie sich die Auswirkungen rekursiver Typen klar.
Was passiert z. B., wenn die Freunde einer Person im Objekttyp Person berücksichtigt werden?
![Page 10: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/10.jpg)
Objekttyp Bücher graphisch
![Page 11: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/11.jpg)
Operationen auf komplexen Typen
• Tupelkonstruktor– Komponentenzugriff
– Test auf Gleichheit zweier Tupel
• Mengenkonstruktor– Zugriff auf alle Elemente
– Test auf ein Element
– Mengenvergleiche: =, – Mengenoperationen, z. B. Durchschnitt
• Listenkonstruktor– Zugriff auf Elemente in Reihenfolge
• allgemein: Einfügen, Löschen, Ändern
![Page 12: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/12.jpg)
3.2 Objektidentität: Nachteile von Schlüsseln
• Kein Unterschied zwischen Änderung des Objektwertes (Inhalt) und der Objektidentität (Schlüssel).
• Problem, wenn mehrere Objekte ein gemeinsames Komponentenobjekt beinhalten (z. B. Raumnr. bei Vorl.)
• Es ist nicht möglich, verschiedene Objekte mit gleichem Wert darzustellen, da der Schlüssel zum Wert gehört.
• Bei Abfragen sind ineffiziente Joins nötig.
![Page 13: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/13.jpg)
Arten der Objektidentität
• physische Adressen, direkte Referenzen, Zeiger– Zeiger zeigen auf Komponentenobjekt
– Zeiger zeigen auf Beginn einer Liste bei mengenwertigen Attributen
• Namen aus einem benutzerdefinierten Namensraum– z. B. Personalnummern nach bestimmtem Schema
• Identifier-Attribute = automatische Schlüssel = Surrogate• abstrakte Objekte
![Page 14: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/14.jpg)
Unterscheide Objekte und Werte
Objekte– Beispiel:
Person Martin Hulin
– nicht druckbar
– müssen erzeugt und definiert werden
– tragen selbst keine Information
– werden beschrieben
Werte– Beispiel:
Zahl 182
– druckbar
– sind schon da
– tragen selbst die Information
– beschreiben etwas
![Page 15: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/15.jpg)
Objektidentität durch physische Adressen
• Beispiel: Häuser werden durch ihre Adresse oder ihre Koordinaten identifiziert
• Vorteile– einfach zu implementieren
– effizient, da Komponenten schnell zu finden sind
– ist kein Wert sondern Objekt
• Nachteile– physikalische Datenunabhängigkeit verletzt
– Objekt nicht verschiebbar
– Was passiert beim Löschen?
![Page 16: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/16.jpg)
Objektidentität durch Namen
• Beispiel: Nummernschilder von Autos• Vorteil
– Name kann strukturiert sein und damit leicht zu lesen.
• Nachteile– kann als Wert interpretiert werden
– Name kann sich ändern (z. B. Autoummeldung)
– Eindeutigkeit muss überwacht werden.
– siehe Schlüssel!
![Page 17: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/17.jpg)
Objektidentität durch Identifier-Attribute
• Beispiel: AutoZähler in Access, SEQUENCE in Oracle• Vorteile
– Eindeutigkeit wird vom System garantiert
– kann nicht geändert werden
– trägt (fast) keine Information, ist also Objekt(ersatz)
• Nachteile– Fremdschlüsselbedingungen müssen definiert werden
– Identifier-Attribute können nicht wie normale Attribute behandelt werden.
![Page 18: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/18.jpg)
Beispiel Buch mit Identifier-Attribut
SET OF
(TUPLE OF ( Bücher_ID: IDENTIFIER,
ISBN: STRING,
Titel: STRING,
Verlags_ID: IDENTIFIER,
Autoren: LIST OF (Autor: STRING),
Stichworte: SET OF (Stichwort: STRING),
Versionen: SET OF
(TUPLE OF (Auflage: INT,
Jahr: INT))))
![Page 19: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/19.jpg)
Bücher mit Identifier-Attributen
Buch_ID ISBN Titel Verl_ID Autoren Stichw.
0110110 3-19-5-3 DB2 0010011 VossenWitt
RDBSLehrb.
0110100 0-53-5-3 Princ. of 0010111 ElmasriNavathe
RDBSLehrb.ODBS
![Page 20: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/20.jpg)
Objektidentität durch abstrakte Objekte
• Objekte sind Elemente einer – unstrukturierten,
– abzählbar unendlich großen,
– abstrakten Menge
– über deren Elemente man nur weiß, dass sie verschieden sind
• Davon unterschieden werden Werte von Objekten• abstrakte Objekte können (mehr oder weniger gut)
implementiert werden durch– physische Adressen
– Namen
– Identifier-Attribute
![Page 21: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/21.jpg)
Darstellung durch Zustandsboxen
88250WeingartenGartenstr. 5
Hugo1.5.89
Zustand von Objekt 19
19
Objekt 19
2
![Page 22: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/22.jpg)
abstrakte Objekte
• Vorteile– unabhängig von der Implementierung
– theoretisch fundiert
– Fremdschlüsselbedingungen werden vom System garantiert
• Nachteile– nur in wenigen realen OODBMSn realisiert
• Zwei Varianten– Eine unendliche Menge mit abstrakten Objekten für alle Klassen
– Für jeden Objekttyp wird eine eigene abstrakte Domäne eingeführt. Diese Domänen sind disjunkt.
![Page 23: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/23.jpg)
Bücher mit abstrakten Objekten und disjunkten Domänen
Buch ISBN Titel Verlag Autoren Stichw.
1 3-19-5-3 DB2
1 VossenWitt
RDBSLehrb.
2 0-53-5-3 Princ. of
2 ElmasriNavathe
RDBSLehrb.ODBS
1 ist keine Adresse eines Verlags, kein Schlüssel eines Verlags, sondern ein gesamtes Objekt vom Typ Verlag
![Page 24: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/24.jpg)
Operationen auf Objekten
• Test auf Identität: o1 == o2
z. B. Vater von Peter == Vater von Susanne• Test auf flache (Wert-)Gleichheit• Test auf tiefe (Wert-)Gleichheit• Zuweisung: erzeugt wird Referenz auf Objekt• flaches Kopieren• tiefes Kopieren
![Page 25: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/25.jpg)
Übung zu Objektoperationen
• Erzeugen Sie ein neues Buch-Objekt 3 durch flaches Kopieren von 1
• Erzeugen Sie ein neues Buch-Objekt 4 durch tiefes Kopieren von 1
• Test auf flache Gleichheit zwischen 1 und 3?
• Test auf flache Gleichheit zwischen 1 und 4?
• Zuweisung von 1 an die Variable Lieblingsbuch
1 == Lieblingsbuch?
1 == 3?
![Page 26: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/26.jpg)
3.3 Klassen und Typen
Klasse hat 2 Bedeutungen:• Menge zusammengehöriger Objekte, Sammelbehälter• Typ = Aufbauschema dieser Objekte
Bestandteile einer Klasse:• Domäne für (abstrakte) Objekte• Menge aller bisher erzeugten Objekte der Klasse• Zustandstyp der Klasse = Aufbauschema• Zustandsfunktion ordnet jedem Objekt seinen Wert, ein
Element des Zustandstyps, zu
![Page 27: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/27.jpg)
Alternative Konzepte bei Klassen
• Typ-basiertes Schema– Klasse definiert einen komplexen Typ
– Objekte der Klasse (Variablen) werden nicht gesammelt
– Extra Sammelobjekte nötig, z. B. os_Set
• Klassen-typ-basiertes Schema (siehe vorige Folie)– Klasse definiert einen komplexen Typ
– Klasse ist Sammelbehälter
• Klassen-basiertes Schema– Klasse ist Sammelbehälter
– Typen der Komponenten sind nicht festgelegt
![Page 28: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/28.jpg)
Typ-basiert
Class Linie
Punkt anf;Punkt end;int dicke;
Linie x
(3;15);(5;17);
6;
Linie a2
(3;0);(5;17);
2;
Linie yxa
(3;15);(1;1);
6;
Typ von
os_Set <Linie*> Linien
![Page 29: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/29.jpg)
Klassen-Typ-basiert
Class Linien
Punkt anf;Punkt end;int dicke;
Linie x
(3;15);(5;17);
6;
Linie a2
(3;1);(5;17);
3;
Linie gt
(3;15);(5;1);
6;
![Page 30: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/30.jpg)
Klassen-basiert
Class Linien
anf;end;
dicke;
Linie x
(3;15);(5;17);
6;
Linie a2
(3;1);(5;17);
3;
Linie gt
"p1";"p2";
"dünn";
![Page 31: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/31.jpg)
3.4 Beziehungen zwischen Klassen
• Jede Klasse besteht aus Attributen = Komponenten.• Diese können wieder Klassen sein.• Klassen-Komponentenklassen-Beziehung realisiert
Relationen zwischen verschiedenen Klassen.• Andere Art von Relation:
Klasse-Unterklasse-Beziehungsiehe 3.5!
• Unterschiedliche Semantik von Komponentenklassen– gemeinsame/private Komponentenobjekte
– abhängige/unabhängige Komponentenobjekte
– eingekapselte/eigenständige Komponentenobjekte
![Page 32: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/32.jpg)
gemeinsame/private Komponentenobjekte
• gemeinsame Komponentenobjekte:– Ein Komponentenobjekt ist Komponente von mehreren
übergeordneten Objekten
– Komponente kann in Objekten verschiedener Klassen sein
– M:N(1)-Relation zwischen Klasse und Komponentenklasse
– Beispiel: Verlage ist gemeinsame Komponente bei Bücher
• private Komponentenobjekte:– Jedes Komponentenobjekt ist Komponente von nur einem
übergeordneten Objekt
– 1:N(1)-Relation zwischen Klasse und Komponentenklasse
– Beispiel: Mitarbeiter ist private Komponente von Abteilung
![Page 33: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/33.jpg)
abhängige/unabhängige Komponentenobjekte
• abhängige Komponentenobjekte existieren nur mit übergeordnetem Objekt werden mit übergeordnetem Objekt erzeugt und gelöscht
– Gemeinsame abhängige Objekte werden mit letztem übergeordneten Objekt gelöscht.
– Beispiel: Adresse ist von Person abhängig.
• unabhängige Komponentenobjekte existieren auch ohne übergeordnetes Objekt werden unabhängig erzeugt und gelöscht
– beim Löschen muss auf übergeordnete Objekte geachtet werden
– Beispiel: Verlage sind unabhängige Komponente von Bücher.
![Page 34: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/34.jpg)
eingekapselte/eigenständige Komponentenobjekte
• eingekapselte Komponentenobjekte sind nur über ihre übergeordneten Objekte erreichbar. sind immer abhängig.
– Redundanz bei M:N-Relationen
– Beispiel: Name ist eingekapselt in Personen
• eigenständige Komponentenobjekte sind direkt erreichbar. sind auch über ihre übergeordneten Objekte erreichbar.
– Beispiel: Verlage ist eine eigenständige Klasse. Eine Auflistung aller Verlage kann erstellt werden, ohne die Klasse Bücher.
![Page 35: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/35.jpg)
Darstellung von Relationen:1. gekapselte Komponentenklassen
komplexe Objekte mit eingekapselten Strukturen– geeignet für 1:1- und 1:N-Relationen
– bei M:N-Relationen Redundanz
– Zugriff nicht symmetrisch:• einfach von Klasse auf Komponente
• schwierig von Komponente auf umfassende Klasse
Beispiel StudentenSET OF (TUPLE OF (
MatrikelNr: STRING, Teilnahme: SET OF (TUPLE OF( VName: STRING,
VPrüfungsart: CHAR,Note: INTEGER))))
![Page 36: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/36.jpg)
Darstellung von Relationen:2. gegenseitige Komponentenklassen
Zwei Klassen haben die jeweils andere als Komponente– geeignet für 1:1-, 1:N- und M:N-Relationen
– Zugriff symmetrisch
– System muss die Symmetrie überwachen bei Änderungsoperationen
– Die Relation darf keine eigenen Attribute haben, z. B. ist die Note eines Studenten für eine Vorlesung nicht darstellbar
![Page 37: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/37.jpg)
Beispiel: Student und Vorlesung
• CLASS Student {STRING MatrikelNr; os_Set <Vorlesung*>besuchte_Vorlesungen
INVERSE_MEMBER os_Set<Teilnehmer>;}• CLASS Vorlesung {
STRING VName; char Prüfungsart;os_Set <Student*>TeilnehmerINVERSE_MEMBER os_Set<besuchte_Vorlesungen>;}
![Page 38: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/38.jpg)
Darstellung von Relationen:3. Verbindungsklasse
• Die Relation wird zu einer eigenen Klasse– geeignet für M:N-Relationen mit eigenen Attributen
– jeweils 1:N-Relationen von den Klassen zur Verbindungsklasse
• Beispiel: Studenten und Vorlesungen
CLASS Student { ... os_Set<Zeugniseintrag*>ZeugnisINVERSE_MEMBER Stud; ...};
CLASS Vorlesung { ... os_Set<Zeugniseintrag*>Teilnehmer INVERSE_MEMBER V; ...};
CLASS Zeugniseintrag {Student Stud; Vorlesung V; int Note;}
![Page 39: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/39.jpg)
3.5 Strukturvererbung
• Besondere Relation zwischen Klassen: "ist ein"z. B. Student Müller "ist eine" Person
• TypvererbungSeien T_O und T_U Typen.T_O ist Obertyp von T_U, T_U Untertyp von T_O– bei atomaren Typen, wenn T_U T_O
z. B. short int long int
– bei Tupeltypen, wenn T_U mindestens alle Komponenten von T_O hat, z. B. Student und Person
– bei Mengentypen, wenn der Elementtyp von T_U Untertyp des Elementtyps von T_O ist
![Page 40: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/40.jpg)
Strukturvererbung (Forts.)
• KlassenhierarchieSeien K_U und K_O Klassen– K_U ist spezieller als K_O, wenn
Objektmenge (K_U) Objektmenge (K_O)
– K_U ist Unterklasse, K_O ist Oberklasse
• Klassen- und Typhierarchie passen zusammen, z. B. – Klassenhierarchie: Studenten Personen
– Typhierarchie: Student hat alle Attribute von Person und mehr
– DBMS sichert zu, dass jedes Objekt von Student auch Person ist
– In C++ nur Typhierarchie
![Page 41: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/41.jpg)
Operationen zur Klassenbildung
• Spezialisierung– definiert Unterklassen durch Vererbung der Oberklasse
– Nicht alle Objekte der Oberklasse müssen in einer der Unterklassen vorkommen
• Generalisierung– fasst mehrere Klassen zu gemeinsamer Oberklasse zusammen
– Alle Objekte der Unterklassen kommen in die Oberklasse
• Spezialisierung und Generalisierung erzeugen sog. freie Klassen ohne eigene abstrakte Objektmenge
• In C++ nur Spezialisierung möglich, Generalisierung muss vorher im Kopf (Konzept) erfolgen.
![Page 42: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/42.jpg)
Klassenbaum und Klassengraph
• Von Unterklasse bilde wiederum Unterklasse Klassenbaum
Tiere
Wirbeltiere
Säugetiere Vögel
wirbellose Tiere
![Page 43: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/43.jpg)
Klassenbaum und Klassengraph
• Bilde Unterklasse von mehreren Klassen (multiple Vererbung) Klassengraph
• Nicht bei allen objektorientierten Systemen möglich
• bei C++ erlaubt
![Page 44: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/44.jpg)
Objekte in mehreren Klassen
Beispiel: ER-Diagramm eines Adressbuchs
Person
FreundKollege
o
Name TelNrAdresse
RaumNr Tel dienstl HobbiesGeb.datum
![Page 45: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/45.jpg)
Probleme bei der Realisierung
• In C++ kann jedes Objekt nur in einer Klasse seinNeue Klasse Kollege_und_Freund nötig als Spezialisierung von
Kollege und von FreundExplosion von Kombinationsklassen
• Klassenwechsel eines Objekts nicht möglich, z. B.– Kollege wird Freund
– Kollege und Freund geht in Rente, bleibt aber FreundObjekt muss gelöscht und in anderer Klasse neu eingefügt
werden.
![Page 46: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/46.jpg)
Klassenhierarchie für Beispielszenario
![Page 47: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/47.jpg)
Legende für Klassengraph
![Page 48: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/48.jpg)
Aufgabe: Klassengraph erstellen
• Bei einem Autohändler in Ravensburg kann man nicht nur Autos kaufen, sondern auch Reisen buchen.
• Erstellen Sie einen Klassengraph für folgende Klassen– Fahrzeuge
– Autos
– Lastkraftwagen
– Urlaubsreisen
– Personen
– Kunden
– Mitarbeiter
– Verkäufe
![Page 49: Konzepte objektorientierter Datenbanken](https://reader035.vdocuments.mx/reader035/viewer/2022062309/5681593e550346895dc67b5d/html5/thumbnails/49.jpg)
3.6 Integritätsbedingungen
• Im objektorientierten Modell inherente Integritätsbed.– Fremdschlüssel unnötig, da Komponentenbeziehung und
Unterklassenbeziehung
– Unterklassen von Standardtypen statt Check-Constraints
• NOT-NULL-Constraint• UNIQUE-Constraint:
– Eine Kombination von Attributen (evtl. auch von Komponentenklassen) muss eindeutig sein.
– wird auch für Zugriffsoptimierung verwendet
• Einschränkung von M:N-Relationen auf 1:N- oder 1:1-Relatinen