49
Konzepte objektorientierter Datenbanken Strukturteil

Konzepte objektorientierter Datenbanken Strukturteil

Embed Size (px)

Citation preview

Page 1: Konzepte objektorientierter Datenbanken Strukturteil

Konzepte objektorientierter Datenbanken

Strukturteil

Page 2: 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

Page 3: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 4: Konzepte objektorientierter Datenbanken Strukturteil

Ü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

Page 5: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 6: Konzepte objektorientierter Datenbanken Strukturteil

Beispiel Personen: Graphik

TupelMenge

Page 7: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 8: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 9: Konzepte objektorientierter Datenbanken Strukturteil

Ü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?

Page 10: Konzepte objektorientierter Datenbanken Strukturteil

Objekttyp Bücher graphisch

Page 11: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 12: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 13: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 14: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 15: Konzepte objektorientierter Datenbanken Strukturteil

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?

Page 16: Konzepte objektorientierter Datenbanken Strukturteil

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!

Page 17: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 18: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 19: Konzepte objektorientierter Datenbanken Strukturteil

Bücher mit Identifier-Attributen

Buch_ID ISBN Titel Verl_ID Autoren Stichw.

0110110 3-19-5-3 DB2 0010011 VossenWitt

RDBSLehrb.

0110100 0-53-5-3 Princ. of 0010111 ElmasriNavathe

RDBSLehrb.ODBS

Page 20: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 21: Konzepte objektorientierter Datenbanken Strukturteil

Darstellung durch Zustandsboxen

88250WeingartenGartenstr. 5

Hugo1.5.89

Zustand von Objekt 19

19

Objekt 19

2

Page 22: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 23: Konzepte objektorientierter Datenbanken Strukturteil

Bücher mit abstrakten Objekten und disjunkten Domänen

Buch ISBN Titel Verlag Autoren Stichw.

1 3-19-5-3 DB2

1 VossenWitt

RDBSLehrb.

2 0-53-5-3 Princ. of

2 ElmasriNavathe

RDBSLehrb.ODBS

1 ist keine Adresse eines Verlags, kein Schlüssel eines Verlags, sondern ein gesamtes Objekt vom Typ Verlag

Page 24: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 25: Konzepte objektorientierter Datenbanken Strukturteil

Ü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?

Page 26: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 27: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 28: Konzepte objektorientierter Datenbanken Strukturteil

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 <Linie*> Linien

Page 29: Konzepte objektorientierter Datenbanken Strukturteil

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;

Page 30: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 31: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 32: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 33: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 34: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 35: Konzepte objektorientierter Datenbanken Strukturteil

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 StudentenSET OF (TUPLE OF (

MatrikelNr: STRING, Teilnahme: SET OF (TUPLE OF( VName: STRING,

VPrüfungsart: CHAR,Note: INTEGER))))

Page 36: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 37: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 38: Konzepte objektorientierter Datenbanken Strukturteil

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*>ZeugnisINVERSE_MEMBER Stud; ...};

CLASS Vorlesung { ... os_Set<Zeugniseintrag*>Teilnehmer INVERSE_MEMBER V; ...};

CLASS Zeugniseintrag {Student Stud; Vorlesung V; int Note;}

Page 39: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 40: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 41: Konzepte objektorientierter Datenbanken Strukturteil

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.

Page 42: Konzepte objektorientierter Datenbanken Strukturteil

Klassenbaum und Klassengraph

• Von Unterklasse bilde wiederum Unterklasse Klassenbaum

Tiere

Wirbeltiere

Säugetiere Vögel

wirbellose Tiere

Page 43: Konzepte objektorientierter Datenbanken Strukturteil

Klassenbaum und Klassengraph

• Bilde Unterklasse von mehreren Klassen (multiple Vererbung) Klassengraph

• Nicht bei allen objektorientierten Systemen möglich

• bei C++ erlaubt

Page 44: Konzepte objektorientierter Datenbanken Strukturteil

Objekte in mehreren Klassen

Beispiel: ER-Diagramm eines Adressbuchs

Person

FreundKollege

o

Name TelNrAdresse

RaumNr Tel dienstl HobbiesGeb.datum

Page 45: Konzepte objektorientierter Datenbanken Strukturteil

Probleme bei der Realisierung

• In C++ kann jedes Objekt nur in einer Klasse seinNeue Klasse Kollege_und_Freund nötig als Spezialisierung von

Kollege und von FreundExplosion von Kombinationsklassen

• Klassenwechsel eines Objekts nicht möglich, z. B.– Kollege wird Freund

– Kollege und Freund geht in Rente, bleibt aber FreundObjekt muss gelöscht und in anderer Klasse neu eingefügt

werden.

Page 46: Konzepte objektorientierter Datenbanken Strukturteil

Klassenhierarchie für Beispielszenario

Page 47: Konzepte objektorientierter Datenbanken Strukturteil

Legende für Klassengraph

Page 48: Konzepte objektorientierter Datenbanken Strukturteil

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

Page 49: Konzepte objektorientierter Datenbanken Strukturteil

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