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

Bücher mit Identifier-Attributen

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 Zustand von Objekt 19 Objekt 19 Hugo 1.5.89 19 88250 Weingarten Gartenstr. 5 2

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.

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

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

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

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;

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;

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  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 wirbellose Tiere Säugetiere 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 o   Freund Kollege RaumNr Tel dienstl 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