Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Konzepte objektorientierter Datenbanken Strukturteil.

Ähnliche Präsentationen


Präsentation zum Thema: "Konzepte objektorientierter Datenbanken Strukturteil."—  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 O 2 : 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 Tupel Menge

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 Hobby; DATE Geburtsdatum}; os_Set 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 O 2 -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 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

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

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

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: o 1 == o 2 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 definiert einen komplexen Typ –Klasse ist Sammelbehälter Klassen-basiertes Schema –Klasse ist Sammelbehälter –Typen der Komponenten sind nicht festgelegt

28 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 Linien

29 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;

30 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";

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

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 besuchte_Vorlesungen INVERSE_MEMBER os_Set ;} CLASS Vorlesung { STRING VName; char Prüfungsart; os_Set Teilnehmer INVERSE_MEMBER os_Set ;}

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 Zeugnis INVERSE_MEMBER Stud;...}; CLASS Vorlesung {...os_Set 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 Säugetiere Vögel wirbellose Tiere

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 Person Freund Kollege o NameTelNrAdresse RaumNrTel dienstl Hobbies Geb.datum

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


Herunterladen ppt "Konzepte objektorientierter Datenbanken Strukturteil."

Ähnliche Präsentationen


Google-Anzeigen