128
1 Teil I Teil I Datenmodelle Datenmodelle Kapitel 9: Transformationen

1 Teil I Datenmodelle Kapitel 9: Transformationen

Embed Size (px)

Citation preview

Page 1: 1 Teil I Datenmodelle Kapitel 9: Transformationen

1

Teil ITeil I

DatenmodelleDatenmodelle

Kapitel 9: Transformationen

Page 2: 1 Teil I Datenmodelle Kapitel 9: Transformationen

2

Kapitel 9.1: Einführung

Page 3: 1 Teil I Datenmodelle Kapitel 9: Transformationen

3

Vier-Stufen-Architektur

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Page 4: 1 Teil I Datenmodelle Kapitel 9: Transformationen

4

Problemstellungen (1)

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Datenbasen sind oft riesig. Eine Anwendung interessiert sich aber meist nur für einen kleinen Teil der Daten bzw. darf nur auf bestimmte Daten zugreifen.

Es wird nur ein Ausschnitt verfügbar gemacht.

Page 5: 1 Teil I Datenmodelle Kapitel 9: Transformationen

5

Problemstellungen (2)

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Die Anwendung wünscht sich oft eine problemangepasstere Struktur ihres Ausschnitts für einen bequemeren Zugriff.

Der Ausschnitt wird umstrukturiert.

Page 6: 1 Teil I Datenmodelle Kapitel 9: Transformationen

6

Beispiel: Zugriffsbeschränkung

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);

relation LagerhilfsmittelArt(LhaNr, LhaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerort(LoNr, LoaNr, Gewicht);

relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);

relation Verträglichkeit(ANr, LoNr);

Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);

relation LagerhilfsmittelArt(LhaNr, LhaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerort(LoNr, LoaNr, Gewicht);

relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);

relation Verträglichkeit(ANr, LoNr);

Zulieferer: Liefern in Lagereinheiten verpackte Artikel, die gelagert und später weiterverkauft werden. Erste Zulieferergruppe:

relation EigenerArtikel(ANr, AName, Menge, Gewicht);

relation Liefereinheit(LeNr, ANr, Stückzahl, Gewicht); Zweite Zulieferergruppe:

relation VerpacktIn(AName, Menge, AGewicht, LeNr, Stückzahl, LeGewicht);

Zulieferer: Liefern in Lagereinheiten verpackte Artikel, die gelagert und später weiterverkauft werden. Erste Zulieferergruppe:

relation EigenerArtikel(ANr, AName, Menge, Gewicht);

relation Liefereinheit(LeNr, ANr, Stückzahl, Gewicht); Zweite Zulieferergruppe:

relation VerpacktIn(AName, Menge, AGewicht, LeNr, Stückzahl, LeGewicht);

Page 7: 1 Teil I Datenmodelle Kapitel 9: Transformationen

7

Problemstellungen (3)

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Jeder Dienstgeber will in der Wahl seines Datenmodells frei (autonom) sein.

Die Umstrukturierung kann Abbildungen zwischen Datenmodellen beinhalten.

relational

objektorientiert

XML

Page 8: 1 Teil I Datenmodelle Kapitel 9: Transformationen

8

Beispiel: Java 2 Enterprise Edition

Dienstnehmer-Behälter

Transaktionsdienst

Ressourcen-Verwalter

Kommunikation(HTTP, IIOP, RMI, JDBC)

Persistenzdienst

JAF

JND

I

JDB

C

JTA

J2SE

JMS WWW-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Java

Ser

vlet

s

Java

Ser

ver

Page

s

EJB-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Ent

erpr

ise

Java

Bea

n

Ent

erpr

ise

Java

Bea

n

Fremd-Behälter

Applet-Behälter

J2SE

RessourcenDatenlogik

GeschäftsprozessAnwendungs-Dienstgeber

PräsentationWWW-Dienstgeber

AnwenderDienstnehmer

Konnektor

RMI-IIOP

HTTP

HTTP

RMI-IIOP

JDBC

NamensdienstSicherheitsdienst Nachrichtendienst

JDBC

Page 9: 1 Teil I Datenmodelle Kapitel 9: Transformationen

9

Problemstellungen (4)

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Mitunter wollen Dienstgeber ihre Daten mit fallweise wählbaren, Dienstgebern, u.a. Datenbanksystemen, austauschen.

Die Umstrukturierung kann Abbildungen zwischen Datenmodellen unter Zwischenschalten eines neutralen Datenmodells beinhalten.

XML

Page 10: 1 Teil I Datenmodelle Kapitel 9: Transformationen

10

Beispiel: Austausch von Daten

Anwendungs-Dienstgeber

Anwendungs-Dienstgeber

. . .

. . .

Middleware

Dienstnehmer Dienstnehmer Dienstnehmer

Datenbank-Dienstgeber

andere Dienstgeber

. . .Ressourcen

WWW-Dienstgeber

WWW-Dienstgeber

. . .

Geschäftsprozess

Präsentation

Anwender

Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

Kunde: Arbeitet mit ArtikelArt-Objekten

Kunde: Arbeitet mit ArtikelArt-Objekten

<artikelliste><artikelart>

<nummer> A001 </nummer><name> Anlasser </name>

<menge> 1 </menge> <lieferant> Bosch </lieferant><gewicht> 2,00 </gewicht>

</artikelart> …</artikelliste>

<artikelliste><artikelart>

<nummer> A001 </nummer><name> Anlasser </name>

<menge> 1 </menge> <lieferant> Bosch </lieferant><gewicht> 2,00 </gewicht>

</artikelart> …</artikelliste>

Export Import

Page 11: 1 Teil I Datenmodelle Kapitel 9: Transformationen

11

Grundprinzip der Transformation

Ausschnitt

z.B. Anwendungs-Db ADB

Abbildung v

AnwendungAnwendungsschema AS

v‘

WeitereAnwendung

Quellschema Sz.B. für Datenbasis DB

Sicht: Bedarfsweise Ausführung

Sicht-DB: Virtuelle Datenbasis

Materialisierung: Einmalige (Vorab-) Ausführung

Materialisierte Sicht: Replizierter Ausschnitt

Page 12: 1 Teil I Datenmodelle Kapitel 9: Transformationen

12

SichtenSichten: Gegeben sei ein Schema S und eine zugehörige

Datenbasis DB. Jede Sicht hierauf ist durch ein weiteres Schema AS, ggf. in

einem anderen Datenmodell, und eine partielle Abbildung v (= View) definiert.

Hierbei legt v die Abbildung von Datenelementen aus DB nach ADB fest mit einer durch die Schemata bestimmten Strukturtransformation.

Für einen auf AS arbeitenden Nutzer sieht es so aus, als würde eine dem Schema AS gehorchende Datenbasis ADB real existieren ((virtuelle) Sicht).

Transformation: Tatsächlich erzeugt v aus den Daten aus DB für die Dauer der

Abfrage eine transiente Kopie. Änderungen erfolgen daher ausschließlich in DB.

Page 13: 1 Teil I Datenmodelle Kapitel 9: Transformationen

13

Materialisierung

Materialisierung:

Bei komplexen Sichtabbildungen v kann das Berechnen der Datenelemente in ADB bei einem Zugriff zu lange dauern.

Die Datenbasis ADB wird materialisiert, d.h. die dort vorkommenden Datenelemente werden real erzeugt.

Hierbei legt v die Abbildung von Datenelementen aus DB nach ADB fest mit einer durch die Schemata bestimmten Strukturtransformation (materialisierte Sicht).

Transformation:

v erzeugt aus den Daten aus DB eine dauerhafte Kopie.

Bei Datenänderungen sind sowohl DB als auch die betroffenen Daten in ADB anzupassen (Problem der Redundanz!).

Page 14: 1 Teil I Datenmodelle Kapitel 9: Transformationen

14

Abgeschlossenheit des Sichtschemas Zwei Schemaelemente

stehen in S in Beziehung zueinander.

Eines der Element wird in die Sicht übernommen, das andere nicht. Die Beziehung verweist in AS ins Leere…

?

vNicht erlaubt

Abbildungen, bei denen im Sichtschema undefinierte Elemente verwendet werden, sind nicht erlaubt.

Forderung: Das Sichtschema muss in sich abgeschlossen sein.

S

AS

Page 15: 1 Teil I Datenmodelle Kapitel 9: Transformationen

15

Datenzugriffe über Sicht Die Originaldatenbasis DB macht sich dem

Benutzer als Sicht ADB := v(DB) bemerkbar.

Bearbeitet der Benutzer einige Daten seiner Sicht mittels einer Operation o, so entsteht ADB' := o(ADB).

Tatsächlich müssen diese Bearbeitungsschritte aber im Original durchgeführt werden, da nur hier die Daten real existieren.

Das Äquivalent von o ist dort im Allgemeinen eine Folge von Operationen p, die einen neuen Zustand DB' := p(DB) bewirkt.

Nach Abschluss der Operationen muss natürlich gelten:

ADB' = v(DB')so dass es für den Nutzer aussieht, als wäre o ausgeführt worden.

ADB ADB'o

p

vv

DB DB'

DB

ADB

v

Page 16: 1 Teil I Datenmodelle Kapitel 9: Transformationen

16

Informationserhaltung in Sichten

Die Abbildung v heißt informationserhaltend, wenn es für alle Zustände einer Datenbasis DB und jede Operation o eines Benutzers auf v(DB) stets eine Operationsfolge p gibt, so dass gilt:

o(v(DB)) = v(p(DB)).

ADB ADB'

DB DB'

Zustände der Sicht-Datenbasis

Datenmodell: ADM

Zustände der Original-Datenbasis

Datenmodell: DM

o

p

vv

Page 17: 1 Teil I Datenmodelle Kapitel 9: Transformationen

17

Datenändernde Zugriffe

Der Nutzer nimmt auf der Sicht ADB Datenänderungen o vor, so dass sich als neuer Zustand der Sichtdatenbasis ADB' ergibt.

Dazu passend müssen die Änderungen p auf der Originaldatenbasis ausgeführt werden. Hierbei ist nicht immer garantiert, … … dass p eindeutig bestimmbar ist. … dass überhaupt ein p existiert.

Datenänderungen o, zu denen es kein p mit o(v(DB)) = v(p(DB)) gibt, sind nicht durchführbar.

} View-update problem

ADB ADB'

DB DB'

o

p

vv

=

v(DB‘)?

Informationserhaltung beim Lesen trivial gegeben wegen o = p = id.

Page 18: 1 Teil I Datenmodelle Kapitel 9: Transformationen

18

Leseoperationen

Seien DB' und ADB' gelesene Ausschnitte. Übliches Lesen: o(v(DB))

Der Nutzer der Sicht liest zunächst mittels v aus DB. Dann liest er das Zwischenergebnis mit eigenem Operator o.

Selten: Das Lesen wird an DB delegiert. Folglich ist p Operationsfolge für Leseoperation o. Es muss dann ebenfalls gelten:

o(v(DB)) = v(p(DB)).

ADB ADB'

DB DB'

o

p

vv

=

v(DB‘)?

Page 19: 1 Teil I Datenmodelle Kapitel 9: Transformationen

19

Kapitel 9.2: Sichten im relationalen Modell

Page 20: 1 Teil I Datenmodelle Kapitel 9: Transformationen

20

Charakterisierung Der Benutzer kann in seiner Sicht ausschließlich auf

Relationen operieren, ebenso wie die Originaldatenbasis ausschließlich Relationen enthält.

Begriffe: Die virtuellen Relationen heißen Sichtrelation oder kurz Sicht

