Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Kapitel 9: Transformationen

Ähnliche Präsentationen


Präsentation zum Thema: "Kapitel 9: Transformationen"—  Präsentation transkript:

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

2 Kapitel 9.1: Einführung

3 Vier-Stufen-Architektur
Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber

4 Problemstellungen (1) Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber 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.

5 Problemstellungen (2) Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber Die Anwendung wünscht sich oft eine problemangepasstere Struktur ihres Ausschnitts für einen bequemeren Zugriff.  Der Ausschnitt wird umstrukturiert.

6 Beispiel: Zugriffsbeschränkung
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); Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender 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); WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber

7 Problemstellungen (3) Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender XML WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware objektorientiert Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess relational Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber Jeder Dienstgeber will in der Wahl seines Datenmodells frei (autonom) sein.  Die Umstrukturierung kann Abbildungen zwischen Datenmodellen beinhalten.

8 Beispiel: Java 2 Enterprise Edition
Anwender Dienstnehmer Präsentation WWW-Dienstgeber Geschäftsprozess Anwendungs-Dienstgeber Ressourcen Datenlogik Dienstnehmer-Behälter HTTP WWW-Behälter EJB-Behälter JNDI JAF JDBC JTA JMS Konnektor Fremd-Behälter J2SE Java Servlets Java Server Pages Enterprise Java Bean Enterprise Java Bean RMI-IIOP RMI-IIOP JDBC Ressourcen-Verwalter Applet-Behälter HTTP JNDI JAF JDBC JTA JMS JNDI JAF JDBC JTA JMS J2SE J2SE J2SE JDBC Kommunikation (HTTP, IIOP, RMI, JDBC) Persistenzdienst Transaktionsdienst Sicherheitsdienst Namensdienst Nachrichtendienst

9 Problemstellungen (4) Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation XML Middleware Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber 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.

10 Beispiel: Austausch von Daten
Dienstnehmer Dienstnehmer . . . Dienstnehmer Anwender Lagermanagement: Arbeitet mit dem vollständigen Datenbestand. relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht); WWW-Dienstgeber . . . WWW-Dienstgeber Präsentation Middleware <artikelliste> <artikelart> <nummer> A001 </nummer> <name> Anlasser </name> <menge> 1 </menge> <lieferant> Bosch </lieferant> <gewicht> 2,00 </gewicht> </artikelart> </artikelliste> Export Anwendungs-Dienstgeber . . . Anwendungs-Dienstgeber Geschäftsprozess Import Ressourcen Datenbank-Dienstgeber . . . andere Dienstgeber Kunde: Arbeitet mit ArtikelArt-Objekten

11 Grundprinzip der Transformation
Materialisierte Sicht: Replizierter Ausschnitt Sicht-DB: Virtuelle Datenbasis Anwendung Anwendungsschema AS z.B. Anwendungs-Db ADB Abbildung v v‘ Weitere Anwendung Ausschnitt Sicht: Bedarfsweise Ausführung Quellschema S z.B. für Datenbasis DB Materialisierung: Einmalige (Vorab-) Ausführung

12 Sichten Sichten: 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.

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

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… ? AS Nicht erlaubt  Abbildungen, bei denen im Sichtschema undefinierte Elemente verwendet werden, sind nicht erlaubt. Forderung: Das Sichtschema muss in sich abgeschlossen sein. v S

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 v DB ADB ADB' o p v DB DB'

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' o Zustände der Sicht-Datenbasis Datenmodell: ADM v v Zustände der Original-Datenbasis Datenmodell: DM p DB DB'

17 Datenändernde Zugriffe
ADB ADB' v(DB‘) ? o = v v p DB DB' 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 Informationserhaltung beim Lesen trivial gegeben wegen o = p = id.

18 Leseoperationen ? = Seien DB' und ADB' gelesene Ausschnitte.
v(DB‘) ? o = v v p DB DB' 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)).

19 Kapitel 9.2: Sichten im relationalen Modell

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.

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); 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’(ArtikelArtAGewichtGewicht) ⋈ LagereinheitLeGewichtGewicht 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);

22 Beispielsichten (1) ArtikelArt pAName(ArtikelArt) ANr AName Menge
Lieferant Gewicht AName A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse

23 Beispielsichten (2) ArtikelArt pANr,AName(ArtikelArt) ANr AName Menge
Lieferant Gewicht ANr AName A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse

