1 / 49

Konzepte objektorientierter Datenbanken

Konzepte objektorientierter Datenbanken. Strukturteil. objektorientierter Bereich komplexe Objekte Objektidentität Einkapselung Typen und Klassen Klassenhierarchien Überladen von Methoden Erweiterbarkeit optional: Mehrfachvererbung. Datenbankbereich Persistenz

kendall
Download Presentation

Konzepte objektorientierter Datenbanken

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Konzepte objektorientierter Datenbanken Strukturteil

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

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

  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 Hugo1.5.89 19 88250WeingartenGartenstr. 5 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: 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

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

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

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

  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-Beziehungsiehe 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 <Vorlesung*>besuchte_Vorlesungen INVERSE_MEMBER os_Set<Teilnehmer>;} • CLASS Vorlesung {STRING VName; char Prüfungsart;os_Set <Student*>TeilnehmerINVERSE_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 • 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

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

  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 Vögel Säugetiere

  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

More Related