(view). Nicht-Sichtrelationen heißen Basisrelationen.

v ist somit eine Abbildung der Form

v: (R) (R),

mit R die Menge aller (beliebig-stelligen) Relationen. R darf bereits definierte Sichten einschließen. v lässt sich relationenalgebraisch ausdrücken.

Page 21: 1 Teil I Datenmodelle Kapitel 9: Transformationen

21

Illustration

Beispiel: Benutzergruppen für Lagerverwaltung: Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);

relation LagerhilfsmittelArt(LhaNr, LhaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerort(LoNr, LoaNr, Gewicht);

relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);

relation Verträglichkeit(ANr, LoNr);

Lagermanagement: Arbeitet mit dem vollständigen Datenbestand.

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);

relation LagerhilfsmittelArt(LhaNr, LhaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerort(LoNr, LoaNr, Gewicht);

relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);

relation Verträglichkeit(ANr, LoNr);

Zulieferer: Liefern in Lagereinheiten verpackte Artikel, die gelagert und später weiterverkauft werden. Erste Zulieferergruppe:

relation EigenerArtikel(ANr, AName, Menge, Gewicht);

relation Liefereinheit(LeNr, ANr, Stückzahl, Gewicht); Zweite Zulieferergruppe:

relation VerpacktIn(AName, Menge, AGewicht, LeNr, Stückzahl, LeGewicht);

Zulieferer: Liefern in Lagereinheiten verpackte Artikel, die gelagert und später weiterverkauft werden. Erste Zulieferergruppe:

relation EigenerArtikel(ANr, AName, Menge, Gewicht);

relation Liefereinheit(LeNr, ANr, Stückzahl, Gewicht); Zweite Zulieferergruppe:

relation VerpacktIn(AName, Menge, AGewicht, LeNr, Stückzahl, LeGewicht);

EigenerArtikel := ANr,Aname,Menge,Gewicht(Lieferant=‘Siemens’(ArtikelArt))

Liefereinheit := ANr(Lieferant=‘Siemens’(ArtikelArt)) ⋈ LeNr,ANr,Stückzahl,Gewicht(Lagereinheit)

VerpacktIn := AName,Menge,AGewicht,LeNr,Stückzahl,LeGewicht