24 Beispielsichten (3) ArtikelArt sLieferant='Siemens'(ArtikelArt) ANr
AName Menge Lieferant Gewicht A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 sLieferant='Siemens'(ArtikelArt) ANr AName Menge Lieferant Gewicht A013 A014 A015 Zündkerzenkabel Zündkerzenstecker Zündspule 10 5 Siemens 0.80 2.50

25 Beispielsichten (4) Lagereinheit sGewicht>100.0(Lagereinheit) LeNr
LeaNr ANr Stückzahl Gewicht LhNr 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 LEA-04 LEA-02 LEA-01 LEA-05 LEA-03 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 2 20 42 175 3 6 85 30 1 13 16 4 12 4.00 20.00 21.00 175.00 4.50 0.30 212.50 15.00 6.00 5.20 16.00 12.00 2.00 3.00 105.00 LH-002 LH-006 LH-004 LH-007 LH-003 LH-005 LH-001 sGewicht>100.0(Lagereinheit) LeNr LeaNr ANr Stückzahl Gewicht LhNr LE-004 LE-007 LE-016 LEA-05 LEA-02 A-017 A-015 175 85 42 175.00 212.50 105.00 LH-006 LH-005

26 Beispielsichten (5) ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht ANr
AName Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr A-001 A-002 A-004 A-005 A-006 A-008 A-010 A-011 A-012 A-015 A-017 A-019 A-020 Anlasser Kolben Kurbelwelle Nockenwelle Ölwanne Ventile Ventilfedern Zündkerzen Zündspule Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 20 50 5 10 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 1.00 0.50 1.50 0.40 2.50 3.00 6.00 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 LEA-04 LEA-03 LEA-02 LEA-01 LEA-05 2 1 6 20 42 3 13 30 16 12 85 175 4 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 6.00 LH-001 LH-007 LH-002 LH-004 LH-003 LH-005 LH-006

27 Welche Art von Lagerhilfsmitteln ist zu meiden?
Beispielsichten (6) Lagereinheit LagerhilfsmittelArt LeNr LeaNr ANr Stückzahl Gewicht LhNr LhaNr LhaName Länge Breite Höhe MaxGewicht 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 LEA-04 LEA-02 LEA-01 LEA-05 LEA-03 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 2 20 42 175 3 6 85 30 1 13 16 4 12 4.00 20.00 21.00 175.00 4.50 0.30 212.50 15.00 6.00 5.20 16.00 12.00 2.00 3.00 105.00 LH-002 LH-006 LH-004 LH-007 LH-003 LH-005 LH-001 LHA-01 LHA-02 LHA-03 LHA-04 LHA-05 LHA-06 Holzpalette Leichte Holzpalette Displaypalette 1200 1000 800 600 800 600 400 100 115 150 500.00 350.00 300.00 200.00 150.00 Welche Art von Lagerhilfsmitteln ist zu meiden? Lagereinheit ⋈Gewicht³MaxGewicht LagerhilfsmittelArt LeNr LeaNr ANr2 Stückzahl Gewicht LhNr LhaNr LhaName Länge Breite Höhe MaxGewicht LE-007 LE-004 LEA-05 A-015 A-017 85 175 212.50 175.00 LH-006 LHA-05 LHA-06 Displaypalette 600 400 150 100 200.00 150.00

28 v = pAName(ArtikelArt)
Löschoperationen (1) ADB ADB' o = lösche(aname) v = pAName(ArtikelArt) v p?? DB DB' Löschen entspricht der relationenalgebraischen Differenz. Dann ergibt sich durch Einsetzen in die Informationserhaltungs-Regel die Forderung pAName(ArtikelArt) \ {(aname)} = pAName(p(ArtikelArt)) und somit p(ArtikelArt) = ArtikelArt \ {(w, aname, x, y, z)}. Fragestellung: Wie sind w, x, y und z richtig auszufüllen?

29 Löschoperationen (1) Sei aname = 'Zündkerzen‘
ArtikelArt pAName(ArtikelArt) ANr AName Menge Lieferant Gewicht AName A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 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.

30 v = pANr,AName(ArtikelArt)
Löschoperationen (2) ADB ADB' o = lösche(anr,aname) v = pANr,AName(ArtikelArt) v p?? DB DB' Es ergibt sich die Forderung pANr,AName (ArtikelArt) \ {(anr, aname)} = pANr,AName (p(ArtikelArt)) und somit p(ArtikelArt) = ArtikelArt \ {(anr, aname, x, y, z)}.

