Konzepte objektorientierter datenbanken
Download
1 / 49

Konzepte objektorientierter Datenbanken - PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Konzepte objektorientierter Datenbanken' - kendall


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

Vorderungen an OODBS


3 1 typkonstruktoren komplexe objekte
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
Ü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 o 2 personen
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 in object store
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
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
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
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
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

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
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
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
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
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
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
Darstellung durch Zustandsboxen

Zustand von Objekt 19

Objekt 19

Hugo1.5.89

19

88250WeingartenGartenstr. 5

2


Abstrakte objekte
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
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
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
Ü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
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
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


Typ basiert

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


Klassen typ basiert

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


Klassen 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
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/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/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/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
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
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
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
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
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
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
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
Klassenbaum und Klassengraph

  • Von Unterklasse bilde wiederum Unterklasse Klassenbaum

Tiere

Wirbeltiere

wirbellose Tiere

Vögel

Säugetiere


Klassenbaum und klassengraph1
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
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
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
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
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


ad