(Lieferant=‘Bosch’(ArtikelArtAGewichtGewicht) ⋈ LagereinheitLeGewichtGewicht

Page 22: 1 Teil I Datenmodelle Kapitel 9: Transformationen

22

Beispielsichten (1)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentilfedernZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderkopfZylinderkurbelgehäuse

ANameAName(ArtikelArt)

Page 23: 1 Teil I Datenmodelle Kapitel 9: Transformationen

23

Beispielsichten (2)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

ANameANr

ANr,AName(ArtikelArt)

Page 24: 1 Teil I Datenmodelle Kapitel 9: Transformationen

24

Beispielsichten (3)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

0.800.802.50

SiemensSiemensSiemens

1010

5

ZündkerzenkabelZündkerzensteckerZündspule

A013A014A015

Gewicht LieferantMengeANameANr

Lieferant='Siemens'(ArtikelArt)

Page 25: 1 Teil I Datenmodelle Kapitel 9: Transformationen

25

Beispielsichten (4)

LH-002

LH-002

LH-002

LH-006

LH-004

LH-007

LH-006

LH-003

LH-003

LH-007

LH-005

LH-003

LH-005

LH-001

LH-004

LH-005

4.00

20.00

21.00

175.00

4.50

0.30

212.50

15.00

6.00

5.20

16.00

12.00

12.00

2.00

3.00

105.00

2

20

42

175

3

6

85

30

1

13

16

4

12

1

2

42

A-001

A-004

A-005

A-017

A-006

A-002

A-015

A-010

A-020

A-008

A-011

A-019

A-012

A-001

A-006

A-015

LEA-04

LEA-02

LEA-01

LEA-05

LEA-02

LEA-03

LEA-05

LEA-01

LEA-02

LEA-04

LEA-01

LEA-02

LEA-01

LEA-04

LEA-02

LEA-02

LE-001

LE-002

LE-003

LE-004

LE-005

LE-006

LE-007

LE-008

LE-009

LE-010

LE-011

LE-012

LE-013

LE-014

LE-015

LE-016

LhNrGewichtStückzahlANrLeaNrLeNr

Lagereinheit

LH-006

LH-006

LH-005

175.00

212.50

105.00

175

85

42

A-017

A-015

A-015

LEA-05

LEA-05

LEA-02

LE-004

LE-007

LE-016

LhNrGewichtStückzahlANrLeaNrLeNr

Gewicht>100.0(Lagereinheit)

Page 26: 1 Teil I Datenmodelle Kapitel 9: Transformationen

26

Beispielsichten (5)ArtikelArt ⋈ LagereinheitLeGewichtGewicht

1

1

1

1

1

1

1

20

50

20

20

5

5

10

1

1

Lieferant

LEA-04

LEA-04

LEA-03

LEA-02

LEA-01

LEA-02

LEA-02

LEA-04

LEA-01

LEA-01

LEA-01

LEA-05

LEA-02

LEA-05

LEA-02

LEA-02

LE-001

LE-014

LE-006

LE-002

LE-003

LE-005

LE-015

LE-010

LE-008

LE-011

LE-013

LE-007

LE-016

LE-004

LE-012

LE-009

Anlasser

Anlasser

Kolben

Kurbelwelle

Nockenwelle

Ölwanne

Ölwanne

Ventile

Ventilfedern

Zündkerzen

Zündkerzen

Zündspule

Zündspule

Zylinderdichtung

Zylinderkopf

Zylinderkurbelgehäuse

A-001

A-001

A-002

A-004

A-005

A-006

A-006

A-008

A-010

A-011

A-012

A-015

A-015

A-017

A-019

A-020

LeaNrLeNrANameANr Menge

Bosch

Bosch

Mahle

Mahle

Mahle

Erzberg

Erzberg

Mahle

Pohlmann

Bosch

Osram

Siemens

Siemens

Erzberg

Mahle

Erzberg

Gewicht

2.00

2.00

0.05

1.00

0.50

1.50

1.50

0.40

0.50

1.00

1.00

2.50

2.50

1.00

3.00

6.00

2

1

6

20

42

3

2

13

30

16

12

85

42

175

4

1

Stückzahl

4.00

2.00

0.30

20.00

21.00

4.50

3.00

5.20

15.00

16.00

12.00

212.50

105.00

175.00

12.00

6.00

LeGewicht

LH-001

LH-001

LH-007

LH-002

LH-002

LH-004

LH-004

LH-007

LH-003

LH-005

LH-005

LH-006

LH-005

LH-006

LH-003

LH-003

LhNr

Page 27: 1 Teil I Datenmodelle Kapitel 9: Transformationen

27

Beispielsichten (6)

Lagereinheit ⋈GewichtMaxGewicht LagerhilfsmittelArt

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

500.00

500.00

350.00

300.00

200.00

150.00

100

100

115

150

150

100

800

800

600

400

400

400

1200

1000

800

600

600

600

Holzpalette

Holzpalette

Leichte Holzpalette

Displaypalette

Displaypalette

Displaypalette

LHA-01

LHA-02

LHA-03

LHA-04

LHA-05

LHA-06

MaxGewicht HöheBreiteLängeLhaNameLhaNr

LagerhilfsmittelArt

LH-002

LH-002

LH-002

LH-006

LH-004

LH-007

LH-006

LH-003

LH-003

LH-007

LH-005

LH-003

LH-005

LH-001

LH-004

LH-005

4.00

20.00

21.00

175.00

4.50

0.30

212.50

15.00

6.00

5.20

16.00

12.00

12.00

2.00

3.00

105.00

2

20

42

175

3

6

85

30

1

13

16

4

12

1

2

42

A-001

A-004

A-005

A-017

A-006

A-002

A-015

A-010

A-020

A-008

A-011

A-019

A-012

A-001

A-006

A-015

LEA-04

LEA-02

LEA-01

LEA-05

LEA-02

LEA-03

LEA-05

LEA-01

LEA-02

LEA-04

LEA-01

LEA-02

LEA-01

LEA-04

LEA-02

LEA-02

LE-001

LE-002

LE-003

LE-004

LE-005

LE-006

LE-007

LE-008

LE-009

LE-010

LE-011

LE-012

LE-013

LE-014

LE-015

LE-016

LhNrGewichtStückzahlANrLeaNrLeNr

Lagereinheit

Welche Art von Lagerhilfsmitteln ist zu meiden?

Page 28: 1 Teil I Datenmodelle Kapitel 9: Transformationen

28

Löschoperationen (1)ADB ADB'

DB DB'

o = lösche(aname)

p??

vv = AName(ArtikelArt)

Löschen entspricht der relationenalgebraischen Differenz. Dann ergibt sich durch Einsetzen in die Informationserhaltungs-Regel die Forderung

AName(ArtikelArt) \ {(aname)} = AName(p(ArtikelArt))

und somit

p(ArtikelArt) = ArtikelArt \ {(w, aname, x, y, z)}. Fragestellung: Wie sind w, x, y und z richtig auszufüllen?

Page 29: 1 Teil I Datenmodelle Kapitel 9: Transformationen

29

Löschoperationen (1)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentilfedernZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderkopfZylinderkurbelgehäuse

ANameAName(ArtikelArt)

Sei aname = 'Zündkerzen‘ In ArtikelArt gar kein eindeutiges Tupel, das zu löschen wäre! Daher: Alle Tupel mit aname = 'Zündkerzen‘ aus der Originalrelation

löschen. Ansonsten verschwände 'Zündkerzen' nicht aus der Sicht.

Page 30: 1 Teil I Datenmodelle Kapitel 9: Transformationen

30

Löschoperationen (2)ADB ADB'

DB DB'

o = lösche(anr,aname)

p??

vv = ANr,AName(ArtikelArt)

Es ergibt sich die Forderung

ANr,AName (ArtikelArt) \ {(anr, aname)} = ANr,AName (p(ArtikelArt))

und somit

p(ArtikelArt) = ArtikelArt \ {(anr, aname, x, y, z)}.

Page 31: 1 Teil I Datenmodelle Kapitel 9: Transformationen

31

Löschoperationen (2)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

ANameANr

ANr,AName(ArtikelArt)

Ausfüllen eindeutig, da das Schlüsselattribut der Originalrelation in der Sicht vorhanden ist.

(Beispiel: anr = 'A-001')

Page 32: 1 Teil I Datenmodelle Kapitel 9: Transformationen

32

Löschoperationen (3)ADB ADB'

DB DB'

o = lösche(anr,aname,menge,lieferant,gewicht)

p??

vv = Lieferant='Siemens'(ArtikelArt)

Forderung:

Lieferant='Siemens' (ArtikelArt) \ {(anr, aname, menge, lieferant, gewicht)}

= Lieferant='Siemens' (p(ArtikelArt)) Für p ergibt sich:

p(ArtikelArt) = ArtikelArt \ {(anr, aname, menge, lieferant, gewicht)}

Page 33: 1 Teil I Datenmodelle Kapitel 9: Transformationen

33

Löschoperationen (3)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameANr

ArtikelArt

0.800.802.50

SiemensSiemensSiemens

1010

5

ZündkerzenkabelZündkerzensteckerZündspule

A013A014A015

Gewicht LieferantMengeANameANr

Lieferant='Siemens'(ArtikelArt)

Keine Probleme, da das Schlüsselattribut der Originalrelation in der Sicht vorhanden ist.

Page 34: 1 Teil I Datenmodelle Kapitel 9: Transformationen

34

Löschoperationen (4)ADB ADB'

DB DB'

o = lösche(lenr,leanr,anr,stückzahl,gewicht,lhnr)

p??

vv = Gewicht>100.0(Lagereinheit)

Forderung:

Gewicht>100.0 (Lagereinheit) \ {(lenr,leanr,anr,stückzahl,gewicht,lhnr)}

= Gewicht>100.0 (p(Lagereinheit)) Für p ergibt sich:

p(Lagereinheit) = Lagereinheit \ {(lenr,leanr,anr,stückzahl,gewicht,lhnr)}

Page 35: 1 Teil I Datenmodelle Kapitel 9: Transformationen

35

Löschoperationen (4)

LH-002

LH-002

LH-002

LH-006

LH-004

LH-007

LH-006

LH-003

LH-003

LH-007

LH-005

LH-003

LH-005

LH-001

LH-004

LH-005

4.00

20.00

21.00

175.00

4.50

0.30

212.50

15.00

6.00

5.20

16.00

12.00

12.00

2.00

3.00

105.00

2

20

42

175

3

6

85

30

1

13

16

4

12

1

2

42

A-001

A-004

A-005

A-017

A-006

A-002

A-015

A-010

A-020

A-008

A-011

A-019

A-012

A-001

A-006

A-015

LEA-04

LEA-02

LEA-01

LEA-05

LEA-02

LEA-03

LEA-05

LEA-01

LEA-02

LEA-04

LEA-01

LEA-02

LEA-01

LEA-04

LEA-02

LEA-02

LE-001

LE-002

LE-003

LE-004

LE-005

LE-006

LE-007

LE-008

LE-009

LE-010

LE-011

LE-012

LE-013

LE-014

LE-015

LE-016

LhNrGewichtStückzahlANrLeaNrLeNr

Lagereinheit

LH-006

LH-006

LH-005

175.00

212.50

105.00

175

85

42

A-017

A-015

A-015

LEA-05

LEA-05

LEA-02

LE-004

LE-007

LE-016

LhNrGewichtStückzahlANrLeaNrLeNr

Gewicht>100.0(Lagereinheit)

Keine Probleme, da das Schlüsselattribut der Originalrelation in der Sicht vorhanden ist.

Selektion ist bei Löschoperationen ein für die Informationserhaltung unkritischer Operator.

Page 36: 1 Teil I Datenmodelle Kapitel 9: Transformationen

36

Löschoperationen (5)ADB ADB'

DB DB'

o = lösche(anr,lenr)

p??

vv = ArtikelArt ⋈ LagereinheitLeGewichtGewicht

Forderung:

ArtikelArt ⋈ LagereinheitLeGewichtGewicht \ {(anr,lenr)}

= p1(ArtikelArt) ⋈ p2(Lagereinheit)

mit p also Folge aus p1 und p2 ((anr,lenr) ist Schlüssel). Erster Versuch:

- p1(ArtikelArt) = ArtikelArt \ {(anr)}

- p2(Lagereinheit) = Lagereinheit \ {(lenr)}

Page 37: 1 Teil I Datenmodelle Kapitel 9: Transformationen

37

Löschoperationen (5)ArtikelArt ⋈ LagereinheitLeGewichtGewicht

1

1

1

1

1

1

1

20

50

20

20

5

5

10

1

1

Lieferant

LEA-04

LEA-04

LEA-03

LEA-02

LEA-01

LEA-02

LEA-02

LEA-04

LEA-01

LEA-01

LEA-01

LEA-05

LEA-02

LEA-05

LEA-02

LEA-02

LE-001

LE-014

LE-006

LE-002

LE-003

LE-005

LE-015

LE-010

LE-008

LE-011

LE-013

LE-007

LE-016

LE-004

LE-012

LE-009

Anlasser

Anlasser

Kolben

Kurbelwelle

Nockenwelle

Ölwanne

Ölwanne

Ventile

Ventilfedern

Zündkerzen

Zündkerzen

Zündspule

Zündspule

Zylinderdichtung

Zylinderkopf

Zylinderkurbelgehäuse

A-001

A-001

A-002

A-004

A-005

A-006

A-006

A-008

A-010

A-011

A-012

A-015

A-015

A-017

A-019

A-020

LeaNrLeNrANameANr Menge

Bosch

Bosch

Mahle

Mahle

Mahle

Erzberg

Erzberg

Mahle

Pohlmann

Bosch

Osram

Siemens

Siemens

Erzberg

Mahle

Erzberg

Gewicht

2.00

2.00

0.05

1.00

0.50

1.50

1.50

0.40

0.50

1.00

1.00

2.50

2.50

1.00

3.00

6.00

2

1

6

20

42

3

2

13

30

16

12

85

42

175

4

1

Stückzahl

4.00

2.00

0.30

20.00

21.00

4.50

3.00

5.20

15.00

16.00

12.00

212.50

105.00

175.00

12.00

6.00

LeGewicht

LH-001

LH-001

LH-007

LH-002

LH-002

LH-004

LH-004

LH-007

LH-003

LH-005

LH-005

LH-006

LH-005

LH-006

LH-003

LH-003

LhNr

Beispiel: anr = 'A-001‘, lenr = ‘LE-001‘

Page 38: 1 Teil I Datenmodelle Kapitel 9: Transformationen

38

Löschoperationen (5)ADB ADB'

DB DB'

o = lösche(anr,lenr)

p??

vv = ArtikelArt ⋈ LagereinheitLeGewichtGewicht

Forderung:

ArtikelArt ⋈ LagereinheitLeGewichtGewicht \ {(anr,lenr)}

= p1(ArtikelArt) ⋈ p2(Lagereinheit)

mit p also Folge aus p1 und p2 ((anr,lenr) ist Schlüssel). Zweiter Versuch:

- p1(ArtikelArt) = ArtikelArt

- p2(Lagereinheit) = Lagereinheit \ {(lenr)}

Page 39: 1 Teil I Datenmodelle Kapitel 9: Transformationen

39

Löschoperationen (5)ArtikelArt ⋈ LagereinheitLeGewichtGewicht

1

1

1

1

1

1

1

20

50

20

20

5

5

10

1

1

Lieferant

LEA-04

LEA-04

LEA-03

LEA-02

LEA-01

LEA-02

LEA-02

LEA-04

LEA-01

LEA-01

LEA-01

LEA-05

LEA-02

LEA-05

LEA-02

LEA-02

LE-001

LE-014

LE-006

LE-002

LE-003

LE-005

LE-015

LE-010

LE-008

LE-011

LE-013

LE-007

LE-016

LE-004

LE-012

LE-009

Anlasser

Anlasser

Kolben

Kurbelwelle

Nockenwelle

Ölwanne

Ölwanne

Ventile

Ventilfedern

Zündkerzen

Zündkerzen

Zündspule

Zündspule

Zylinderdichtung

Zylinderkopf

Zylinderkurbelgehäuse

A-001

A-001

A-002

A-004

A-005

A-006

A-006

A-008

A-010

A-011

A-012

A-015

A-015

A-017

A-019

A-020

LeaNrLeNrANameANr Menge

Bosch

Bosch

Mahle

Mahle

Mahle

Erzberg

Erzberg

Mahle

Pohlmann

Bosch

Osram

Siemens

Siemens

Erzberg

Mahle

Erzberg

Gewicht

2.00

2.00

0.05

1.00

0.50

1.50

1.50

0.40

0.50

1.00

1.00

2.50

2.50

1.00

3.00

6.00

2

1

6

20

42

3

2

13

30

16

12

85

42

175

4

1

Stückzahl

4.00

2.00

0.30

20.00

21.00

4.50

3.00

5.20

15.00

16.00

12.00

212.50

105.00

175.00

12.00

6.00

LeGewicht

LH-001

LH-001

LH-007

LH-002

LH-002

LH-004

LH-004

LH-007

LH-003

LH-005

LH-005

LH-006

LH-005

LH-006

LH-003

LH-003

LhNr

Beispiel: anr = 'A-001‘, lenr = ‘LE-001‘

Erklärung: Referenzielle Konsistenz von ANr in Lagereinheit bezüglich ArtikelArt im ersten Fall verletzt, im zweiten nicht.

Page 40: 1 Teil I Datenmodelle Kapitel 9: Transformationen

40

Löschoperationen (6)ADB ADB'

DB DB'

o = lösche(lenr,...,gewicht,lhnr,lhanr,...,maxgewicht)

p??

vv = Lagereinheit ⋈GewichtMaxGewichtLagerhilfsmittelArt

Forderung:

Lagereinheit ⋈GewichtMaxGewicht LagerhilfsmittelArt \ {(lenr,...,gewicht,lhnr,lhanr,...,maxgewicht)}

= p1(Lagereinheit) ⋈GewichtMaxGewicht p2(LagerhilfsmittelArt) Problem:

Keines der Schlüsselattribute der beiden Relationen ist am Join beteiligt.

Page 41: 1 Teil I Datenmodelle Kapitel 9: Transformationen

41

Löschoperationen (6)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Versuch 1:

Lösche Tupel aus beiden Relationen (Schlüssel gegeben!)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Versuch 2:

Lösche Tupel aus LagerhilfsmittelArt (Schlüssel gegeben!)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Page 42: 1 Teil I Datenmodelle Kapitel 9: Transformationen

42

Löschoperationen (6)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Versuch 1:

Lösche Tupel aus beiden Relationen (Schlüssel gegeben!)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Versuch 3:

Lösche Tupel aus Lagereinheit (Schlüssel gegeben!)

Displaypalette

Displaypalette

Displaypalette

LHA-05

LHA-06

LHA-06

LEA-05

LEA-05

LEA-05

LE-007

LE-004

LE-007

LhaNameLhaNrLeaNrLeNr

A-015

A-017

A-015

ANr2

85

175

85

Stückzahl

212.50

175.00

212.50

Gewicht

LH-006

LH-006

LH-006

LhNr MaxGewicht HöheBreiteLänge

600

600

600

400

400

400

150

100

100

200.00

150.00

150.00

Page 43: 1 Teil I Datenmodelle Kapitel 9: Transformationen

43

Einfügeoperationen (1)ADB ADB'

DB DB'

o = einfüge(anr,aname)

p??

vv = ANr,AName(ArtikelArt)

Forderung:

ANr,AName (ArtikelArt) {(anr, aname)} = ANr,AName (p(ArtikelArt))

und somit

p(ArtikelArt) = ArtikelArt {(anr, aname, x, y, z)}. Problem:

Keine Belegung für x, y, z bekannt, daher Vorbelegung mit NULL.

Page 44: 1 Teil I Datenmodelle Kapitel 9: Transformationen

44

Einfügeoperationen (1)

2.00 0.05 0.10 1.00 0.501.50 0.100.400.400.501.001.00 0.800.802.50 0.50 1.001.003.006.00

BoschMahleMahleMahleMahleErzbergMahleMahleBoschPohlmannBoschOsramSiemensSiemensSiemens BoschErzbergPohlmannMahleErzberg

11

501111

20205020201010

55

1010

11

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

Gewicht LieferantMengeANameAnr

ArtikelArt

AnlasserKolbenKolbenringeKurbelwelleNockenwelleÖlwannePleuelVentileVentileVentilfedernZündkerzenZündkerzenZündkerzenkabelZündkerzensteckerZündspuleZündverteilerZylinderdichtungZylinderdichtungZylinderkopfZylinderkurbelgehäuse

A001A002A003A004A005A006A007A008A009A010A011A012 A013A014A015A016A017A018A019A020

ANameAnr

ANr,AName(ArtikelArt)

A-030 ÖlfilterA-030 Ölfilter NULL NULL NULL

Eindeutigkeit in Sicht lässt sich zurückführen auf Eindeutigkeit in Basisrelation

Page 45: 1 Teil I Datenmodelle Kapitel 9: Transformationen

45

Einfügeoperationen (2)ADB ADB'

DB DB'

o = einfüge(aname)

p??

vv = AName(ArtikelArt)

Forderung: AName (ArtikelArt) {(aname)} = AName (p(ArtikelArt))

und somit p(ArtikelArt) = ArtikelArt {(w, aname, x, y, z)}. Problem:

w = NULL unzulässig wenn ANr key und nur einmal zulässig wenn ANr unique.

Page 46: 1 Teil I Datenmodelle Kapitel 9: Transformationen

46

Einfügeoperationen (3)ADB ADB'

DB DB'

o = einfüge(anr,aname,menge,lieferant,gewicht)

p??

vv = Lieferant='Siemens'(ArtikelArt)

Forderung:

Lieferant='Siemens' (ArtikelArt) {(anr, aname, menge, lieferant, gewicht)}

= Lieferant='Siemens' (p(ArtikelArt)) Für p ergibt sich:

p(ArtikelArt) = ArtikelArt {(anr, aname, menge, lieferant, gewicht)} Problem: Beim Einfügen von Tupeln mit Lieferant 'Siemens'

erscheinen diese wegen der Selektionsbedingung nicht in der Sicht.

Page 47: 1 Teil I Datenmodelle Kapitel 9: Transformationen

47

Einfügeoperationen (4)ADB ADB'

DB DB'

o = einfüge(anr,...,lenr,...)

p??

vv = ArtikelArt ⋈ LagereinheitLeGewichtGewicht

Forderung:

ArtikelArt ⋈ LagereinheitLeGewichtGewicht {(anr,lenr)}

= p1(ArtikelArt) ⋈ p2(Lagereinheit) Vermutung für p:

- p1(ArtikelArt) = ArtikelArt {(anr,...)}

- p2(Lagereinheit) = Lagereinheit {(lenr,...)}

Page 48: 1 Teil I Datenmodelle Kapitel 9: Transformationen

48

Einfügeoperationen (4)

Ist neues Tupel in der Sichtrelation noch nicht vorhanden, so muss zwingend – wegen der referenziellen Konsistenz – ein Tupel in Lagereinheit eingefügt werden.

Hingegen kann geeignetes Tupel bereits in ArtikelArt existieren, muss aber nicht. Falls existent, muss p1 Eindeutigkeit bzgl. Schlüssel in der Basisrelation durchsetzen.

Falls neues Tupel in der Sichtrelation bereits vorhanden, so muss auch p2 Eindeutigkeit bzgl. Schlüssel in der Basisrelation durchsetzen.

Page 49: 1 Teil I Datenmodelle Kapitel 9: Transformationen

49

Informationserhaltung (1)Fazit: View Update-Problem: Änderungsoperationen bereiten in

komplizierteren Fällen Probleme. Erwünscht: Systematische Analyse der Randbedingungen,

unter denen Änderungen im Hinblick auf Informationserhaltung zulässig sind.

Vereinfachende Annahmen: Ignorieren von Selektionsbedingungen Betrachtung nur einattributiger Schlüssel Joins sind stets Equi-Joins Weitere Voraussetzungen: Kenntnis über Zusammenhänge zwischen den Attributen

liegt vor: Schlüsselfunktion, Join-Attribute.

Page 50: 1 Teil I Datenmodelle Kapitel 9: Transformationen

50

Informationserhaltung (2)Seien R1, ..., Rn die Basisrelationen und V = v(R1, ..., Rn) eine

auf den Ri definierte Sichtrelation.

Dann konstruieren wir den Spurgraphen G(V) wie folgt: Für jedes Attribut der Relationen Ri wird ein -Knoten

eingeführt, und für jedes Attribut von V ein -Knoten. Zwischen jedem Sichtattribut V.A und seinem

definierenden Attribut Ri.B in einer der Basisrelationen wird eine bidirektionale Kante zwischen den beteiligten Knoten gezogen.

Für jede (Equi-)Join-Bedingung Ri.A = Rj.B wird eine bidirektionale Kante zwischen den beteiligten Knoten gezogen.

Für jeden (einattributigen) Schlüssel Ri.A werden gerichtete Kanten vom Schlüsselattribut Ri.A zu allen anderen Attributen von Ri gezogen.

Page 51: 1 Teil I Datenmodelle Kapitel 9: Transformationen

51

Informationserhaltung (3)Spurgraph für ANr,AName(ArtikelArt).

Spurgraph für AName(ArtikelArt).

AName ANr Menge Lieferant Gewicht

ArtikelArt

AName ANr Menge Lieferant Gewicht

ArtikelArt

Page 52: 1 Teil I Datenmodelle Kapitel 9: Transformationen

52

Informationserhaltung (4)Spurgraph für ArtikelArt ⋈ LagereinheitLeGewichtGewicht

AName ANr Menge Lieferant Gewicht

ArtikelArt

ANr LeNr LeaNr Stückzahl LhNr

Lagereinheit

Gewicht

AName ANr Menge Lieferant Gewicht LeNr LeaNrStückzahl LhNrLeGewicht

Page 53: 1 Teil I Datenmodelle Kapitel 9: Transformationen

53

Informationserhaltung (5)Pfade im Spurgraph: Seien A und B Knoten in G(V). Dann ist A v B Pfad in G(V),

falls eine Kante von A nach B existiert oder es einen Knoten C in G(V) gibt, so dass eine Kante von

A nach C verläuft und ein Pfad C v B gefunden werden kann.

Pfade für Knotenmengen: Sei Z Knotenmenge. A v Z ist Pfad in G(V), falls für jedes C Z gilt: A v C.

Sichtspur: Sei A -Knoten und B -Knoten in G(V). A heißt Sichtspur von B, falls A v B und B v A (kurz: A v B).

Page 54: 1 Teil I Datenmodelle Kapitel 9: Transformationen

54

Informationserhaltung (6)Spurgraph für ArtikelArt ⋈ LagereinheitLeGewichtGewicht

AName ANr Menge Lieferant Gewicht

ArtikelArt

ANr LeNr LeaNr Stückzahl LhNr

Lagereinheit

Gewicht

AName ANr Menge Lieferant Gewicht LeNr LeaNrStückzahl LhNrLeGewicht

Pfad

Sichtspur

Page 55: 1 Teil I Datenmodelle Kapitel 9: Transformationen

55

Löschoperationen (1)

Sei V Sichtrelation und X Attributfolge in V . delete(V, X) sei Löschoperation, wobei für jedes Attribut in

X ein Wert spezifiziert wird. Dann ist delete(V, X) informationserhaltend auf

Löschoperationen in den Basisrelationen abbildbar, falls es genau eine Basisrelation Ri mit einem Schlüssel Ki so gibt, dass Ki v X.

Es werden dann ausschließlich Tupel aus diesem Ri entfernt.

Page 56: 1 Teil I Datenmodelle Kapitel 9: Transformationen

56

Löschoperationen (2)Spurgraph für AName(ArtikelArt).

delete(V,AName) mit AName = aname. ANr ist Schlüssel in ArtikelArt. Es gilt: ArtikelArt.ANr v V.AName. Die Löschoperation ist also durchführbar. Es werden alle

einschlägigen Tupel entfernt.

AName ANr Menge Lieferant Gewicht

ArtikelArt

AName

Page 57: 1 Teil I Datenmodelle Kapitel 9: Transformationen

57

Löschoperationen (3)

Spurgraph für ANr, AName(ArtikelArt).

delete(V,(ANr,AName)) mit (ANr,AName) = (anr,aname). Es gilt: ArtikelArt.ANr v (V.ANr, V.AName). Die Löschoperation ist also gestattet.

AName ANr Menge Lieferant Gewicht

ArtikelArt

AName ANr

Page 58: 1 Teil I Datenmodelle Kapitel 9: Transformationen

58

Löschoperationen (4)Spurgraph für ArtikelArt ⋈ LagereinheitLeGewichtGewicht

delete (V,(ANr,LeNr)) mit (ANr,LeNr) = (anr,lenr). Die beiden möglichen Schlüssel sind ANr in ArtikelArt und

LeNr in Lagereinheit. Nur für LeNr ist die Pfadbedingung erfüllt. Löschen findet also nur in der Basisrelation Lagereinheit

statt.

AName ANr Menge Lieferant Gewicht

ArtikelArt

ANr LeNr LeaNr Stückzahl LhNr

Lagereinheit

Gewicht

AName ANr Menge Lieferant Gewicht LeNr LeaNrStückzahl LhNrLeGewicht

Page 59: 1 Teil I Datenmodelle Kapitel 9: Transformationen

59

Einfügeoperationen (1) Sei V Sichtrelation und t ein Tupel. Dann ist insert(V,t) informationserhaltend auf Einfügeoperationen in

den Basisrelationen abbildbar, falls folgendes gilt:

- Konsistenz

- Seiteneffektfreiheit

- Eindeutigkeit

Page 60: 1 Teil I Datenmodelle Kapitel 9: Transformationen

60

Einfügeoperationen (2) Sei V Sichtrelation und t ein Tupel. Dann ist insert(V,t) informationserhaltend auf Einfügeoperationen in

den Basisrelationen abbildbar, falls folgendes gilt:

- Konsistenz

- Seiteneffektfreiheit

- Eindeutigkeit

Konsistenz: Sei Ri Basisrelation.

1. Sind D1, D2 Sichtspuren desselben Attributs in Ri, dann D1({t}) =

D2({t}).

2. In der Menge der Ri muss (mindestens ein) Schlüssel Ki eine Sichtspur

D besitzen, und D({t}) darf nicht NULL sein.

3. Für jedes Ri mit Schlüssel Ki und weiterem Attribut Ai gilt: Falls DK Sichtspur von Ki ist und DA Sichtspur von Ai ist, dann gilt für alle sV:

Mit DK({t}) = DK({s}) folgt DA({t}) = DA({s}). Bed. 3 nicht aus dem Schema, sondern erst aus der Datenbasis zu bestimmen.

Page 61: 1 Teil I Datenmodelle Kapitel 9: Transformationen

61

Einfügeoperationen (2)

R1 R2

D1 D2 DK1 DK2 DA

Konsistenzbed. 1

Konsistenzbed. 2

Konsistenzbed. 3

K2K1 A

Page 62: 1 Teil I Datenmodelle Kapitel 9: Transformationen

62

Einfügeoperationen (3) Sei V Sichtrelation und t ein Tupel. Dann ist insert(V,t) informationserhaltend auf Einfügeoperationen in

den Basisrelationen abbildbar, falls folgendes gilt:

- Konsistenz

- Seiteneffektfreiheit

- Eindeutigkeit

Seiteneffektfreiheit:

Für alle Attribute Aj von V mit Aj({t}) NULL existiert für jede

Basisrelation Ri ein Schlüssel Ki, so dass Ki v {Aj}.

Page 63: 1 Teil I Datenmodelle Kapitel 9: Transformationen

63

Einfügeoperationen (3)

R1 R2

D1 D2 DK1 DK2 DA

K2K1 A

Konsistenzbed. 1

Konsistenzbed. 2

Konsistenzbed. 3

Seiteneffektfreiheit (nur K2)

Page 64: 1 Teil I Datenmodelle Kapitel 9: Transformationen

64

Einfügeoperationen (4) Sei V Sichtrelation und t ein Tupel. Dann ist insert(V,t) informationserhaltend auf Einfügeoperationen in

den Basisrelationen abbildbar, falls folgendes gilt:

- Konsistenz

- Seiteneffektfreiheit

- Eindeutigkeit

Eindeutigkeit:

Jedes Attribut in der Equijoin-Bedingung besitzt eine Sichtspur Dj, und

Dj({t}) NULL.

Page 65: 1 Teil I Datenmodelle Kapitel 9: Transformationen

65

Einfügeoperationen (4)

R1 R2

D1 D2 DK1 DK2 DA

K2K1 A

Konsistenzbed. 1

Konsistenzbed. 2

Konsistenzbed. 3

Seiteneffektfreiheit (nur K2)

Eindeutigkeit

Page 66: 1 Teil I Datenmodelle Kapitel 9: Transformationen

66

Einfügeoperationen (5)Spurgraph für ANr,AName(ArtikelArt).

insert(anr, aname). Konsistenz (Bed. 2) und Seiteneffektfreiheit sind sichergestellt. Konsistenzbed. 1 und Eindeutigkeitsbedingung entfallen. Dritte Bedingung für Konsistenz ist zu prüfen: Sie schließt aus,

dass ein Tupel mit bereits vorhandenem Schlüssel, aber ansonsten abweichenden Werten eingefügt wird.

In ArtikelArt: insert(anr, aname, NULL, NULL, NULL).

AName ANr Menge Lieferant Gewicht

ArtikelArt

AName ANr

Page 67: 1 Teil I Datenmodelle Kapitel 9: Transformationen

67

Einfügeoperationen (6)Spurgraph für AName(ArtikelArt).

insert(aname). Es wird gegen die zweite Bedingung zur Konsistenz

verstoßen: Der Schlüssel ANr besitzt keine Sichtspur.

AName ANr Menge Lieferant Gewicht

ArtikelArt

AName

Page 68: 1 Teil I Datenmodelle Kapitel 9: Transformationen

68

Einfügeoperationen (7)Spurgraph für ArtikelArt ⋈ LagereinheitLeGewichtGewicht

insert(aname,anr,menge,lieferant,gew1,lenr,leanr,stückzahl,gew2,lhnr)

Seiteneffektfreiheit ist nicht gesichert: Schlüssel ANr der Basisrelation ArtikelArt leistet nicht die Pfadbedingung.

Somit ist die Einfügeoperation nicht zwingend informationserhaltend.

AName ANr Menge Lieferant Gewicht

ArtikelArt

ANr LeNr LeaNr Stückzahl LhNr

Lagereinheit

Gewicht

AName ANr Menge Lieferant Gewicht LeNr LeaNr Stückzahl LhNrGewicht

Page 69: 1 Teil I Datenmodelle Kapitel 9: Transformationen

69

Kapitel 9.3: Sichten in SQL

Page 70: 1 Teil I Datenmodelle Kapitel 9: Transformationen

70Vereinbarung von Sichten (1)

Erzeugen von Sichten:create view view-name [ (attributliste ) ]

as sql-ausdruck

Löschen von Sichten:drop view view-name

Beispiele:create view ArtikelÜbersicht as

select ANr, ANamefrom ArtikelArt;

create view SiemensArtikel asselect from ArtikelArtwhere Lieferant = 'Siemens';

create view SchwereLagereinheit asselect from Lagereinheitwhere Gewicht > 100.0;

Page 71: 1 Teil I Datenmodelle Kapitel 9: Transformationen

71Vereinbarung von Sichten (2)

Beispiele:

create view GelagerterArtikel ( ANr, AName, Menge, Lieferant, Gewicht, LeNr, LeaNr, Stückzahl, LeGewicht, LhNr )

select A.ANr, AName, Menge, Lieferant, A.Gewicht, LeNr, LeaNr, Stückzahl, Le.Gewicht, LhNr

from ArtikelArt A, Lagereinheit Lewhere A.Anr = Le.ANr;

create view UnzulässigeKombination asselect from Lagereinheit, LagerhilfsmittelArtwhere Gewicht MaxGewicht;

Selektionen, Projektionen, Join-Operationen, Gruppierung sind allesamt möglich.

Page 72: 1 Teil I Datenmodelle Kapitel 9: Transformationen

72Vereinbarung von Sichten (3)

Durch den Anwender parametrisierte Sichten sind nicht möglich.Beispiel: Der für einen Lieferanten nach Stückzahl am häufigsten gelagerte

Artikel. Der Parameter Lieferant muss bei Definition der Sicht jeweils

ausgefüllt werden, beispielsweise mit „Bosch“ oder „Siemens“:

create view HäufigsterArtikelFürLieferant asselectA.ANr, AName, sum(Stückzahl)from ArtikelArt A, Lagereinheit LewhereA.Anr = Le.ANrand Lieferant = 'Lieferant'group by A.ANrhaving sum(Stückzahl) >= all (

select sum(Stückzahl)from ArtikelArt A, Lagereinheit Lewhere A.Anr = Le.ANrand Lieferant = 'Lieferant'group by A.Anr ); SQL-Prozeduren sind nur ein

Notbehelf!

Page 73: 1 Teil I Datenmodelle Kapitel 9: Transformationen

73Informationserhaltung

Faustregeln für erlaubtes Ändern von Sichten: Die Sicht darf nur aus einer einzigen Basisrelation oder Sicht

abgeleitet und nicht geschachtelt sein. Falls die Sicht aus einer anderen Sicht abgeleitet ist, muss

diese andere Sicht änderbar sein. Die Sicht darf aus keiner Gruppierung hervorgegangen sein. Die Sicht darf nicht aus einer Duplikateliminierung (distinct)

hervorgegangen sein. Kein Attribut darf auf einer Aggregierungsfunktion basieren. Modifizieren von Attributen, die aus einer arithmetischen

Operation hervorgehen, und Löschen von Tupeln, die derartige Attribute enthalten, ist nicht erlaubt.

Damit werden allerdings auch nach Kapitel 9.2 zulässige Fälle ausgeschlossen.

Page 74: 1 Teil I Datenmodelle Kapitel 9: Transformationen

74

Kapitel 9.4:

Objektorientierte Sichten auf relationale Daten

Page 75: 1 Teil I Datenmodelle Kapitel 9: Transformationen

75

Beispiel: Java 2 Enterprise Edition

Dienstnehmer-Behälter

Transaktionsdienst

Ressourcen-Verwalter

Kommunikation(HTTP, IIOP, RMI, JDBC)

Persistenzdienst

JAF

JND

I

JDB

C

JTA

J2SE

JMS WWW-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Java

Ser

vlet

s

Java

Ser

ver

Page

s

EJB-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Ent

erpr

ise

Java

Bea

n

Ent

erpr

ise

Java

Bea

n

Fremd-Behälter

Applet-Behälter

J2SE

RessourcenDatenlogik

GeschäftsprozessAnwendungs-Dienstgeber

PräsentationWWW-Dienstgeber

AnwenderDienstnehmer

Konnektor

RMI-IIOP

HTTP

HTTP

RMI-IIOP

JDBC

NamensdienstSicherheitsdienst Nachrichtendienst

JDBC

objektorientiert(Java)

relational

Page 76: 1 Teil I Datenmodelle Kapitel 9: Transformationen

76

Dauerhafte Objekte

Aus einer objektorientierten Anwendung heraus sollen die Zustandsdaten der Objekte dauerhaft in einem RDBMS hinterlegt werden. Die Sicht braucht (und kann) sich nur ausschließlich struktureller Merkmale bedienen.

Das objektorientierte Schema der Anwendung bildet hierbei den Ausgangspunkt, um ein relationales Schema zu generieren.

ADB ADB'o

p

vv

DB DB'

Gegeben: oo-Schema

Gesucht: Relationales Schema und v informationserhaltend

Page 77: 1 Teil I Datenmodelle Kapitel 9: Transformationen

77

Abbildung Die unterschiedliche Ausdrucksmächtigkeit der beiden

Datenmodelle bereitet Probleme bei der Abbildung. Abzubildende Konzepte sind:

Objektidentität Objektverweise Mengenkonstruktion Typhierarchien (Vererbung)

Page 78: 1 Teil I Datenmodelle Kapitel 9: Transformationen

78

Objekte und Objektidentität Objekttypen werden in Relationstypen überführt. Die Menge der Ausprägungen eines Objekttyps bildet dann

die (einzige) Relation dieses Relationstyps. Objektidentitäten definieren die Eindeutigkeit. Da sie nicht

sichtbar sind, muss die Abbildung objektidentifizierende Werte erzeugen. Liegt Extent mit Schlüssel vor, kann der Schlüssel

übernommen werden. Andernfalls müssen künstliche objektidentifizierende Werte als

Schlüssel (Surrogat) erzeugt und unter einem zusätzlichen Attribut geführt werden.

Page 79: 1 Teil I Datenmodelle Kapitel 9: Transformationen

79

Objekte und Objektverweise Abbildung von Attributen:

Atomares Objektattribut wird zu atomarem Attribut des Relationstyps.

Attribut mit Objektverweis wird zu Attribut des Relationstyps, das Schlüssel des Tupels aufnimmt, das aus der Abbildung des Verweisobjekts hervorgeht (Fremdschlüssel).

Konstruktion des Relationstyps: Ausschließlich atomare Attribute: Jedes Objekt wird zu

relationalem Tupel. Ausschließlich atomare und Verweis-Attribute: Jedes Objekt

wird zu relationalem Tupel.

Page 80: 1 Teil I Datenmodelle Kapitel 9: Transformationen

80Objektorientiertes Ausgangsschema: class ArtikelArt (key ANr) {

ANr: String; AName: String; Menge: Integer; Lieferant: String; Gewicht: Float };

class Lagereinheit (key LeNr) {

LeNr: String; LeaNr: LagereinheitArt; ANr: ArtikelArt; Stückzahl: Integer; Gewicht: Float; LhNr:

Lagerhilfsmittel }; class LagereinheitArt (key LeaNr) {

LeaNr: String; LeaName: String; Länge: Integer; Breite: Integer; Höhe: Integer; MaxGewicht: Float };

Beispiel (1)

class Lagerhilfsmittel (key LhNr) { LhNr: String; LhaNr:

LagerhilfsmittelArt; Gewicht: Float; LoNr: Lagerort };

class LagerhilfsmittelArt

(key LhaNr) { LhaNr: String; LhaName: String; Länge: Integer; Breite: Integer; Höhe: Integer; MaxGewicht: Float };

Relationen:Trivial, da Schlüssel gegeben, Attribute nur atomar oder Verweise. relation ArtikelArt(ANr,AName,Menge,Lieferant,Gewicht); relation Lagereinheit(LeNr,LeaNr,ANr,Stückzahl,Gewicht,LhNr); relation LagereinheitArt(LeaNr,LeaName,Länge,Breite,Höhe,MaxGewicht);relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);relation LagerhilfsmittelArt(LhaNr,LhaName,Länge,Breite,Höhe,MaxGewicht);