31 Löschoperationen (2) ArtikelArt pANr,AName(ArtikelArt) ANr AName Menge Lieferant Gewicht ANr AName A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse Ausfüllen eindeutig, da das Schlüsselattribut der Originalrelation in der Sicht vorhanden ist. (Beispiel: anr = 'A-001')

32 Löschoperationen (3) ADB ADB' o = lösche(anr,aname,menge,lieferant,gewicht) v = sLieferant='Siemens'(ArtikelArt) v p?? DB DB' Forderung: sLieferant='Siemens' (ArtikelArt) \ {(anr, aname, menge, lieferant, gewicht)} = sLieferant='Siemens' (p(ArtikelArt)) Für p ergibt sich: p(ArtikelArt) = ArtikelArt \ {(anr, aname, menge, lieferant, gewicht)}

33 Löschoperationen (3) Keine Probleme, da das Schlüsselattribut der Originalrelation in der Sicht vorhanden ist. ArtikelArt ANr AName Menge Lieferant Gewicht A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 sLieferant='Siemens'(ArtikelArt) ANr AName Menge Lieferant Gewicht A013 A014 A015 Zündkerzenkabel Zündkerzenstecker Zündspule 10 5 Siemens 0.80 2.50

34 Löschoperationen (4) v = sGewicht>100.0(Lagereinheit) Forderung:
ADB ADB' o = lösche(lenr,leanr,anr,stückzahl,gewicht,lhnr) v = sGewicht>100.0(Lagereinheit) v p?? DB DB' Forderung: sGewicht>100.0 (Lagereinheit) \ {(lenr,leanr,anr,stückzahl,gewicht,lhnr)} = sGewicht>100.0 (p(Lagereinheit)) Für p ergibt sich: p(Lagereinheit) = Lagereinheit \ {(lenr,leanr,anr,stückzahl,gewicht,lhnr)}

35 Löschoperationen (4) 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. Lagereinheit LeNr LeaNr ANr Stückzahl Gewicht LhNr 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 LEA-04 LEA-02 LEA-01 LEA-05 LEA-03 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 2 20 42 175 3 6 85 30 1 13 16 4 12 4.00 20.00 21.00 175.00 4.50 0.30 212.50 15.00 6.00 5.20 16.00 12.00 2.00 3.00 105.00 LH-002 LH-006 LH-004 LH-007 LH-003 LH-005 LH-001 sGewicht>100.0(Lagereinheit) LeNr LeaNr ANr Stückzahl Gewicht LhNr LE-004 LE-007 LE-016 LEA-05 LEA-02 A-017 A-015 175 85 42 175.00 212.50 105.00 LH-006 LH-005

36 v = ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht
Löschoperationen (5) ADB ADB' o = lösche(anr,lenr) v v = ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht p?? DB DB' Forderung: ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht \ {(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)}

37 Löschoperationen (5) ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht
ANr AName Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr A-001 A-002 A-004 A-005 A-006 A-008 A-010 A-011 A-012 A-015 A-017 A-019 A-020 Anlasser Kolben Kurbelwelle Nockenwelle Ölwanne Ventile Ventilfedern Zündkerzen Zündspule Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 20 50 5 10 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 1.00 0.50 1.50 0.40 2.50 3.00 6.00 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 LEA-04 LEA-03 LEA-02 LEA-01 LEA-05 2 1 6 20 42 3 13 30 16 12 85 175 4 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 6.00 LH-001 LH-007 LH-002 LH-004 LH-003 LH-005 LH-006 Beispiel: anr = 'A-001‘, lenr = ‘LE-001‘

38 v = ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht
Löschoperationen (5) ADB ADB' o = lösche(anr,lenr) v v = ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht p?? DB DB' Forderung: ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht \ {(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)}

39 Löschoperationen (5) ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht
ANr AName Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr A-001 A-002 A-004 A-005 A-006 A-008 A-010 A-011 A-012 A-015 A-017 A-019 A-020 Anlasser Kolben Kurbelwelle Nockenwelle Ölwanne Ventile Ventilfedern Zündkerzen Zündspule Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 20 50 5 10 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 1.00 0.50 1.50 0.40 2.50 3.00 6.00 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 LEA-04 LEA-03 LEA-02 LEA-01 LEA-05 2 1 6 20 42 3 13 30 16 12 85 175 4 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 6.00 LH-001 LH-007 LH-002 LH-004 LH-003 LH-005 LH-006 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.

