8 Datenbanken Objektorientierte Datenbanken

(1)

1

Objektmodellierung

8 Datenbanken Objektorientierte Datenbanken

Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund

OM – Datenbanken

LE 15

2

Lernziele

▲

Wissen, was der ODMG-Standard ist und was seine wichtigsten Komponenten sind

▲

Wissen, was ein objekt-relationales Datenbanksystem ist

▲

Erklären können, was die wesentlichen Eigenschaften von objektorientierten Datenbanksystemen sind

▲

Erklären können, wie die Anbindung an die objektorientierte Programmiersprache C++

funktioniert

▲

Klassendiagramme in ODL spezifizieren können

▲

Anfragen in OQL formulieren können

(2)

LE 15

3

Inhalt

8.4 Objektorientierte Datenbanksysteme 8.5 ODL

8.6 OQL

8.7 Anbindung an C++

8.8 Objekt-relationale Datenbanksysteme

LE 15

4

8.4 Objektorientierte Datenbanksysteme

▲

Objektorientiertes Datenbanksystem

Integriert die Eigenschaften einer Datenbank mit den Möglichkeiten von objektorientierten

Programmiersprachen

▲

ODMG

1991: Gründung der ODMG (Object Database Management Group) durch Hersteller und Anwender von objektorientierten

Datenbanksystemen

1993 Vorschlag eines Standards für objektorientierte Datenbanksysteme:

ODMG-93 1.0

Juni 1997: ODMG-Standard 2.0

(3)

LE 15

5

8.4 Objektorientierte Datenbanksysteme

▲

ODMG-Standard

Objektmodell (Object Model)

Spezifiziert die Konzepte für objektorient. DBS ODL (Object Definition Language)

Schema-Beschreibungssprache OIF (Object Interchange Format)

ASCII-Austauschformat für objektorientierte DBS OQL (Object Query Language)

Deklarative Sprache, die SQL2 ähnlich ist

Ermöglicht Anfragen (queries) in der Datenbank Sprachanbindung an C++

Sprachanbindung an Smalltalk Sprachanbindung an Java

LE 15

6

8.4 Objektorientierte Datenbanksysteme

▲

Objekte und Literale

Das Objektmodell unterscheidet Objekte und Literale

Objekte (objects)

Besitzen Objektidentität und können separat in der Datenbank gespeichert werden

Literale (literals)

Daten, die keine Objektidentität besitzen

Können nur als Teil eines Objekts in der Datenbank gespeichert werden

ODMG-Standard fordert strenge Typisierung

Angabe des Typs für jedes Objekt und jedes Literal

(4)

LE 15

7

8.4 Objektorientierte Datenbanksysteme

▲

Objektidentität

Jedes Objekt besitzt eine eindeutige Objektidentität (OID, object identity)

Keine Änderung während der Lebensdauer des Objekts

Objektidentitäten werden vom Datenbanksystem generiert und verwaltet

Keine (verwendbare) Semantik

Dem Programmierer nicht bekannt Keine Festlegung im ODMG-Standard, wie

Objektidentitäten zu implementieren sind

Objektidentitäten notwendig für das Darstellen von Verbindungen zwischen Objekten

LE 15

8

8.4 Objektorientierte Datenbanksysteme

▲

Realisierung der Objektidentität

Surrogate (surrogate)

Erzeugung durch einen Algorithmus, der Eindeutigkeit garantiert

Zeitstempel bestehend aus Datum und Uhrzeit Zähler, der kontinuierlich erhöht wird

Typisierte Surrogate (typed surrogate)

Besteht aus

Klassen-Identifikator (type ID) und

Objekt-Identifikator, der für jede Klasse individuell inkrementiert wird

(5)

LE 15

9

8.4 Objektorientierte Datenbanksysteme

▲

Objektname

Benutzung durch den Programmierer zur Identifikation

Vergleichbar mit globalen Variablen einer Programmiersprache

Jeder Objektname muß innerhalb einer Datenbank eindeutig sein

LE 15

10

8.4 Objektorientierte Datenbanksysteme

▲

4 Literaltypen

Atomare Literale

long, short, unsigned long, unsigned short (ganze Zahlen)

float, double (reelle Zahlen)

boolean

octet

char, string

enum (Aufzählungstypen) long Artikelnummer Kollektionen von Literalen Strukturierte Literale

Null-Literal (Entspricht dem Null-Wert bei SQL2)

(6)

LE 15

11

8.4 Objektorientierte Datenbanksysteme

▲

Kollektion

Alle Elemente sind vom selben Objekt- oder Literaltyp

Für Kollektionen von Literalen sind definiert

set <t>

bag <t>

list <t>

array <t>

dictionary <t, value>