Page 81: 1 Teil I Datenmodelle Kapitel 9: Transformationen

81class Lagerort (key LoNr) {

LoNr: String; LoaNr: LagerortArt; Gewicht: Float };

class LagerortArt (key LoaNr) {

LoaNr: String; Länge: Integer; Breite: Integer; Höhe: Integer; MaxGewicht: Float };

class Verträglichkeit (key ANr, LoNr) {

ANr: ArtikelArt; LoNr: Lagerort };

Beispiel (2)

Relationen:Trivial, da Schlüssel gegeben. Attribute nur atomar oder Verweiserelation Lagerort(LoNr, LoaNr, Gewicht);relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);relation Verträglichkeit(ANr, LoNr);

Page 82: 1 Teil I Datenmodelle Kapitel 9: Transformationen

82

Objekte und Mengenkonstruktion Konstruktion des Relationstyps:

Mischung aus atomaren und Verweis-Attributen sowie Mengen oder Listen hiervon: Atomare/Verweis-Attribute bilden Relationstyp TR. Bilde für jedes mengenwertige Attribut (ggf. Menge über Tupelstruktur) einen eigenen Relationstyp. Dort bildet das identifizierende Attribut von TR den Fremdschlüssel.

Page 83: 1 Teil I Datenmodelle Kapitel 9: Transformationen