40 Löschoperationen (6) ADB ADB' o = lösche(lenr,...,gewicht,lhnr,lhanr,...,maxgewicht) v v = Lagereinheit ⋈Gewicht³MaxGewichtLagerhilfsmittelArt p?? DB DB' Forderung: Lagereinheit ⋈Gewicht³MaxGewicht LagerhilfsmittelArt \ {(lenr,...,gewicht,lhnr,lhanr,...,maxgewicht)} = p1(Lagereinheit) ⋈Gewicht³MaxGewicht p2(LagerhilfsmittelArt) Problem: Keines der Schlüsselattribute der beiden Relationen ist am Join beteiligt.

41 Löschoperationen (6) Versuch 1:
LeNr LeaNr ANr2 Stückzahl Gewicht LhNr LhaNr LhaName Länge Breite Höhe MaxGewicht LE-007 LE-004 LEA-05 A-015 A-017 85 175 212.50 175.00 LH-006 LHA-05 LHA-06 Displaypalette 600 400 150 100 200.00 150.00 Versuch 1: Lösche Tupel aus beiden Relationen (Schlüssel gegeben!) Displaypalette LHA-05 LHA-06 LEA-05 LE-007 LE-004 LhaName LhaNr LeaNr LeNr A-015 A-017 ANr2 85 175 Stückzahl 212.50 175.00 Gewicht LH-006 LhNr MaxGewicht Höhe Breite Länge 600 400 150 100 200.00 150.00 Versuch 2: Lösche Tupel aus LagerhilfsmittelArt (Schlüssel gegeben!) Displaypalette LHA-05 LHA-06 LEA-05 LE-007 LE-004 LhaName LhaNr LeaNr LeNr A-015 A-017 ANr2 85 175 Stückzahl 212.50 175.00 Gewicht LH-006 LhNr MaxGewicht Höhe Breite Länge 600 400 150 100 200.00 150.00

42 Löschoperationen (6) Versuch 1:
LeNr LeaNr ANr2 Stückzahl Gewicht LhNr LhaNr LhaName Länge Breite Höhe MaxGewicht LE-007 LE-004 LEA-05 A-015 A-017 85 175 212.50 175.00 LH-006 LHA-05 LHA-06 Displaypalette 600 400 150 100 200.00 150.00 Versuch 1: Lösche Tupel aus beiden Relationen (Schlüssel gegeben!) Displaypalette LHA-05 LHA-06 LEA-05 LE-007 LE-004 LhaName LhaNr LeaNr LeNr A-015 A-017 ANr2 85 175 Stückzahl 212.50 175.00 Gewicht LH-006 LhNr MaxGewicht Höhe Breite Länge 600 400 150 100 200.00 150.00 Versuch 3: Lösche Tupel aus Lagereinheit (Schlüssel gegeben!) Displaypalette LHA-05 LHA-06 LEA-05 LE-007 LE-004 LhaName LhaNr LeaNr LeNr A-015 A-017 ANr2 85 175 Stückzahl 212.50 175.00 Gewicht LH-006 LhNr MaxGewicht Höhe Breite Länge 600 400 150 100 200.00 150.00

43 Einfügeoperationen (1)
ADB ADB' o = einfüge(anr,aname) v = pANr,AName(ArtikelArt) v p?? DB DB' Forderung: pANr,AName (ArtikelArt)  {(anr, aname)} = pANr,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.

44 Einfügeoperationen (1)
ArtikelArt pANr,AName(ArtikelArt) Anr AName Menge Lieferant Gewicht Anr AName A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse 1 50 20 10 5 Bosch Mahle Erzberg Pohlmann Osram Siemens 2.00 0.05 0.10 1.00 0.50 1.50 0.40 0.80 2.50 3.00 6.00 A001 A002 A003 A004 A005 A006 A007 A008 A009 A010 A011 A012 A013 A014 A015 A016 A017 A018 A019 A020 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle Ölwanne Pleuel Ventile Ventilfedern Zündkerzen Zündkerzenkabel Zündkerzenstecker Zündspule Zündverteiler Zylinderdichtung Zylinderkopf Zylinderkurbelgehäuse A Ölfilter NULL NULL NULL A Ölfilter Eindeutigkeit in Sicht lässt sich zurückführen auf Eindeutigkeit in Basisrelation

