490 likes | 583 Views
Konzepte objektorientierter Datenbanken. Strukturteil. objektorientierter Bereich komplexe Objekte Objektidentität Einkapselung Typen und Klassen Klassenhierarchien Überladen von Methoden Erweiterbarkeit optional: Mehrfachvererbung. Datenbankbereich Persistenz
E N D
Konzepte objektorientierter Datenbanken Strukturteil
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 Vorderungen an OODBS
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
Ü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?
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
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 Unterscheide Objekte und Werte
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))))
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 Hugo1.5.89 19 88250WeingartenGartenstr. 5 2
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 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 == o2z. 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 und3? • Test auf flache Gleichheit zwischen 1 und4? • 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
Class Linie Linie x Linie a2 Linie yxa Punkt anf;Punkt end;int dicke; (3;15);(5;17);6; (3;0);(5;17);2; (3;15);(1;1);6; Typ-basiert Typ von os_Set <Linie*> Linien
Class Linien Linie x Linie a2 Linie gt Punkt anf;Punkt end;int dicke; (3;15);(5;17);6; (3;1);(5;17);3; (3;15);(5;1);6; Klassen-Typ-basiert
Class Linien Linie x Linie a2 Linie gt anf;end;dicke; (3;15);(5;17);6; (3;1);(5;17);3; "p1";"p2";"dünn"; Klassen-basiert
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
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*>TeilnehmerINVERSE_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 • 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_Oz. 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.) • 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
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 Vögel Säugetiere
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.
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