83

Beispiel (3)

class Punkt( extent punkte ) { attribute float x; attribute float y; attribute float z; void translation(in Punkt p);};

class Kante { attribute Punkt p1; attribute Punkt p2; void translation(in Punkt p);};

class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; void translation(in Punkt p);};

class Vielflächner( extent vielflächner; key vName ) { attribute string vName; relationship set<Fläche> flächen inverse Fläche::körper; void translation(in Punkt p);};

class Quader extends Vielflächner( extent quader ) { attribute float volume();};

Punkt (PSurr, x, y, z)

Kante (KSurr, PSurr1, PSurr2)

Fläche (FSurr)

Kanten (KSurr, FSurr)Körper (VName, FSurr)

Vielflächner (VName)

Flächen (FSurr, VName)

(lokaler) Fremdschlüssel

Bidirektional: Beschreibt gleichen Sachverhalt

Page 84: 1 Teil I Datenmodelle Kapitel 9: Transformationen

84

Punkt (PSurr, x, y, z)Kante (KSurr, PSurr1, PSurr2)Fläche (FSurr)Kanten (KSurr, FSurr)Vielflächner (VName)Körperflächen (VName, FSurr)

Beispiel (3)

Page 85: 1 Teil I Datenmodelle Kapitel 9: Transformationen