45 Einfügeoperationen (2)
ADB ADB' o = einfüge(aname) v = pAName(ArtikelArt) v p?? DB DB' Forderung: pAName (ArtikelArt)  {(aname)} = pAName (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.

46 Einfügeoperationen (3)
ADB ADB' o = einfüge(anr,aname,menge,lieferant,gewicht) v = sLieferant='Siemens'(ArtikelArt) v p?? DB DB' Forderung: sLieferant='Siemens' (ArtikelArt)  {(anr, aname, menge, lieferant, gewicht)} = sLieferant='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.

47 Einfügeoperationen (4)
ADB ADB' o = einfüge(anr,...,lenr,...) v v = ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht p?? DB DB' Forderung: ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht  {(anr,lenr)} = p1(ArtikelArt) ⋈ p2(Lagereinheit) Vermutung für p: - p1(ArtikelArt) = ArtikelArt  {(anr,...)} - p2(Lagereinheit) = Lagereinheit  {(lenr,...)}

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.

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.

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.

51 Informationserhaltung (3)
Spurgraph für pANr,AName(ArtikelArt). Spurgraph für pAName(ArtikelArt). ArtikelArt AName ANr Menge Lieferant Gewicht ArtikelArt AName ANr Menge Lieferant Gewicht

52 Informationserhaltung (4)
Spurgraph für ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht ArtikelArt Lagereinheit AName ANr Menge Lieferant Gewicht ANr LeNr LeaNr Stückzahl Gewicht LhNr AName ANr Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr

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

54 Informationserhaltung (6)
Spurgraph für ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht ArtikelArt Lagereinheit AName ANr Menge Lieferant Gewicht ANr LeNr LeaNr Stückzahl Gewicht LhNr AName ANr Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr Pfad Sichtspur

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.

56 Löschoperationen (2) delete(V,AName) mit AName = aname.
Spurgraph für pAName(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. ArtikelArt AName ANr Menge Lieferant Gewicht AName

57 Löschoperationen (3) Spurgraph für pANr, 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. ArtikelArt AName ANr Menge Lieferant Gewicht AName ANr

58 Löschoperationen (4) Spurgraph für ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht 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. ArtikelArt Lagereinheit AName ANr Menge Lieferant Gewicht ANr LeNr LeaNr Stückzahl Gewicht LhNr AName ANr Menge Lieferant Gewicht LeNr LeaNr Stückzahl LeGewicht LhNr

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

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 pD1({t}) = pD2({t}). 2. In der Menge der Ri muss (mindestens ein) Schlüssel Ki eine Sichtspur D besitzen, und pD({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 sÎV: Mit pDK({t}) = pDK({s}) folgt pDA({t}) = pDA({s}). Bed. 3 nicht aus dem Schema, sondern erst aus der Datenbasis zu bestimmen.

61 Einfügeoperationen (2)
K1 K2 A D1 D2 DK1 DK2 DA Konsistenzbed. 1 Konsistenzbed. 2 Konsistenzbed. 3

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 pAj({t}) ¹ NULL existiert für jede Basisrelation Ri ein Schlüssel Ki, so dass Ki v {Aj}.

63 Einfügeoperationen (3)
K1 K2 A D1 D2 DK1 DK2 DA Konsistenzbed. 1 Konsistenzbed. 2 Konsistenzbed. 3 Seiteneffektfreiheit (nur K2)

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 pDj({t}) ¹ NULL.

65 Einfügeoperationen (4)
K1 K2 A D1 D2 DK1 DK2 DA Konsistenzbed. 1 Konsistenzbed. 2 Konsistenzbed. 3 Seiteneffektfreiheit (nur K2) Eindeutigkeit

66 Einfügeoperationen (5)
Spurgraph für pANr,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). ArtikelArt AName ANr Menge Lieferant Gewicht AName ANr

67 Einfügeoperationen (6)
Spurgraph für pAName(ArtikelArt). insert(aname). Es wird gegen die zweite Bedingung zur Konsistenz verstoßen: Der Schlüssel ANr besitzt keine Sichtspur. ArtikelArt AName ANr Menge Lieferant Gewicht AName

68 Einfügeoperationen (7)
Spurgraph für ArtikelArt ⋈ LagereinheitLeGewicht¬Gewicht 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. ArtikelArt Lagereinheit AName ANr Menge Lieferant Gewicht ANr LeNr LeaNr Stückzahl Gewicht LhNr AName ANr Menge Lieferant Gewicht LeNr LeaNr Stückzahl Gewicht LhNr

69 Kapitel 9.3: Sichten in SQL

70 Vereinbarung 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, AName from ArtikelArt; create view SiemensArtikel as select  from ArtikelArt where Lieferant = 'Siemens'; create view SchwereLagereinheit as from Lagereinheit where Gewicht > 100.0;

71 Vereinbarung 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 Le where A.Anr = Le.ANr; create view UnzulässigeKombination as select  from Lagereinheit, LagerhilfsmittelArt where Gewicht  MaxGewicht; Selektionen, Projektionen, Join-Operationen, Gruppierung sind allesamt möglich.

72 Vereinbarung 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 as select A.ANr, AName, sum(Stückzahl) from ArtikelArt A, Lagereinheit Le where A.Anr = Le.ANr and Lieferant = 'Lieferant' group by A.ANr having sum(Stückzahl) >= all ( select sum(Stückzahl) group by A.Anr ); SQL-Prozeduren sind nur ein Notbehelf!

73 Informationserhaltung
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.

74 Objektorientierte Sichten auf relationale Daten
Kapitel 9.4: Objektorientierte Sichten auf relationale Daten

75 Beispiel: Java 2 Enterprise Edition
Anwender Dienstnehmer Präsentation WWW-Dienstgeber Geschäftsprozess Anwendungs-Dienstgeber Ressourcen Datenlogik objektorientiert (Java) Dienstnehmer-Behälter HTTP WWW-Behälter EJB-Behälter JNDI JAF JDBC JTA JMS Konnektor Fremd-Behälter J2SE Java Servlets Java Server Pages Enterprise Java Bean Enterprise Java Bean RMI-IIOP relational RMI-IIOP JDBC Ressourcen-Verwalter Applet-Behälter HTTP JNDI JAF JDBC JTA JMS JNDI JAF JDBC JTA JMS J2SE J2SE J2SE JDBC Kommunikation (HTTP, IIOP, RMI, JDBC) Persistenzdienst Transaktionsdienst Sicherheitsdienst Namensdienst Nachrichtendienst

76 Gesucht: Relationales Schema und v informationserhaltend
Dauerhafte Objekte ADB ADB' o p v DB DB' Gegeben: oo-Schema Gesucht: Relationales Schema und v informationserhaltend 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.

77 Abbildung Die unterschiedliche Ausdrucksmächtigkeit der beiden Datenmodelle bereitet Probleme bei der Abbildung. Abzubildende Konzepte sind: Objektidentität Objektverweise Mengenkonstruktion Typhierarchien (Vererbung)

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.

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.

80 Beispiel (1) Objektorientiertes 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 }; 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);

81 Beispiel (2) class 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 }; Relationen: Trivial, da Schlüssel gegeben. Attribute nur atomar oder Verweise relation Lagerort(LoNr, LoaNr, Gewicht); relation LagerortArt(LoaNr, Länge, Breite, Höhe, MaxGewicht); relation Verträglichkeit(ANr, LoNr);

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.

