Konzepte objektorientierter Datenbanken

Konzepte objektorientierter
Datenbanken
Strukturteil
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
3.1 Typkonstruktoren, komplexe Objekte
• Um viele Objekte speichern und bearbeiten zu können,
braucht man einen Mengenkonstruktor
• Typ einer relationalen Tabelle
SET 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
Ü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
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))
Beispiel Personen: Graphik
Menge
Tupel
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
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
Ü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?
Objekttyp Bücher graphisch
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
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.
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
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
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?
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!
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.
Beispiel Buch mit Identifier-Attribut
SET OF
(TUPLE OF ( Bücher_ID:
ISBN:
Titel:
Verlags_ID:
Autoren:
Stichworte:
Versionen:
IDENTIFIER,
STRING,
STRING,
IDENTIFIER,
LIST OF (Autor: STRING),
SET OF (Stichwort: STRING),
SET OF
(TUPLE OF (Auflage: INT,
Jahr: INT))))
Bücher mit Identifier-Attributen
Buch_ID ISBN
Titel
0110110 3-19-5-3 DB2
Verl_ID Autoren Stichw.
0010011 Vossen RDBS
Witt
Lehrb.
0110100 0-53-5-3 Princ. of 0010111 Elmasri RDBS
Navathe Lehrb.
ODBS
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
Darstellung durch Zustandsboxen
Objekt 19
19
Zustand von Objekt 19
Hugo
1.5.89
2
88250
Weingarten
Gartenstr. 5
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.
Bücher mit abstrakten Objekten und
disjunkten Domänen
Buch
ISBN
Titel
Verlag Autoren Stichw.
1
3-19-5-3 DB2
1
Vossen RDBS
Witt
Lehrb.
2
0-53-5-3 Princ. of 2
Elmasri RDBS
Navathe Lehrb.
ODBS
1 ist keine Adresse eines Verlags, kein Schlüssel eines Verlags,
sondern ein gesamtes Objekt vom Typ Verlag
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
Ü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?
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
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
Typ-basiert
Typ von
Class Linie
Linie x
Punkt anf;
Punkt end;
int dicke;
(3;15);
(5;17);
6;
Linie a2
(3;0);
(5;17);
2;
os_Set <Linie*> Linien
Linie yxa
(3;15);
(1;1);
6;
Klassen-Typ-basiert
Linie x
Class Linien
Punkt anf;
Punkt end;
int dicke;
(3;15);
(5;17);
6;
Linie a2
(3;1);
(5;17);
3;
Linie gt
(3;15);
(5;1);
6;
Klassen-basiert
Linie x
Class Linien
anf;
end;
dicke;
(3;15);
(5;17);
6;
Linie a2
(3;1);
(5;17);
3;
Linie gt
"p1";
"p2";
"dünn";
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-Beziehung
siehe 3.5!
• Unterschiedliche Semantik von Komponentenklassen
– gemeinsame/private Komponentenobjekte
– abhängige/unabhängige Komponentenobjekte
– eingekapselte/eigenständige Komponentenobjekte
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
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.
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.
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 Studenten
SET OF (TUPLE OF (
MatrikelNr: STRING, 
Teilnahme: SET OF (TUPLE OF( VName: STRING, 
VPrüfungsart: CHAR,
Note: INTEGER))))
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
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*>Teilnehmer
INVERSE_MEMBER os_Set<besuchte_Vorlesungen>;}
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*>Zeugnis
INVERSE_MEMBER Stud; ...};
CLASS Vorlesung { ... os_Set<Zeugniseintrag*>Teilnehmer
INVERSE_MEMBER V; ...};
CLASS Zeugniseintrag {Student Stud; Vorlesung V; int Note;}
3.5 Strukturvererbung
• Besondere Relation zwischen Klassen: "ist ein"
z. B. Student Müller "ist eine" Person
• Typvererbung
Seien 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
Strukturvererbung (Forts.)
• Klassenhierarchie
Seien 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
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.
Klassenbaum und Klassengraph
• Von Unterklasse bilde wiederum Unterklasse
 Klassenbaum
Tiere
Wirbeltiere
Säugetiere
wirbellose Tiere
Vögel
Klassenbaum und Klassengraph
• Bilde Unterklasse von
mehreren Klassen
(multiple Vererbung)
 Klassengraph
• Nicht bei allen
objektorientierten
Systemen möglich
• bei C++ erlaubt
Objekte in mehreren Klassen
Beispiel: ER-Diagramm eines Adressbuchs
Name
Adresse
TelNr
Person

Kollege
RaumNr
Tel dienstl
o

Freund
Geb.datum
Hobbies
Probleme bei der Realisierung
• In C++ kann jedes Objekt nur in einer Klasse sein
Neue Klasse Kollege_und_Freund nötig als Spezialisierung von
Kollege und von Freund
Explosion von Kombinationsklassen
• Klassenwechsel eines Objekts nicht möglich, z. B.
– Kollege wird Freund
– Kollege und Freund geht in Rente, bleibt aber Freund
Objekt muss gelöscht und in anderer Klasse neu eingefügt
werden.
Klassenhierarchie für Beispielszenario
Legende für Klassengraph
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
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