85

Objekte und Mengenkonstruktion Konstruktion des Relationstyps:

Sonderfall: Ein einziges, mengen- oder listenwertiges Attribut mit Elementen, die einer der zuvor betrachteten Attributstrukturen folgen:

Wende das zutreffende der zuvor betrachteten Verfahren auf die Attributstruktur an.

Es werde nunmehr Mengen von Mengen in einer Relation geführt, d.h. die Menge von Mengen wird zu einer Ebene verflacht.

Das Surrogatattribut des Objekts kann somit nicht alleine Schlüssel sein.

Page 86: 1 Teil I Datenmodelle Kapitel 9: Transformationen

86

Dem Konzept der Subtypisierung entspricht kein relationales Konstrukt.

Das relationale Modell kennt auch keine Vererbung. Das Erscheinungsbild der Subtypisierung kann sich also im

relationalen Schema nur in gewissen Zusammenhängen innerhalb oder zwischen Relationen (also in der Datenbasis selbst!) widerspiegeln.

Dementsprechend lassen sich auch mehrere Abbildungsregeln angeben.

Typhierarchien

Page 87: 1 Teil I Datenmodelle Kapitel 9: Transformationen

87Objektorientiertes Ausgangsschema:

class Lagereinrichtung {

Nr: String; Art: LagereinrichtungsArt; Gewicht: Float };

class Lagereinheit : Lagereinrichtung {

ANr: ArtikelArt; Stückzahl: Integer; LhNr: Lagerhilfsmittel };

class Lagerhilfsmittel : Lagereinrichtung {LoNr: Lagerort };

class Lagerort : Lagereinrichtung {};

Beispiel

Lagereinrichtung

Lagerort Lagerhilfsmittel Lagereinheit

Page 88: 1 Teil I Datenmodelle Kapitel 9: Transformationen

88Option 1: Jeder Objekttyp einer Typhierarchie bildet eine eigene Relation. Jede Relation handelt ihren eigenen Satz von Attributen ab. Bei allen kommt das Schlüsselattribut aus dem Obertyp hinzu.

Abbilden von Typhierarchien (1)

Lagereinrichtung

Lagerort Lagerhilfsmittel Lagereinheit

relation Lagereinrichtung (Nr, Art, Gewicht);

relation Lagereinheit(Nr, ANr, Stückzahl, LhNr);

relation Lagerhilfsmittel(Nr, LoNr)

relation Lagerort(Nr)

Bewertung: Vererbung der Attribute nicht unmittelbar ersichtlich. Zur Gewinnung der Originalinformation müssen die Werte unter diesen

Attributen aus verschiedenen Relationen verbunden werden. Verbinden nur möglich bei identischen Schlüsselwerten. Daher nur

sinnvoll bei Mengeninklusions-Semantik.

Page 89: 1 Teil I Datenmodelle Kapitel 9: Transformationen

89Option 2: Jeder Objekttyp einer Typhierarchie bildet eine eigene Relation. Jetzt werden jedoch mit einer Relation sämtliche, also auch die

ererbten Attribute aufgenommen.

Abbilden von Typhierarchien (2)

Lagereinrichtung

Lagerort Lagerhilfsmittel Lagereinheit

relation Lagereinrichtung (Nr, Art, Gewicht);

relation Lagereinheit(Nr, Art, Gewicht, ANr, Stückzahl, LhNr);

relation Lagerhilfsmittel(Nr, Art, Gewicht, LoNr)

relation Lagerort(Nr, Art, Gewicht)

Bewertung: Jedes Objekt wird in der Relation geführt, die seinem Objekttyp

entspricht. Diese Lösung setzt keine Mengeninklusions-Semantik voraus. Liegt

jedoch eine solche vor, so kommt es zu Replikationen und somit zu Redundanzen in den Relationen für die Untertypen.

Page 90: 1 Teil I Datenmodelle Kapitel 9: Transformationen

90Option 3: Jeder Pfad von der Wurzel zu den Blättern der Hierarchie bildet eine

eigene Relation. Zwangsläufig enthält jede Relation die entlang ihres Pfades

beobachteten Attribute.

Abbilden von Typhierarchien (3)

relation Lagereinheit(Nr, Art, Gewicht, ANr, Stückzahl, LhNr);

relation Lagerhilfsmittel(Nr, Art, Gewicht, LoNr)

relation Lagerort(Nr, Art, Gewicht)

Bewertung: Diese Lösung fordert eine Mengeninklusions-Semantik in der

verschärften Form der Überdeckung. Vorteilhaft ist, dass alle Attribute jedes Objekts in genau einem

einzigen Tupel gehalten werden können und nicht über mehrere Relationen verstreut sind.

Dafür ist andererseits die ursprüngliche Typhierarchie auch nicht mehr erkennbar.

Lagereinrichtung

Lagerort Lagerhilfsmittel Lagereinheit

Page 91: 1 Teil I Datenmodelle Kapitel 9: Transformationen

91Option 4: Die gesamte Generalisierungshierarchie fällt in einer einzigen Relation für

die Wurzel zusammen.

Abbilden von Typhierarchien (4)

relation Lagereinrichtung(Einrichtungstyp, Nr, Art, Gewicht, LeANr, LeStückzahl, LeLhNr, LhLoNr);

Bewertung: Je nach tatsächlichem Typ des Objekts sind nur bestimmte Attribute

mit Werten belegt; die anderen enthalten NULL. Um nicht aus der Belegung auf die tatsächlichen Typen schließen zu

müssen, muss der Relation ein zusätzliches Typ-Attribut beigegeben werden (hier: Einrichtungstyp).

Die Lösung eignet sich ohne und mit Mengeninklusions-Semantik. Im letzteren Fall gibt die Belegung von Einrichtungstyp den speziellsten Typ an. Dann Disjunktheit der Untermengen erforderlich.

Im Vergleich zur zweiten Lösung ist der entstehende Relationstyp allerdings stark aufgebläht.

Lagereinrichtung

Lagerort Lagerhilfsmittel Lagereinheit

Page 92: 1 Teil I Datenmodelle Kapitel 9: Transformationen

92

Operationen Mit der Konstruktion des relationalen Schemas ist gesichert,

dass sich alle Objektzustände in der dauerhaften, relationalen Datenbasis wiederfinden.

Damit sind die Voraussetzungen geschaffen, dass Änderungen am Objektzustand eindeutig in Änderungen in der Datenbank abgebildet werden können.

Objektändernde (und ebenso -lesende) Operatoren sind so zu implementieren, dass sie entsprechende Operationen auf der relationalen Datenbasis ausführen, z.B. unter Verwenden von JDBC.

Page 93: 1 Teil I Datenmodelle Kapitel 9: Transformationen

93

Beispiel: Java 2 Enterprise Edition

Dienstnehmer-Behälter

Transaktionsdienst

Ressourcen-Verwalter

Kommunikation(HTTP, IIOP, RMI, JDBC)

Persistenzdienst

JAF

JND

I

JDB

C

JTA

J2SE

JMS WWW-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Java

Ser

vlet

s

Java

Ser

ver

Page

s

EJB-Behälter

JAF

JND

I

JDB

C

JTA

J2SE

JMS

Ent

erpr

ise

Java

Bea

n

Ent

erpr

ise

Java

Bea

n

Fremd-Behälter

Applet-Behälter

J2SE

RessourcenDatenlogik

GeschäftsprozessAnwendungs-Dienstgeber

PräsentationWWW-Dienstgeber

AnwenderDienstnehmer

Konnektor

RMI-IIOP

HTTP

HTTP

RMI-IIOP

JDBC

NamensdienstSicherheitsdienst Nachrichtendienst

JDBC

objektorientiert(Java)

relational

Page 94: 1 Teil I Datenmodelle Kapitel 9: Transformationen

94

Objektsichten

ADB ADB'o

p

vv

DB DB'

Gegeben: Relationales Schema

Gesucht: Objektsicht auf relationale DB (oo-Schema

und v informationserhaltend)

Vorgehensweise: Definition eines objektorientierten Schemas mit passenden

Objekttypen zum Zugriff für die Anwendung. Festlegen der Anfragen, wie die Daten extrahiert und zu

Objekten zusammengebaut werden. Festlegen eines Objektidentifikators, der sich aus

Attributwerten ergibt (meist Schlüsselattribut). Grundsätze für die Operationen wie zuvor.

Page 95: 1 Teil I Datenmodelle Kapitel 9: Transformationen

95

Manuelle Konstruktion

Lagermanagement:

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

Lagermanagement:

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

create view AV of ArtikelArt with oid(ANr) as select ANr, AName, Menge from ArtikelArt

create view AV of ArtikelArt with oid(ANr) as select ANr, AName, Menge from ArtikelArt

class ArtikelArt {string AName;float Menge;

}

class ArtikelArt {string AName;float Menge;

} Objekttyp angeben

Objektidentität festlegen

Attributwerte füllen

Erscheinungsbild als Klasse angeben

Konstruktion der Ausprägung (Sicht)

Page 96: 1 Teil I Datenmodelle Kapitel 9: Transformationen

96

Kanonische Konstruktion (1)Gegeben: Relationales Schema RS von n Relationstypen:

RS = {TRi}, 1 i n. Für jedes TRi sei KRi ein zugehöriger Schlüssel.

Schritt 1: Objekt-Relationstypen: TRi RS ist Objekt-Relationstyp, wenn

gilt: KRi enthält höchstens einen

Fremdschlüssel oder KRi ist insgesamt Fremdschlüssel.

KRi

KRi

Schritt 2: Beziehungs-Relationstypen: Alle anderen Relationstypen bilden Beziehungs-