83 Beispiel (3) Bidirektional: Beschreibt gleichen Sachverhalt
Punkt (PSurr, x, y, z) 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; class Fläche { attribute set<Kante> kanten; relationship set<Vielflächner> körper inverse Vielflächner::flächen; 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(); Kante (KSurr, PSurr1, PSurr2) Vielflächner (VName) Flächen (FSurr, VName) Bidirektional: Beschreibt gleichen Sachverhalt Fläche (FSurr) Kanten (KSurr, FSurr) Körper (VName, FSurr) (lokaler) Fremdschlüssel

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

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.

86 Typhierarchien 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.

87 Beispiel Objektorientiertes 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 { }; Lagereinrichtung Lagerort Lagerhilfsmittel Lagereinheit

88 Abbilden von Typhierarchien (1)
Option 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. relation Lagereinrichtung (Nr, Art, Gewicht); relation Lagereinheit(Nr, ANr, Stückzahl, LhNr); relation Lagerhilfsmittel(Nr, LoNr) relation Lagerort(Nr) Lagereinrichtung Lagerort Lagerhilfsmittel Lagereinheit 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.

89 Abbilden von Typhierarchien (2)
Option 2: Jeder Objekttyp einer Typhierarchie bildet eine eigene Relation. Jetzt werden jedoch mit einer Relation sämtliche, also auch die ererbten Attribute aufgenommen. 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) Lagereinrichtung Lagerort Lagerhilfsmittel Lagereinheit 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.