Ungeordnete Sequenz von Paaren <Schlüssel, Wert>;

keine Duplikate des Schlüssels erlaubt set <Artikel> gelieferteArtikel list <Person> allePersonen

LE 15

12

8.4 Objektorientierte Datenbanksysteme

▲

Struktur

Feste Anzahl von Elementen, von denen jedes einen Namen besitzt und entweder einen Literalwert oder ein Objekt enthalten kann

▲

Typen für strukturierte Literale

date

time

Gibt die aktuelle Zeit in der jeweiligen Zeitzone an

interval

Beschreibt eine Zeitdauer timestamp

Besteht aus Datum und Zeit

(7)

LE 15

13

8.4 Objektorientierte Datenbanksysteme

▲

Objekttyp

Alle Objekte der Datenbank werden durch ihren Typ spezifiziert

ODMG-Standard unterscheidet

Atomare Objekte, die vom Programmierer definiert werden

Kollektionen von Objekten

Strukturierte Objekte

Definition der Typen für Kollektionen und Strukturen analog zu den Literaltypen Objekttypen beginnen immer mit einem

Großbuchstaben

LE 15

14

8.4 Objektorientierte Datenbanksysteme

▲

Klasse (class)

Definiert für ihre Objekte ...

das Verhalten (Operationen) und

den Zustand (Attribute, Assoziationen) Optional

Angabe der Klassenextension (extent)

Angabe eines Schlüssel (key) Beispiel

class Klassenname

( extent Klassenextension key Schlüsselattribut )

(8)

LE 15

15

8.4 Objektorientierte Datenbanksysteme

▲

Klassenextension (extent)

Menge aller Objekte einer Klasse

Programmierer kann entscheiden, ob eine Klassenextension notwendig ist

Neu erzeugte Objekte werden automatisch eingefügt und beim Löschen wieder entfernt Realisiert die Objektverwaltung

Ermöglicht die Durchführung von Operationen auf der Menge aller Objekte einer Klasse

z.B. Selektionen

Verwendung der Klassenextension im select- Befehl von OQL

LE 15

16

8.4 Objektorientierte Datenbanksysteme

▲

Klassenextension und Vererbung

Ist Derived eine Unterklasse von Base, dann ist die Klassenextension von Derivedeine

Teilmenge der Klassenextension von Base

Derived

Base :Base

:Derived

:Derived :Base

:Base

(9)

LE 15

17

8.4 Objektorientierte Datenbanksysteme

▲

Schlüssel (key)

Verwendung für schnellen Zugriff auf Objekte Besteht aus einem (Schlüsselwort key) oder

mehreren (Schlüsselwort keys) Attributen Jeder Schlüssel muß ein Objekt der Klasse

eindeutig identifizieren

Definition der Klassenextension ist

Voraussetzung für die Verwendung eines Schlüssels

LE 15

18

8.4 Objektorientierte Datenbanksysteme

▲

Schnittstelle interface

Spezifiziert nur das Verhalten

Es können keine Objekte erzeugt werden.

Beispiel

interface Schnittstellenname

▲

Vererbung

Zwei Arten von Vererbungsstrukturen

extends

subtyping

Auch is a- oder ISA-Vererbung genannt

(10)

LE 15

19

8.4 Objektorientierte Datenbanksysteme

▲

extends-Vererbung

Einfachvererbung zwischen zwei Klassen Unterklasse erbt die Eigenschaften und das

Verhalten der Oberklasse transitiv

Person

Angestellter

Manager

classPerson

classAngestellterextendsPerson

classManagerextendsAngestellter

LE 15

20

8.4 Objektorientierte Datenbanksysteme

▲

subtyping oder ISA-Vererbung (is a)

Bezieht sich auf die Vererbung von Verhalten Sowohl Klassen als auch Schnittstellen dürfen

von einer Schnittstelle (interface) abgeleitet werden

Person «interface»

Angestellter

Angestellter Person

interfaceAngestellter

classPerson

classAngestellterPerson

extendsPerson : Angestellter

«interface»

Manager

Manager Person

interfaceManager

classManagerPerson

extendsAngestellterPerson : Manager

(11)

LE 15

21

8.4 Objektorientierte Datenbanksysteme

▲

Funktionsweise eines objektorientierten Datenbanksystems

Datenzugriff

Schemadeklaration Anwendungs-Quellcode

in PL

Präprozessor

PL-Compiler

Laufende Anwendung

Legende: PL =programming language,z.B. C++ oder Java DD =data dictionary

Binärcode der Anwendung Laufzeitsystem

des ODBS

Linker ODBS

Daten bank

DB- Schema in DD

PL-Deklaration

Aufgabe1

LE 15

22

8.5 ODL

▲