Relationstypen.

Page 97: 1 Teil I Datenmodelle Kapitel 9: Transformationen

97

Kanonische Konstruktion (2)

Schritt 3: Gewinnung von Objekttypen: Jeder Objekt-Relationstyp wird in einen Objekttyp überführt. Jeder Beziehungs-Relationstyp wird in einen Objekttyp

überführt. Ausnahme: Es existieren keine Nichtschlüsselattribute und der

Schlüssel wird aus zwei Fremdschlüsseln K1 und K2 gebildet. Dann kann man dem Objekttyp mit K1 ein mengenwertiges Attribut mit referenzieller Konsistenz auf den Objekttyp mit K2 zuschlagen und umgekehrt.

Schritt 4: Gewinnung von Objektidentitäten: Besitze ein Objekt unter der Attributfolge KR, die dem

Schlüssel des zugrundeliegenden Objekt- oder Beziehungs-Relationstyps TR entspricht, den Wert k. Dann oid := TR.k.

Page 98: 1 Teil I Datenmodelle Kapitel 9: Transformationen

98

Schritt 5: Referenzielle Konsistenzen: Fremdschlüssel in Objekttypen werden durch

relationship/inverse gekennzeichnet.

Kanonische Konstruktion (3)

Page 99: 1 Teil I Datenmodelle Kapitel 9: Transformationen

99

Abbildung: Schritt 1: Alle Relationen außer Verträglichkeit sind Objekt-Relationen. Schritt 2: Verträglichkeit ist Beziehungs-Relation. Schritt 3: Konstruiere Objekttypen zu den Objekt-Relationen. Schritt 4: Konstruiere Objektidentifikatoren. Schritt 5: Konstruiere referenzielle Konsistenzen.

Lagermanagement:

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

relation LagereinheitArt(LeaNr, LeaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerhilfsmittel(LhNr, LhaNr, Gewicht, LoNr);

relation LagerhilfsmittelArt(LhaNr, LhaName, Länge, Breite, Höhe, MaxGewicht);

relation Lagerort(LoNr, LoaNr, Gewicht);

relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht);

relation Verträglichkeit(ANr, LoNr);

Beispiel (1)

Page 100: 1 Teil I Datenmodelle Kapitel 9: Transformationen

100

Beispiel (2)class ArtikelArt (key ANr) {

ANr: String;

relationship...inverse...; AName: String; Menge: Integer; Lieferant: String; Gewicht: Float;VertrLoNr: set<Lagerort>

relationship...inverse...};

class Lagereinheit (key LeNr) { LeNr: String;

relationship...inverse...; LeaNr: LagereinheitArt;

relationship...inverse...; ANr: ArtikelArt;

relationship...inverse...; Stückzahl: Integer; Gewicht: Float; LhNr: Lagerhilfsmittel

relationship...inverse...};

class LagereinheitArt (key LeaNr) { ... };

class Lagerhilfsmittel (key LhNr) { ... };

class LagerhilfsmittelArt (key LhaNr) {

... };

class Lagerort (key LoNr) { LoNr: String;

relationship...inverse...; LoaNr: LagerortArt; Gewicht: Float };

VertrANr: set<ArtikelArt> relationship...inverse...};

class LagerortArt (key LoaNr) { LoaNr: String;

relationship...inverse...; Länge: Integer; Breite: Integer; Höhe: Integer; MaxGewicht: Float };

Page 101: 1 Teil I Datenmodelle Kapitel 9: Transformationen

101

Kapitel 9.5: XML-Sichten auf relationale Daten

Page 102: 1 Teil I Datenmodelle Kapitel 9: Transformationen

102

Dauerhafte XML-DokumenteAufgaben:

Verwaltung von XML-Dokumenten Unterstützung von Navigation und Suche innerhalb der

Dokumente Einzelzugriff auf XML-Elemente im gespeicherten Dokument

Ändern bzw. Aktualisieren von Dokumenteninhalten Änderbarkeit einzelner XML-Elemente

Alternativen: Natives XML-Datenbanksystem

Implementierung auf Datenmodell zugeschnitten Performanzprobleme erst bei großer Anzahl von Dokumenten XML-Datenbanken befinden sich noch in der Entwicklung

Nutzung konventioneller Datenbanksysteme Schnell erreichbare Lösung Fehlanpassung der Datenmodelle mit Performanzverlust

Page 103: 1 Teil I Datenmodelle Kapitel 9: Transformationen

103

Basis Textdokument (1) Interpretation eines XML-Dokumentes …

…als fortlaufenden Text und speichern dieses Textes in einem Attribut einer Relation.

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib>

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib> XML

BibliographyBibliography

BibID PaperList

DBLP <?xml version="1.0"?><bib><paper id = "o12" ><title>Foundations of Databases</title><author><firstname>Serge</firstname><lastname>Abiteboul</lastname></author><year>1997</year><publisher> Addison Wesley</publisher></paper>…

DBLP.xml

Page 104: 1 Teil I Datenmodelle Kapitel 9: Transformationen

104

Basis Textdokument (2) Vorteile des Verfahrens:

Speichern und Auslesen von beliebigen XML-Dokumenten wird unterstützt.

Datenbasis kommt ohne Datenbankschema aus Kein Schema für XML-Dokumente benötigt!

Nachteile: Navigation und Suche im gespeicherten XML-Dokument nur

möglich, wenn Datenbanksystem spezielle Unterstützung für das Verarbeiten langer Texte bietet.

Dokumentstruktur wird nicht berücksichtigt. Lesender oder schreibender Zugriff auf Werte einzelner XML-

Elemente nur bedingt möglich.

Reine Dokumentenverwaltung

Page 105: 1 Teil I Datenmodelle Kapitel 9: Transformationen

105

Basis Dokumentgraph (1) Einbezug der Strukturinformationen, die ein XML-Dokument

enthält, in die Speicherung.

Interpretation eines XML-Dokuments … …als gerichteter Graph...

XML-Elemente und XML-Attribute ergeben die Knoten des Graphen

Kanten modellieren die Enthaltensbeziehung Kanten werden mit den Bezeichnern der enthalten

Elemente bzw. Attribute gekennzeichnet …und Speichern der Knoten und Kanten in einer Relation.

Page 106: 1 Teil I Datenmodelle Kapitel 9: Transformationen

106

Basis Dokumentgraph (2)

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib>

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib> XML

11

22

33

bib

paper

o12o12

id

Foundations…Foundations…

title

44

author

SergeSerge

firstname

AbiteboulAbiteboul

19971997

year

Addison…Addison…

publisher

lastname

Page 107: 1 Teil I Datenmodelle Kapitel 9: Transformationen

107

11

22

33

bib

paper

o12o12

id

Foundations…Foundations…

title

44

author

SergeSerge

firstname

AbiteboulAbiteboul

19971997

year

publisher

lastname

Addison…Addison…

KantenKanten

Basis Dokumentgraph (3)

Name

123334433

Beginn Ziel/WertIstText

bibpaperidtitleauthorfirstnamelastnameyearpublisher

neinneinjajaneinjajajaja

23o12Foundations…4SergeAbiteboul1997Addison…

Reihenf.

111231245

Bei Bedarf zusätzliches Attribut, um XML-Attribut und XML-Element unterscheiden

zu können

Page 108: 1 Teil I Datenmodelle Kapitel 9: Transformationen

108

Basis Dokumentgraph (4) Vorteile

Speichern und Auslesen beliebiger XML-Dokumente Einfaches Datenbankschema

Generisch, hat daher nichts mit der spezifischen Struktur des XML-Dokuments zu tun

Daher für XML-Dokument kein Schema erforderlich Zugriff auf einzelne XML-Elemente möglich Reihenfolge der XML-Elemente rekonstruierbar

Nachteile Navigation und Suche innerhalb eines gespeicherten XML-

Dokumentes benötigen viele Joins Verlust von Semantik, z.B. Gruppierung von

zusammengehörenden Elementen nur operational wieder herstellbar.

Page 109: 1 Teil I Datenmodelle Kapitel 9: Transformationen

109

Basis Relationen (1)

Aufgaben: Überführen der Struktur des XML-Dokuments in Relationen Unmittelbarer Zusammenhang der beiden Strukturen und

Zwang zu relationalem Datenbankschema erfordert auch Datenbankschema für die XML-Dokumente

ADB ADB'o

p

vv

DB DB'

Gegeben: XML-Schema

Gesucht: Relationales Schema und v informationserhaltend

Page 110: 1 Teil I Datenmodelle Kapitel 9: Transformationen

110

Basis Relationen (2) Für ein XML-Dokument kann ein Schema etwa in Form

einer DTD oder eines XML-Schemas existieren. Fehlt es, kann durch heuristische Verfahren eine DTD

erzeugt werden.

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]>

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]> DTD

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib>

<?xml version="1.0" ?><bib>

<paper id = "o12" ><title> Foundations of Databases </title><author>

<firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year>

<publisher> Addison Wesley </publisher></paper>

…</bib> XML

Page 111: 1 Teil I Datenmodelle Kapitel 9: Transformationen

111

Basis Relationen (3) Ausgehend von der DTD wird ein passendes relationales

Schema erzeugt, das die Dokumente aufnehmen kann. Es müssen alle erlaubten Dokumente, die der DTD

gehorchen, gespeichert werden können: z.B. muss auch für optionale Unterelemente etc. Speicherplatz

vorhanden sein.

Annahme: Nur Blatt-XML-Elemente enthalten Freitext.

Page 112: 1 Teil I Datenmodelle Kapitel 9: Transformationen

112

Direkte Abbildung

1.Idee: XML-Element Relationstyp Für jedes in der DTD definierte XML-Element wird ein

Relationstyp mit künstlichem Schlüsselattribut angelegt. Jedes dazugehörige XML-Attribut wird zu einem Attribut

dieses Relationstypen. Element-Unterelement-Beziehungen werden mit Hilfe von

Fremdschlüsseln modelliert. Jedes Vorkommen eines XML-Elements im Dokument

ergibt dann ein Tupel in seiner zugehörigen Relation.

Der Ansatz generiert eine Vielzahl von Relationstypen und bewirkt somit eine hohe Fragmentierung der Daten.

Page 113: 1 Teil I Datenmodelle Kapitel 9: Transformationen

113

Abbildung mit Gruppierung (1)2. Idee: XML-Elemente gruppieren Relationstyp Ein in der DTD definiertes XML-Element und seine direkten

oder indirekten Unterelemente mit Textinhalt, die jeweils maximal einmal innerhalb des Elements vorkommen, bilden einen Relationstypen mit Attributen.

Darf ein Unterelement mehrfach vorkommen, wird für dieses ein neuer Relationstyp angelegt und über einen Fremdschlüssel mit der Relation des umgebenden XML-Elements verknüpft.

Entsprechend bei atomaren und mengenwertigen XML-Attributen.

Bewirkt Gruppierung von zusammengehörigen Elementen in einem Relationstyp und somit ein kompakteres relationales Schema.

Page 114: 1 Teil I Datenmodelle Kapitel 9: Transformationen

114

Abbildung mit Gruppierung

2. Idee: XML-Elemente gruppieren Relationstyp

1. Reduktion der Komplexität einer DTD z.B. <!ELEMENT a ((b|c|e)?,(e?|(f?,(b,b)*))*)> vereinfachen

2. Aus der DTD wird ein DTD-Graph generiert, der die 1:1- bzw. 1:n-Beziehungen zwischen XML-Elementen modelliert.

3. Generierung der Relationstypen durch Unterteilung der Graphstruktur.