90 Abbilden von Typhierarchien (3)
Option 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. relation Lagereinheit(Nr, Art, Gewicht, ANr, Stückzahl, LhNr); relation Lagerhilfsmittel(Nr, Art, Gewicht, LoNr) relation Lagerort(Nr, Art, Gewicht) Lagereinrichtung Lagerort Lagerhilfsmittel Lagereinheit 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.

91 Abbilden von Typhierarchien (4)
Option 4: Die gesamte Generalisierungshierarchie fällt in einer einzigen Relation für die Wurzel zusammen. Lagereinrichtung Lagerort Lagerhilfsmittel Lagereinheit 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.

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.

93 Beispiel: Java 2 Enterprise Edition
Anwender Dienstnehmer Präsentation WWW-Dienstgeber Geschäftsprozess Anwendungs-Dienstgeber Ressourcen Datenlogik objektorientiert (Java) Dienstnehmer-Behälter HTTP WWW-Behälter EJB-Behälter JNDI JAF JDBC JTA JMS Konnektor Fremd-Behälter J2SE Java Servlets Java Server Pages Enterprise Java Bean Enterprise Java Bean RMI-IIOP relational RMI-IIOP JDBC Ressourcen-Verwalter Applet-Behälter HTTP JNDI JAF JDBC JTA JMS JNDI JAF JDBC JTA JMS J2SE J2SE J2SE JDBC Kommunikation (HTTP, IIOP, RMI, JDBC) Persistenzdienst Transaktionsdienst Sicherheitsdienst Namensdienst Nachrichtendienst

94 Gegeben: Relationales Schema
Objektsichten Gesucht: Objektsicht auf relationale DB (oo-Schema und v informationserhaltend) ADB ADB' o p v DB DB' Gegeben: Relationales Schema 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.

95 Manuelle Konstruktion
Erscheinungsbild als Klasse angeben class ArtikelArt { string AName; float Menge; } Konstruktion der Ausprägung (Sicht) Objekttyp angeben Objektidentität festlegen create view AV of ArtikelArt with oid(ANr) as select ANr, AName, Menge from ArtikelArt Attributwerte füllen 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);

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 Schritt 2: Beziehungs-Relationstypen: Alle anderen Relationstypen bilden Beziehungs-Relationstypen.

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.

98 Kanonische Konstruktion (3)
Schritt 5: Referenzielle Konsistenzen: Fremdschlüssel in Objekttypen werden durch relationship/inverse gekennzeichnet.

99 Beispiel (1) Abbildung:
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); 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.

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; LeaNr: LagereinheitArt; ANr: ArtikelArt; Stückzahl: Integer; 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; Länge: Integer; Breite: Integer; Höhe: Integer; MaxGewicht: Float };

101 Kapitel 9.5: XML-Sichten auf relationale Daten

102 Dauerhafte XML-Dokumente
Aufgaben: 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

103 Basis Textdokument (1) Interpretation eines XML-Dokumentes … XML
…als fortlaufenden Text und speichern dieses Textes in einem Attribut einer Relation. DBLP.xml <?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 Bibliography BibID PaperList DBLP <?xml version="1.0"?><bib> <paper id = "o12" ><title>Fo undations of Databases</titl e><author><firstname>Serge</firstname><lastname>Abiteboul</lastname></author><year>1997</year><publisher> Addison Wesley</publi sher></paper>…

104 Basis Textdokument (2) Vorteile des Verfahrens: Nachteile:
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

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.

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 1 2 3 bib paper o12 id Foundations… title 4 author Serge firstname Abiteboul 1997 year Addison… publisher lastname

107 Basis Dokumentgraph (3)
1 2 3 bib paper o12 id Foundations… title 4 author Serge firstname Abiteboul 1997 year publisher lastname Addison… Kanten Beginn Reihenf. Name IstText Ziel/Wert 1 2 3 4 1 2 3 4 5 bib paper id title author firstname lastname year publisher nein ja 2 3 o12 Foundations… 4 Serge Abiteboul 1997 Addison… Bei Bedarf zusätzliches Attribut, um XML-Attribut und XML-Element unterscheiden zu können

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.

