Konzepte objektorientierter Datenbanken

Präsentation zum Thema: "Konzepte objektorientierter Datenbanken"—  Präsentation transkript:

1 Konzepte objektorientierter Datenbanken
Strukturteil

2 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 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

4 Ü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

5 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))

6 Beispiel Personen: Graphik
Menge Tupel

7 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

8 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

9 Ü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?

10 Objekttyp Bücher graphisch

11 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

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

13 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

14 Unterscheide Objekte und Werte
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

15 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?

16 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!

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

18 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))))

19 Bücher mit Identifier-Attributen

20 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

21 Darstellung durch Zustandsboxen
Zustand von Objekt 19 Objekt 19 Hugo 19 88250 Weingarten Gartenstr. 5 2

22 abstrakte Objekte Vorteile Nachteile Zwei Varianten
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.

23 Bücher mit abstrakten Objekten und disjunkten Domänen
1 ist keine Adresse eines Verlags, kein Schlüssel eines Verlags, sondern ein gesamtes Objekt vom Typ Verlag

24 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

25 Ü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?

26 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

27 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 ist Sammelbehälter Klassen-basiertes Schema Typen der Komponenten sind nicht festgelegt

28 Punkt anf; Punkt end; int dicke;
Typ-basiert Typ von Linie x (3;15); (5;17); 6; Class Linie Punkt anf; Punkt end; int dicke; Linie yxa (3;15); (1;1); 6; Linie a2 (3;0); (5;17); 2; os_Set <Linie*> Linien

29 Punkt anf; Punkt end; int dicke;
Klassen-Typ-basiert Linie x (3;15); (5;17); 6; Linie gt (3;15); (5;1); 6; Class Linien Punkt anf; Punkt end; int dicke; Linie a2 (3;1); (5;17); 3;

30 Klassen-basiert Linie x (3;15); (5;17); 6; Linie gt Class Linien
"p1"; "p2"; "dünn"; Class Linien anf; end; dicke; Linie a2 (3;1); (5;17); 3;

31 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

32 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

33 abhängige/unabhä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.

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

35 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))))

36 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

37 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>;}

38 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;}

39 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

40 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

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

42 Klassenbaum und Klassengraph
Von Unterklasse bilde wiederum Unterklasse  Klassenbaum Tiere Wirbeltiere wirbellose Tiere Säugetiere Vögel

43 Klassenbaum und Klassengraph
Bilde Unterklasse von mehreren Klassen (multiple Vererbung)  Klassengraph Nicht bei allen objektorientierten Systemen möglich bei C++ erlaubt

44 Objekte in mehreren Klassen
Beispiel: ER-Diagramm eines Adressbuchs Name Adresse TelNr Person o   Freund Kollege RaumNr Tel dienstl Geb.datum Hobbies

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

46 Klassenhierarchie für Beispielszenario

47 Legende für Klassengraph

48 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

49 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