ODL (Object Definition Language)

Zur Schemadeklaration

Unterstützt alle Konzepte des ODMG-Objektmodells Ist keine vollwertige Programmiersprache

Dient ausschließlich zur Spezifikation von Klassen und Schnittstellen

Ist syntaktisch eine Erweiterung von IDL (Interface Definition Language)

Zu einer ODL-Spezifikation gibt es im Normalfall eine Implementierung in C++, Java oder Smalltalk Es können auch mehrere Implementierungen

existieren, z.B für verschiedene Plattformen

(12)

LE 15

23

8.5 ODL

▲

Attribut in ODL

Ein Attribut ist entweder ...

ein Literal (literal) oder

die Identität (OID) eines Objekts Es kann niemals ein Objekt sein

Attribute, die nur gelesen werden dürfen, sind als readonly gekennzeichnet

Klassenattribute können in ODL nicht spezifiziert werden

LE 15

24

8.5 ODL

▲

Beispiel: Klasse Person

class Person { struct NameT

{ string Vorname, string Nachname };

attribute long Nummer;

attribute NameT Name;

//Datenstruktur (Literal) attribute date Geburtsdatum;

readonly attribute short Alter;

//readonly-Attribut attribute AdresseT Wohnung;

//OID von AdresseT-Objekt };

(13)

LE 15

25

8.5 ODL

class AdresseT

{ attribute string Strasse;

attribute string PLZ;

attribute string Ort;

};

:Person Nummer = 1234 Name = (Hans, Müller) Geburtsdatum = 16.8.56 Alter = 43

Wohnung

:Adr esseT Strasse = Waldweg 1 PLZ = 5678 Ort = Sonnenwinkel

LE 15

26

8.5 ODL

▲

Assoziation in ODL

Nur binäre Assoziationen Darstellung stets bidirektional

Angabe inverse

Keine Unterscheidung zwischen einfacher Assoziation, Aggregation und Komposition Nur Kardinalitäten

1:1

1:m

m:m

Keine Unterscheidung zwischen Muß- und Kann- Assoziationen

Keine assoziativen Klassen

(14)

LE 15

27

8.5 ODL

▲

Beispiel

Handelsbeteiligter Adresse

Telefon

1

* Kunde

Nummer Name Umsatz erfassen

erhoeheUmsatzUm()

Lieferant Firma

Ansprechpartner erfassen()

teuersterArtikelpreis()

Artikel Nummer Bezeichnung Preis erfassen() wechselnLieferant()

wirdGeliefertVon liefert

LE 15

28

8.5 ODL

class Artikel { ...

relationship Lieferant wirdGeliefertVon //one-Richtung inverse Lieferant::liefert;

}

class Lieferant extends Handelsbeteiligter { ...

relationship set <Artikel> liefert

//many-Richtung inverse Artikel::wirdGeliefertVon;

}

(15)

LE 15

29

8.5 ODL

▲

Signatur von Operationen

Ergebnistyp Operationsname(in Typ1 Par1, out Typ2 Par2,

inout Typ3 Par3,...) raises (Ausnahme1, Ausnahme2, ...) Angabe von void, wenn kein Ergebnistyp

Keine Spezifikation von Klassenoperationen in ODL Beispiel

class Artikel

{ void wechselnLieferant

(in Lieferant neuerLieferant) raises (gleicherLieferant);

...}

LE 15

30

8.5 ODL

class Artikel

( extent Artikelliste key Nummer)

{ attribute long Nummer;

attribute string Bezeichung;

attribute float Preis;

relationship Lieferant wirdGeliefertVon inverse Lieferant::liefert;

void erfassen() raises (schonVorhanden);

void wechselnLieferant(

in Lieferant neuerLieferant) raises (gleicherLieferant);

}

(16)

LE 15

31

8.5 ODL

class Handelsbeteiligter

{ struct AdresseT { string Strasse, string PLZ,

string Ort };

attribute AdresseT Adresse;

attribute string Telefon; }

class Kunde extends Handelsbeteiligter (extent Kunden)

{ attribute long Nummer;

attribute string Name;

attribute float Umsatz;

void erfassen() raises (schonVorhanden);

void erhoehenUmsatzUm(in float Erhoehung);}

LE 15

32

8.5 ODL

class Lieferant extends Handelsbeteiligter ( extent Lieferanten)

{ attribute string Firma;

attribute string Ansprechpartner;

relationship set <Artikel> liefert inverse Artikel::wirdGeliefertVon;

void erfassen() raises (schonVorhanden);

float teuersterArtikelpreis()

//ermittelt den Preis des teuersten //Artikels dieses Lieferanten

raises (liefertNichts);

}

▲

Aufgabe 3

(17)

LE 15

33

8.6 OQL

▲

OQL (Object Query Language)

Ermöglicht Anfragen an eine objektorientierte Datenbank

Baut auf dem select-from-where-Block von SQL2 auf

Kann als eigenständige, interaktive – aber nicht berechnungsvollständige – Datenbanksprache beutzt werden

Kann eingebettet in verschiedene Programmiersprachen benutzt werden

Verzicht auf das Geheimnisprinzip im Falle von ad hoc queries

LE 15

34

8.6 OQL

▲

Alle Objekte einer Klasse selektieren

Ermittlung der Menge aller Objekte einer Klasse ...

durch Angabe der Klassenextension oder

mittels einer select-Anfrage

Artikelliste

select a

from Artikelliste a

(18)

LE 15

35

8.6 OQL

▲

Einfache Anfragen

Formulierung analog zu SQL

OQL referenziert anstelle der Tabellen in SQL die Klassenextensionen

Verknüpfung mehrerer Bedingungen mittels and select a

where a.Bezeichnung = "S*"

select a

where a.Nummer >= 1000 and a.Nummer <= 1999

LE 15

36

8.6 OQL

select distinct a.Nummer from Artikelliste a

Ergebnis ist vom Typ set<long>

select distinct struct (Nr: a.Nummer, Bezeichnung: a.Bezeichnung) from Artikelliste a

Ergebnis ist vom Typ set<struct>

(19)

LE 15

37

8.6 OQL

▲

Zugriff in Struktur

OQL ermöglicht Zugriff innerhalb von Datenstrukturen

Verwendung des ».«-Operators select distinct struct

(Name: l.Ansprechpartner, Tel: l.Telefon) from Lieferanten l

where l.Adresse.Ort = "Dortmund"

Ergebnis ist vom Typ set<struct>

Filterung der Klassenextension Lieferantennach dem Ort Dortmund

Ortist eine Komponente des strukturierten Typs AdresseT– als Klasse realisiert – und wird über einen Pfadausdruck erreicht

LE 15

38

8.6 OQL

▲

Navigieren in OQL

Kein Unterschied in der Notation

beim Navigieren über die Objektverbindung oder

beim Zugriff innerhalb einer Struktur

▲

Beispiel

:Artikel :Lieferant

Adresse Ort wird

Geliefert Von

(20)

LE 15

39

8.6 OQL

▲

Beispiel

Alle Artikel, die von den Dortmunder Lieferanten geliefert werden

Ausgangspunkt: Objekt der Klasse Artikel

Navigation zu seinem (genau einem) Lieferanten

Zugriff in dem strukturierten Attribut Adresse auf den Ort

select a

from Artikelliste a, a.wirdGeliefertVon l where l.Adresse.Ort = "Dortmund"

LE 15

40

8.6 OQL

▲

Inverse Richtung der Assoziation

Alle Lieferanten, die einen Artikel mit der Bezeichnung »Diskette« liefern

select l

from Lieferanten l, l.liefert a where a.Bezeichnung = "Diskette"

:Lieferant :Artikel

:Artikel

:Artikel liefert

liefert

(21)

LE 15

41

8.6 OQL

▲

Operation in OQL

Aufruf einer Operation überall dort erlaubt, wo der Ergebnistyp der Operation möglich ist Beispiel

Preis des teuersten Artikels für alle Lieferanten in Dortmund

select l.teuersterArtikelpreis from Lieferanten l

Anhand der Notation hier nicht ersichtlich, ob es sich um

ein Attribut

einen Operationsaufruf oder

die Navigation einer Assoziation handelt

LE 15

42

8.6 OQL

▲

Nullwerte

Folgende Anfrage führt zu einem Laufzeitfehler, wenn für einen Lieferanten kein Ort eingetragen ist

select l.Adresse.Ort from Lieferanten l

Korrekte Anfrage bei möglichen Nullwerten ist select l.Adresse.Ort

from Lieferanten l

where is_defined (l.Adresse.Ort)

(22)

LE 15

43

8.6 OQL

▲

define

Erstellung vordefinierter Anfragen (named queries)

Ähnlich den Sichten bei relationalen DB Vordefinierten Anfragen können in der from-

Klausel von select-Anweisungen benutzt werden define DortmunderLieferanten() as

select l

from Lieferanten l

▲

Aufgabe 2

▲

Aufgabe 4 (Erweiterung von Aufgabe 3)

LE 15

44

8.7 Anbindung an C++

▲

C++ ODL

Klassen werden persistent durch

Ableitung von der Klasse d_Object Klassenextension: d_Extent<t>

Schlüssel: keine Realisierung Typen

Standardtypen von C++

Eigene Typen, z.B. d_Long, d_Float

Besitzen auf allen Plattformen denselben Wertebereich

Typ d_String für die Speicherung von Strings in der Datenbank

Deklaration der Attribute und Operationen wie in C++

(23)

LE 15

45

8.7 Anbindung an C++

▲

Assoziationen in C++ ODL

Spezifikation von Verbindungen zwischen Objekten als Objektreferenzen

Deklaration von Assoziationen

d_Rel_Ref <T, const char*>

d_Rel_Set <T, const char*>

d_Rel_List <T, const char*>

»T« ist eine persistente Klasse

Der zweite Parameter spezifiziert die inverse Richtung der Assoziation

LE 15

46

8.7 Anbindung an C++

▲

Beispiel

Spezifikation des folgenden Klassendiagramms

Lieferant Firma

Ansprechpartner

Artikel Nummer Bezeichnung Preis erfassen()

teuersterArtikelpreis() erfassen()

wechselnLieferant() wird

Geliefert Von

liefert

1 *

(24)

LE 15

47

8.7 Anbindung an C++

▲

Beispiel

extern const char _wirdGeliefertVon[], _liefert[];

class Lieferant: public d_Object {public:

d_String Firma;

d_String Ansprechpartner;

d_RelSet <Artikel, _wirdGeliefertVon>

liefert;

void erfassen();

d_Float teuersterArtikelpreis();

};

LE 15

48

8.7 Anbindung an C++

class Artikel: public d_Object {public:

d_Ulong Nummer;

d_String Bezeichnung;

d_Float Preis;

d_Rel_Ref <Lieferant, _liefert>

wirdGeliefertVon;

void erfassen();

void wechselnLieferant (Lieferant

&neuerLieferant); };

const char _wirdGeliefertVon[] =

"wirdGeliefertVon";

const char _liefert[] = "liefert";

(25)

LE 15

49

8.7 Anbindung an C++

▲

C++ OML

Grundlegendes Entwurfskonzept

Syntax zur Manipulation der persistenten und transienten Objekte soll sich möglichst wenig unterscheiden

Erzeugung neuer Objekte mit new()

Löschen von Objekten mittels delete_object()

Persistente Objekte werden nicht nur aus dem Speicher, sondern auch aus der Datenbank entfernt

Zugriff auf Objekte über ihre Objektreferenz Objektreferenzen sind Exemplare der

generischen Klasse d_Ref<T>

LE 15

50

8.7 Anbindung an C++

▲

C++ OML

Automatisches Laden aus der Datenbank, wenn ein referenziertes Objekt nicht im Speicher ist Objektreferenzen vergleichbar mit Zeigern in C++

Zusätzliche Mechanismen, um die referentielle Integrität der persistenten Objekte zu

gewährleisten

Intelligente Zeigern (smart pointers) Beispiel

Anlegen eines persistenten Objekts der Klasse Lieferant

d_Ref<Lieferant> lieferant;

lieferant = new (&database,

"Lieferant") Lieferant;

(26)

LE 15

51

8.7 Anbindung an C++

▲

Objektnamen in C++ OML

Ermöglichen bequemen Zugriff auf Objekte In einer Datenbank müssen alle Objektnamen

eindeutig sein

Operation set_object_name()weist dem jeweiligen Objekt einen Namen zu

Beispiel

database->set_object_name

(lieferant, "SuperBillig");

LE 15

52

8.7 Anbindung an C++

▲

Attribut in C++ OML

Zugriff auf Attribute in C++ OML wie in C++

d_Ref <Artikel> artikel;

cout << artikel->Bezeichnung;

In C++ ist erlaubt

Attribut eines Objekts kann selbst wieder ein Objekt sein, nicht nur die OID eines anderen Objekts, wie beim ODMG-Standard

Embedded objects

Besitzen nach dem ODMG-Standard keine eigene Objektidentität

Behandlung wie »einfache« Attribute

Kein Zugriff auf diese Objekte mittels d_Ref

(27)

LE 15

53

8.7 Anbindung an C++

▲

Operation in C++ OML

Verwendung wie in C++

Bei Änderung eines persistenten Objekts muß diese Änderung der Datenbank sichtbar gemacht Alle modifizierenden Operationen müssen

Operationsaufruf obj_ref->mark_modified() enthalten

LE 15

54

8.7 Anbindung an C++

▲

Assoziation in C++ OML

One-Richtung von Artikelzu Lieferant

Objekt einLieferant sei vorhanden

Objekt einArtikel erzeugen

Aufbauen der roten Verbindung zu einLieferant durch einArtikel.wirdGeliefertVon =

&einLieferant

Aufbauen der grünen Verbindung zu einArtikel automatisch

einLieferant liefert

...

einArtikel wirdGeliefertVon

(28)

LE 15

55

8.7 Anbindung an C++

Änderung des Lieferanten des Artikels

Lösen der roten Verbindung zu einLieferant einArtikel.wirdGeliefertVon.clear()

Inverse grüne Richtung wird automatisch entfernt Aufbau der Verbindung zu andererLieferant

einArtikel.wirdGeliefertVon =

&andererLieferant

ander erLieferant liefert

...

... einArtikel wirdGeliefertVon

LE 15

56

8.7 Anbindung an C++

many-Richtung von Lieferantzu Artikel

Aufbauen der roten Verbindung zu einArtikel durch

einLieferant.liefert.insert_element (&einArtikel)

Aufbauen der grünen Verbindung zu einLieferant automatisch

...

einArtikel wirdGeliefertVon

(29)

LE 15

57

8.7 Anbindung an C++

Änderung des Lieferanten des Artikels einLieferant.liefert.remove_element

(&einArtikel)

andererLieferant.liefert.insert_element (&einArtikel)

ander erLieferant liefert

...

... einArtikel wirdGeliefertVon

LE 15

58

8.7 Anbindung an C++

▲

Referentielle Integrität der Objektreferenzen

Sicherstellung automatisch durch das Datenbanksystem

Beim Aufbauen einer Objektverbindung wird die inverse Richtung automatisch durch das

Datenbanksystem erstellt

Beim Löschen eines Objekts, zu dem eine Verbindung besteht, entfernt das

Datenbanksystem automatisch die inverse Verbindung

(30)

LE 15

59

8.7 Anbindung an C++

▲

Lesen einer Kollektion

Zugriff auf einzelne Elemente einer Kollektion mit der generischen Klasse d_Iterator

Beispiel

Alle Objekte in der Klassenextension der Klasse Lieferant

d_Iterator <d_Ref<Lieferant>> iterator = Lieferanten.create_iterator();

d_Ref<Lieferant> l;

while (iterator.next(l))

{ l = iterator.get_element();

...

};

LE 15

60

8.7 Anbindung an C++

▲

Transaktion

Wichtiges Konzept von Datenbanksystemen Transaktion ist erfolgreich (commits)

Permanenter Eintrag aller im Rahmen der Transaktion durchgeführten Änderungen

Änderungen sind für alle anderen Benutzer sichtbar

Transaktion schlägt fehl (aborts)

Transaktion darf keinerlei Veränderungen in der Datenbank zur Folge haben

Rückgängig machen aller bereits im Rahmen der Transaktion durchgeführten

Verarbeitungen

(31)

LE 15

61

8.7 Anbindung an C++

▲

Beispiel C++ OML

Suchen eines Lieferanten nach Namen und Ausgeben der von ihm gelieferten Artikel d_Database database;

database.open("ArtikelLieferantenDB");

d_Transaction transaction;

transaction.begin();

d_Ref<Lieferant> lieferant;

lieferant=

database->lookup_object("SuperBillig");

d_Iterator <d_Ref<Artikel>> iterator;

d_Ref <Artikel> artikel;

LE 15

62

8.7 Anbindung an C++

iterator =

lieferant->liefert.create_iterator();

cout << "Lieferant" << lieferant->Firma

<< " liefert folgende Artikel "

<< endl;

while (iterator.next(artikel)) { cout << artikel->Nummer << " "

<< artikel->Bezeichnung

<< " " << artikel->Preis << endl;

}

transaction.commit();

database.close();

(32)

LE 15

63

8.7 Anbindung an C++

▲

C++ OQL

C++ OQL bildet die Semantik von OQL in C++ ab Klasse d_Collectionbesitzt eine query-

Operation mit folgender Signatur

int query (d_Collection<T> &result, const char* predicate) const;

Filterung einer Kollektion von Objekten, auf die das Prädikat angewendet wird

Ergebnis wird im ersten Parameter zurückgegeben

LE 15

64

8.8 Objekt-relationale Datenbanksysteme

▲

Objekt-relationale Datenbanksysteme

Verbindung der Vorteile der relationalen und der objektorientierten Welt

Grundlegendes Konzept: Tabelle SQL3 wird von ANSI und ISO genormt Wichtige objektorientierte Erweiterungen

Abstrakte Datentypen (ADTs)

Objektidentität

Definition von Operationen für ADTs

Überschreiben des Operationsnamens

Dynamisches Binden

ADT-Hierarchien

Tabellenhierarchien

(33)

LE 15

65

8.8 Objekt-relationale Datenbanksysteme

▲

ADT in SQL3

Kann definiert werden für

Objekte (Objekt-ADT – mit Objektidentität)

Werte (Wert-ADT – ohne Objektidentität) Erzeugung eines Surrogat-Attributs bei der

Definition eines Objekt-ADT

Erfüllt die Eigenschaften der Objektidentität Sichtbarkeiten

public

protected

private

LE 15

66

8.8 Objekt-relationale Datenbanksysteme

▲

Lese- und Schreib-Operation für jedes Attribut eines ADT

Observer-Operation

Ermöglicht den lesenden Zugriff Mutator-Operation

Ermöglicht Änderungen des Attributwertes

▲

Konstruktor und Destruktor für ADT

Konstruktor mit dem Namen des ADT Destruktor mit dem Namen destroy

(34)

LE 15

67

8.8 Objekt-relationale Datenbanksysteme

▲

Funktionen und Prozeduren

Prozeduren

Verändern Objekte oder Werte

Haben keinen Ergebniswert

Unterscheidung ihrer Parameter mit in,outund inout

Funktionen

Realisieren im allgemeinen Anfragen

Besitzen Ergebniswert

Dürfen nur in-Parameter besitzen

LE 15

68

8.8 Objekt-relationale Datenbanksysteme

▲

Beispiel

create type Artikel ( public

Nummer integer,

Bezeichnung char (30), Verkaufspreis real, Einkaufspreis real, ...

public function

ermittlePreisDifferenzVerkaufEinkauf (a Artikel) returns real begin

...

end )

(35)

LE 15

69

8.8 Objekt-relationale Datenbanksysteme

▲

ADT-Hierarchie

Definition eines spezialisierten ADT mit der under-Klausel

Der spezialisierte ADT kann auch Operationen des allgemeineren ADT überschreiben

Dynamisches Binden möglich Beispiel

create type Lieferant under Handelsbeteiligter (...)

LE 15

70

8.8 Objekt-relationale Datenbanksysteme

▲

Tabellenhierarchie

Bezieht sich auf die Extensionen (Tabellen) der beteiligten ADTs

Untertabellen enthalten alle Attribute der Obertabelle

Jede insert-Operation in der Untertabelle wirkt auch auf die Obertabelle

Jede delete-Operation in der Obertabelle wirkt auch auf die Untertabelle

Beispiel

create table Lieferanten of Lieferant under Handelsbeteiligte of

Handelsbeteiligter (...)

(36)

LE 15 71

▲

Danke!

▲

Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken des Lehrbuchs der

Objektmodellierung von Heide Balzert, Spektrum Akademischer Verlag 1999

LE 15

72

Aufgabe 1 (5 – 10 min)

▲

Grundbegriffe des ODMG-Objektmodells erläutern können

a. Literal und Objekt

b. Klasse (class) und Schnittstelle (interface) c. extends- und subtyping-Vererbung

▲

Lösung

(37)

LE 15

73

Aufgabe 2 (10 – 15 min)

▲

Assoziationen in ODL und Anfragen in OQL spezifizieren können

Erweitern Sie die Kunden-Lieferanten-Artikel- Verwaltung um folgende Assoziation: Ein Kunde kauft 1 bis viele Artikel. Ein Artikel kann von vielen Kunden gekauft werden. Dabei soll nicht festgehalten werden, ob ein bestimmter Artikel mehrmals vom gleichen Kunden gekauft wurde.

a. Ergänzen Sie die Spezifikation in ODL.

b. Formulieren Sie eine OQL-Anfrage, die den Namen und den Umsatz aller Kunden ausgibt, deren Umsatz größer als 10.000 ist.

c. Ermitteln Sie mittels OQL alle Kunden, die einen Artikel mit der Nummer 4711 gekauft haben.

▲

Lösung

LE 15

74

Aufgabe 3 (20 – 25 min)

▲

Klassendiagramme in ODL spezifizieren

1 *

EK-Preis Lieferfrist

Lagerartikel Mindestmenge Bestand

Artikel Nummer Bezeichnung VK-Preis

Lieferant Name

Adresse:AdresseT Telefon

Lieferkondition *

*

Bestellung Nummer Datum

Position Anzahl

1 *

AdresseT Strasse PLZ Ort

1..*

1

Lösung

(38)

LE 15

75

Aufgabe 4 (10 min)

▲

Anfragen in OQL spezifizieren können

Formulieren Sie für das Schema der Aufgabe 3 a. Erstellen einer Liste aller Lagerartikel, bei denen

der Mindestbestand unterschritten ist. Die Liste soll enthalten: Nummer, Bezeichnung, Bestand, Mindestmenge.

b. Für jeden Dortmunder Lieferanten ist eine Liste der ihm erteilten Bestellungen zu erstellen. Die Liste soll folgende Angaben enthalten: Lieferantenname, Bestelldatum.

▲

Lösung

LE 15

76

Lösung der Aufgabe 1

a. Literal: keine Objektidentität, kann nur als Komponente eines Objekts in der Datenbank gespeichert werden

Objekt: Objektidentität, kann daher für sich in der Datenbank gespeichert und wieder selektiert werden

b. Klasse: definiert Verhalten und Zustand von

Objekten, Klassenextension und Schlüssel können definiert werden

Schnittstelle: nur Verhalten, keine Objekte erzeugbar

c. Extends: Einfachvererbung zwischen zwei Klassen subtyping-Vererbung: Klassen und Schnittstellen können von Schnittstelle abgeleitet werden, auch Mehrfachvererbung

(39)

LE 15

77

Lösung der Aufgabe 2

Handelsbeteiligter Adresse

Telefon

erfassen()

erhoeheUmsatzUm() Nummer

Name Umsatz

Kunde

erfassen()

teuersterArtikelpreis() Firma

Ansprechpartner Lieferant

erfassen() wechselnLieferant() Nummer

Bezeichnung Preis

Artikel Kaeufer

*

1..*

Kauf

1wirdGeliefertVon liefert *

LE 15

78

Lösung der Aufgabe 2

a.

class Artikel ( ...

relationship Lieferant wirdGeliefertVon inverse Lieferant::liefert;

relationship set <Kunde> Kaeufer inverse Kunde::Kauf;

class Kunde: Handelsbeteiligter ...

relationship set <Artikel> Kauf inverse Artikel::Kaeufer;

(40)

LE 15

79

Lösung der Aufgabe 2

b. Name und Umsatz aller Kunden, deren Umsatz größer als 10.000 ist

select distinct struct (Name: k.Name, Umsatz: k.Umsatz) from Kunden k

where k.Umsatz > 10000

c. Alle Kunden, die einen Artikel mit der Nummer 4711 gekauft haben

select k

from Kunden k, k.Kauf a where a.Nummer = 4711

LE 15

80

Lösung der Aufgabe 3

Lagerartikel Mindestmenge Bestand

Nummer Bezeichnung VKPreis

Artikel EKPreis Lieferfrist

hat gehoert 1

* Lieferkondition Name

Adresse Telefon

wirdGebotenVon

* Lieferant

bietet 1

Strasse PLZ Ort

AdresseT Anzahl

Position Nummer Datum

Bestellung

1..*

1 erteilt

wird ErteiltVon

1 *

bestellterArtikel 1

Bestellposition

*

(41)

LE 15

81

Lösung der Aufgabe 3

class Artikel

( extent Artikelliste key Nummer)

{ attribute long Nummer;

attribute string Bezeichung;

attribute float VKPreis;

relationship set <Lieferkondition> hat inverse Lieferkondition::gehoert;

relationship set <Position>

Bestellposition

inverse Position::bestellterArtikel;

}

LE 15

82

Lösung der Aufgabe 3

class Lagerartikel extends Artikel ( extent Lagerartikelliste

key Nummer)

{ attribute long Mindestmenge;

attribute long Bestand;

}

class Lieferant

( extent Lieferanten)

{ struct AdresseT { string Strasse, string PLZ, string Ort };

attribute string Name;

attribute AdresseT Adresse;

attribute string Telefon;

(42)

LE 15

83

Lösung der Aufgabe 3

relationship set <Lieferkondition> bietet inverse Lieferkondition::wirdGebotenVon;

relationship set <Bestellung> erteilt inverse Bestellung::wirdErteiltVon;

}

class Lieferkondition

(extent Lieferkonditionen) { attribute float EKPreis;

attribute long Lieferfrist;

relationship Lieferant wirdGebotenVon inverse Lieferant::bietet;

relationship Artikel gehoert inverse Artikel::hat;

}

LE 15

84

Lösung der Aufgabe 3

class Bestellung

( extent Bestellungen key Nummer)

{ attribute long Nummer;

attribute date Datum;

relationship Lieferant wirdErteiltVon inverse Lieferant::erteilt;

relationship set <Position> enthaelt inverse Position::istTeilVon;

}

(43)

LE 15

85

Lösung der Aufgabe 3

class Position

( extent Positionen) { attribute long Anzahl;

relationship Bestellung istTeilVon inverse Bestellung::enthaelt;

relationship Bestellung bestellterArtikel inverse Artikel::Bestellposition;

}

LE 15

86

Lösung der Aufgabe 4

a.

select la.Nummer, la.Bezeichnung, la.Bestand, la.Mindestmenge from Lagerartikelliste la

where la.Bestand < la.Mindestmenge b.

select distinct struct (Lieferantenname:

l.Name, erteilteBestellungen:

(select b from l.erteilt as b)) from Lieferanten l