109 Gesucht: Relationales Schema und v informationserhaltend
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 v DB DB' Gegeben: XML-Schema Gesucht: Relationales Schema und v informationserhaltend

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. <?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 <!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

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.

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.

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.

114 Abbildung mit Gruppierung
2. Idee: XML-Elemente gruppieren  Relationstyp Reduktion der Komplexität einer DTD z.B. <!ELEMENT a ((b|c|e)?,(e?|(f?,(b,b)*))*)> vereinfachen Aus der DTD wird ein DTD-Graph generiert, der die 1:1- bzw. 1:n-Beziehungen zwischen XML-Elementen modelliert. Generierung der Relationstypen durch Unterteilung der Graphstruktur.

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

116 Komplexität einer DTD DTD 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)> ]> 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)> ]> DTD

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.

118 Strukturinformation DTD-Graph <!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)> ]> bib DTD-Graph * paper ? * id title year publisher author age firstname lastname

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.

120 Relationstypen erzeugen
relation Bib (bibID) bib * relation Paper (paperID, bibID, id, title, year, publisher) paper ? * id title year publisher relation Author (authorID, paperID, age, firstname, lastname ) author age firstname lastname

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.

122 Datenaustausch auf Basis von XML
Gesucht: XML-Sicht auf relationale DB und v informationserhaltend ADB ADB' o p v DB DB' Gegeben: Relationales Schema Export und Import von Daten aus bestehender relationaler Datenbasis Selbstbeschreibendes Datenformat bei der Übertragung Keine Preisgabe interner Datenstrukturen

123 Export von Daten als XML
Vorgehensweise: 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.

124 Anfrageformulierung (1)
Zwischensprache RXL (Relational to XML Transformation Language) From- und where-Klausel wie in SQL Variable $a ist Iterator über ArtikelArt-Tupel construct-Klausel legt Struktur des resultierenden XML-Dokuments fest from ArtikelArt $a where $a.ANr = „A-001“ construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel> <artikel> <nummer> A-001 </nummer> <name> Anlasser </name> <menge> 1 </menge> </artikel> Ergebnis XML Anfrage

125 Anfrageformulierung (1)
Zwischensprache RXL (Relational to XML Transformation Language) 2.00 0.05 0.10 1.00 0.50 Bosch Mahle 1 50 Anlasser Kolben Kolbenringe Kurbelwelle Nockenwelle A-001 A-002 A-003 A-004 A-005 Lieferant Menge AName ANr ArtikelArt Gewicht from ArtikelArt $a where $a.ANr = „A-001“ construct <artikel> <nummer> $a.ANr </nummer> <name> $a.AName </name> <menge> $a.Menge </menge> </artikel> <artikel> <nummer> A-001 </nummer> <name> Anlasser </name> <menge> 1 </menge> </artikel> Ergebnis XML Anfrage

126 Anfrageformulierung (2)
Geschachtelte Anfragen möglich Unabhängige Konstruktion von Elementteilen Gruppierung über IDs construct <artikelliste> { } </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 from ArtikelArt $a construct <artikel id=Artikel($a.ANr)> <nummer> $a.ANr </nummer> <name> $a.AName </name> </artikel> from Lagereinheit $le construct <artikel id=Artikel($le.ANr)> <lagereinheit id=LE($le.LeNr)> <nummer> $le.LeNr </nummer> <anzahl> $le.Stückzahl </anzahl> </lagereinheit> </artikel>

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. 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; } Sichtenabbildung Lagermanagement: relation ArtikelArt(ANr, AName, Menge, Lieferant, Gewicht); relation Lagereinheit(LeNr, LeaNr, ANr, Stückzahl, Gewicht, LhNr); Sichtenabbildung

128 Auslesen als XML über Objektsichten
Beispiel: Auslesen aller Lagereinheiten Objekttypen werden zu komplexen Elementen <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 class Lagereinheit { string LeNr; LagereinheitArt LeaNr; ArtikelArt ANr; long Stückzahl; float Gewicht; Lagerhilfsmittel LhNr; } Über Navigation erreichbare Objekte einbetten class ArtikelArt { string ANr; string AName; float Menge; string Lieferant; float Gewicht; } Objektattribute werden zu Unterelementen


Herunterladen ppt "Kapitel 9: Transformationen"

Ähnliche Präsentationen


Google-Anzeigen