Page 115: 1 Teil I Datenmodelle Kapitel 9: Transformationen

115

Komplexität einer DTD

Schritt 1: Reduktion der Komplexität einer DTD Geschachtelte Elementdefinitionen entschachteln

z.B. (a|b) a?,b? Folge von Kardinalitäten zusammenfassen

z.B. a*? a* Unterelemente gruppieren

z.B. ..., a*, ..., a*, ... ..., a*, ... Alle „+“ Kardinalitäten werden zu „*“

Die obigen Transformationen bewahren ... 1:1- bzw. 1:n-Elementbeziehungen und Optionale Unterelemente

Aber: Informationen über Reihenfolge und genau erlaubte Anzahl der Unterelemente kann verloren gehen

Page 116: 1 Teil I Datenmodelle Kapitel 9: Transformationen

116

Komplexität einer DTD Im Beispiel wird author+ zu author* Neue DTD beschreibt also eine Obermenge von XML-Dokumenten

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]>

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]> DTD

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]>

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]> DTD

Page 117: 1 Teil I Datenmodelle Kapitel 9: Transformationen

117

Strukturinformation

Schritt 2: Strukturinformationen extrahieren Die neue DTD dient nun als Grundlage für einen gerichteten

DTD-Graphen, der die Struktur dieser DTD repräsentiert: Für jedes XML-Element ergibt sich genau ein Knoten im Graph. Für jedes Vorkommen eines XML-Attributs bei einem Element

wird ein Knoten angelegt, der mit dem entsprechenden Element-Knoten verbunden ist.

Knoten für Element und erlaubte Unterelemente werden durch Kanten verbunden.

Ist als Kardinalität bei einem Unterelement „*“ oder „?“ angegeben oder liegt ein mengenwertiges bzw. optionales XML-Attribut vor, wird die entsprechende Kante mit dem Symbol der Kardinalität markiert.

Rekursionen können durch Zyklen im Graph erkannt werden.

Page 118: 1 Teil I Datenmodelle Kapitel 9: Transformationen

118

Strukturinformation<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]>

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> …]>

idid

bibbib

paperpaper

authorauthor

yearyear publisherpublisher

ageage firstnamefirstname lastnamelastname

**

**titletitle

DTD-Graph

??

Page 119: 1 Teil I Datenmodelle Kapitel 9: Transformationen

119

Relationstypen erzeugen

Schritt 3: Erzeugen der Relationstypen anhand des DTD-Graph Relationstypen erzeugen für…

jeden Knoten mit keiner oder mehr als einer Eingangskante, jeden Knoten unterhalb einer „*“-Kante und mindestens einen Knoten innerhalb einer Rekursion

… und mit Attributen ergänzen: Jedem Relationstypen werden diejenigen Blattknoten als

Attribute zugeschlagen, die direkt vom entsprechenden Knoten aus erreichbar sind. Eine dazwischenliegende „?“-Kante erlaubt NULL-Werte beim Attribut.

Jeder Relationstyp erhält künstlichen Schlüssel, der ein dort gespeichertes XML-Element eindeutig identifiziert.

Beziehungen werden über Fremdschlüssel modelliert.

Page 120: 1 Teil I Datenmodelle Kapitel 9: Transformationen

120

Relationstypen erzeugenbibbib

paperpaper

idid

authorauthor

yearyear publisherpublisher

ageage firstnamefirstname lastnamelastname

**

**titletitle

relation Bib (bibID)

relation Author (authorID, paperID, age, firstname, lastname )

??

relation Paper (paperID, bibID, id, title, year, publisher)

Page 121: 1 Teil I Datenmodelle Kapitel 9: Transformationen

121

Abbildung mit Gruppierung

Bewertung Speichert alle XML-Dokumente, die einer DTD folgen. Bewirkt durch die Gruppierung von zusammengehörigen

Elementen in einem Relationstyp ein kompakteres relationales Schema.

Suche und Navigation innerhalb des Dokuments benötigen wenige Join-Operationen.

Ein direkter Zugriff auf die Elemente ist möglich.

Anmerkung: Im Gegensatz zu den ersten beiden Ansätzen kann die

Struktur der XML-Dokumente nicht mehr direkt aus den Relationen entnommen werden.

Das Wissen hierüber steckt in der Abbildungsvorschrift.

Page 122: 1 Teil I Datenmodelle Kapitel 9: Transformationen

122

Datenaustausch auf Basis von XML

ADB ADB'o

p

vv

DB DB'

Gegeben: Relationales Schema

Gesucht: XML-Sicht auf relationale DB und v

informationserhaltend

Export und Import von Daten aus bestehender relationaler Datenbasis

Selbstbeschreibendes Datenformat bei der Übertragung Keine Preisgabe interner Datenstrukturen

Page 123: 1 Teil I Datenmodelle Kapitel 9: Transformationen

123

Export von Daten als XMLVorgehensweise: Zugriff auf das gespeicherte Dokument erfolgt über eine

XML-Anfragesprache (etwa XPath oder XQuery). Die Abbildung setzt die Anfrage in SQL um und liest die

entsprechenden Daten aus der Datenbasis. Anschließend wird aus den gelesenen Werten das

resultierende XML-Dokument zusammengebaut und als Ergebnis der Benutzeranfrage zurückgegeben.

Page 124: 1 Teil I Datenmodelle Kapitel 9: Transformationen

124

Anfrageformulierung (1) Zwischensprache RXL (Relational to XML Transformation

Language)

from ArtikelArt $awhere $a.ANr = „A-001“construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel>

from ArtikelArt $awhere $a.ANr = „A-001“construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel>

From- und where-Klausel wie in SQL

Variable $a ist Iterator über ArtikelArt-Tupel

construct-Klausel legt Struktur des resultierenden XML-Dokuments fest

Anfrage

<artikel><nummer> A-001 </nummer><name> Anlasser </name><menge> 1 </menge>

</artikel>

<artikel><nummer> A-001 </nummer><name> Anlasser </name><menge> 1 </menge>

</artikel>

Ergebnis

XML

Page 125: 1 Teil I Datenmodelle Kapitel 9: Transformationen

125

Anfrageformulierung (1) Zwischensprache RXL (Relational to XML Transformation

Language)

from ArtikelArt $awhere $a.ANr = „A-001“construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel>

from ArtikelArt $awhere $a.ANr = „A-001“construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel>

Anfrage

<artikel><nummer> A-001 </nummer><name> Anlasser </name><menge> 1 </menge>

</artikel>

<artikel><nummer> A-001 </nummer><name> Anlasser </name><menge> 1 </menge>

</artikel>

Ergebnis

XML

2.00

0.05

0.10

1.00

0.50

Bosch

Mahle

Mahle

Mahle

Mahle

1

1

50

1

1

Anlasser

Kolben

Kolbenringe

Kurbelwelle

Nockenwelle

A-001

A-002

A-003

A-004

A-005

LieferantMengeANameANr

ArtikelArt

Gewicht

Page 126: 1 Teil I Datenmodelle Kapitel 9: Transformationen

126

Anfrageformulierung (2)

construct <artikelliste> {

} </artikelliste>

construct <artikelliste> {

} </artikelliste>

from Lagereinheit $leconstruct <artikel id=Artikel($le.ANr)> <lagereinheit id=LE($le.LeNr)> <nummer> $le.LeNr </nummer> <anzahl> $le.Stückzahl </anzahl> </lagereinheit> </artikel>

from ArtikelArt $aconstruct <artikel id=Artikel($a.ANr)> <nummer> $a.ANr </nummer> <name> $a.AName </name> </artikel>

Geschachtelte Anfragen möglich

Unabhängige Konstruktion von Elementteilen

<artikelliste><artikel id=„A-001“>

<nummer> A-001 </nummer><name> Anlasser </name>

<lagereinheit id=“LE-001”> <nummer> LE-001 </nummer> <anzahl> 2 </anzahl> </lagereinheit> <lagereinheit id=“LE-014”> <nummer> LE-014 </nummer> <anzahl> 1 </anzahl> </lagereinheit> </artikel> …</artikelliste>

<artikelliste><artikel id=„A-001“>

<nummer> A-001 </nummer><name> Anlasser </name>

<lagereinheit id=“LE-001”> <nummer> LE-001 </nummer> <anzahl> 2 </anzahl> </lagereinheit> <lagereinheit id=“LE-014”> <nummer> LE-014 </nummer> <anzahl> 1 </anzahl> </lagereinheit> </artikel> …</artikelliste> XML

Gruppierung über IDs

Page 127: 1 Teil I Datenmodelle Kapitel 9: Transformationen

127

Objektsichten XML Für den Export von Daten als XML-Dokument genügt meist

schon ein automatisches Verfahren: Relationen Objektsicht XML

Die Objekttypen geben hierbei die Struktur des resultierenden XML-Dokuments an.

Lagermanagement:

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

Lagermanagement:

relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht);

relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr);

class ArtikelArt {string ANr;string AName;float Menge;string Lieferant;float Gewicht;

}

class ArtikelArt {string ANr;string AName;float Menge;string Lieferant;float Gewicht;

}

class Lagereinheit {string LeNr;LagereinheitArt LeaNr;ArtikelArt ANr;long Stückzahl;float Gewicht;

Lagerhilfsmittel LhNr;}

class Lagereinheit {string LeNr;LagereinheitArt LeaNr;ArtikelArt ANr;long Stückzahl;float Gewicht;

Lagerhilfsmittel LhNr;}

Sichtenabbildung

Sichtenabbildung

Page 128: 1 Teil I Datenmodelle Kapitel 9: Transformationen

128

Auslesen als XML über Objektsichten

class ArtikelArt {string ANr;string AName;float Menge;string Lieferant;float Gewicht;

}

class ArtikelArt {string ANr;string AName;float Menge;string Lieferant;float Gewicht;

}

class Lagereinheit {string LeNr;LagereinheitArt LeaNr;ArtikelArt ANr;long Stückzahl;float Gewicht;

Lagerhilfsmittel LhNr;}

class Lagereinheit {string LeNr;LagereinheitArt LeaNr;ArtikelArt ANr;long Stückzahl;float Gewicht;

Lagerhilfsmittel LhNr;}

<rowset><Lagereinheit LeNr=„LE-001“>

<LagereinheitArt LeaNr=“LEA-02”> … </LagereinheitArt> <ArtikelArt ANr=“A-001”> <AName> Anlasser </AName> <Menge> 2 </Menge> <Lieferant> Bosch </Lieferant> <Gewicht> 2,00 </Gewicht> </ArtikelArt> <Stückzahl> 2 </Stückzahl> <Gewicht> 4,00 </Gewicht> <Lagerhilfsmittel LhNr=“LH-001”> … </Lagerhilfsmittel> </Lagereinheit> …</rowset>

<rowset><Lagereinheit LeNr=„LE-001“>

<LagereinheitArt LeaNr=“LEA-02”> … </LagereinheitArt> <ArtikelArt ANr=“A-001”> <AName> Anlasser </AName> <Menge> 2 </Menge> <Lieferant> Bosch </Lieferant> <Gewicht> 2,00 </Gewicht> </ArtikelArt> <Stückzahl> 2 </Stückzahl> <Gewicht> 4,00 </Gewicht> <Lagerhilfsmittel LhNr=“LH-001”> … </Lagerhilfsmittel> </Lagereinheit> …</rowset> XML

Objekttypen werden zu komplexen Elementen

Über Navigation erreichbare Objekte einbetten

Objektattribute werden zu Unterelementen

Beispiel: Auslesen aller Lagereinheiten