Konzepte objektorientierter Datenbanken Strukturteil

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

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

TupelMenge

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?

Objekttyp Bücher graphisch

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

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

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

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

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

88250WeingartenGartenstr. 5

Hugo1.5.89

Zustand von Objekt 19

19

Objekt 19

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

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

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

Ü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

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

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

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;

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

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 StudentenSET 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*>ZeugnisINVERSE_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_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

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

Säugetiere Vögel

wirbellose Tiere

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

Person

FreundKollege

o

Name TelNrAdresse

RaumNr Tel dienstl HobbiesGeb.datum

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.

Klassenhierarchie für Beispielszenario

Legende für Klassengraph

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