Datenintegration & Datenherkunft Global-as-View (GaV) und Local-as-View (LaV)
|
|
- Wilhelm Meinhardt
- vor 7 Jahren
- Abrufe
Transkript
1 Datenintegration & Datenherkunft Global-as-View (GaV) und Local-as-View (LaV) Wintersemester 2010/11 Melanie Herschel Lehrstuhl für Datenbanksysteme, Universität Tübingen 1 Ausblick auf das Semester Problemstellungen Einführung in die Informationsintegration Verteilung, Autonomie und Heterogenität Architekturen Materialisierte und virtuelle Integration 5 Schichten Architektur Mediator/Wrapper Architektur P2P Architektur Schema Mapping Schema Matching Mapping 2
2 Ausblick auf das Semester Modellierung Global-As-View Modellierung Local-As-View Modellierung Anfragen Global-As-View Anfragebearbeitung Containment und Local-As-View Anfragebearbeitung Bucket Algorithmus Datenintegration Duplikaterkennung Datenfusion Datenherkunft (Data Provenance) Why-, How-, und Where-Provenance Datenherkunft fehlender Daten 3 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 4
3 Das Problem Anwendung 1 Anwendung 2 Data Warehouse (DW) Wie spezifiziert man die Datentransformationen? ETL1 ETL2 ETL3 Quelle 1 Quelle 2 Quelle 3 5 Das Problem Anwendung 1 Anwendung 2 Wie drückt man die Funktionalität des Wrappers aus? Mediator Wrapper1 Wrapper2 Wrapper3 Quelle 1 Quelle 2 Quelle 3 6
4 Anfrageplanung Schema Integration Query processing Query planning Decomposition Translation Result Integration Wenn das integrierte System ein globales Schema zur Verfügung stellt Wie beschreibt man die Beziehungen zwischen dem globalen und den verschiedenen lokalen Schemata?! Siehe Schema Matching / Schema Mapping Kapitel Wie benutzt man diese Beziehungen zur Anfrageplanung?! Besprechen wir hier 7 Aufgabe Korrespondenzen Exportschema/ lokales Schema Aufgabe der Anfragebearbeitung Gegeben eine Anfrage q gegen das globale Schema Gegeben eine Menge von Korrespondenzen zwischen globalem und lokalen Schemata Finde alle Antworten auf q. 8
5 Anfragebearbeitung Schritt 1: Anfrageplanung Welche Quellen können / sollen / müssen benutzt werden? Welche Teile der Anfrage sollen an welche Quelle geschickt werden? Schritt 2: Anfrageübersetzung Übersetzung aus der Sprache der Föderation in die Sprache der Quellen Schritt 3: Anfrageoptimierung Finde geeignete Reihenfolge der Ausführung der Teilanfragen Wer führt was aus (Pushen)? Wer kann was ausführen (Kompensation)? Schritt 4: Anfrageausführung Monitoring, Puffern, Cachen Dynamische Reoptimierung Schritt 5: Ergebnisintegration Duplikaterkennung und Konfliktauflösung 9 Beispiel Beispeil aus der Filmwelt Vereinfachende Annahmen Quellen bestehen nur aus einer (Export-)Relation. Keine Datenmodellheterogenität! Nehmen wir jetzt immer an! Aufgabe des Wrappers Zunächst vereinfachend: Keine strukturelle oder schematische Heterogenität Keine semantische Heterogenität! Gleiche Namen = gleiche Konzepte! Nur offensichtliche Schreibvarianten (Sprachunterschiede) 10
6 Beispiel Datenquellen film(titel, regisseur) schauspieler (schauspieler_name, nationalitaet) spielt (titel, schauspieler_name, rolle) Datenquelle & exportierte Relation Beschreibung Globale Relation imdb.movie (titel, director) Alle Filme der IMDB film imdb.acts(title, actor_name, role) Zuordnung von Schauspielern zu Filmen der IMDB spielt imdb.actor (actor_name, nationality) Alle Schauspieler der IMDB schauspieler fd.film(titel, regisseur) Alle Filme des Filmdienstes film fd.spielt (titel, schauspieler_name, rolle) fd.schauspieler(schauspieler_name, nationalitaet) Zuordnung von Schauspielern zu Filmen des Filmdienstes Alle Schauspieler des Filmdienstes spielt schauspieler 11 Schritt 1: Anfrageplanung Globale Anfrage Alle Filme, in denen Hans Albers eine Hauptrolle spielte SELECT titel, regisseur, rolle FROM film, spielt WHERE spielt.schauspieler_name = Hans Albers AND spielt.rolle = Hauptrolle AND spielt.titel = film.titel Welche Quellen kommen infrage? film:! Quellen imdb.movie und fd.film spielt:! Quellen imdb.acts und fd.spielt Ergibt vier Anfragepläne 12
7 Vier Anfragepläne Jeder Plan besteht aus zwei Teilplänen Auch p 1 und p 4 Jeder Teilplan ist quellspezifisch Kann von einer Quelle ausgeführt werden Wer führt die Joins zwischen den Teilplänen aus? System kann auswählen Alle Pläne? (teuer, vollständig) Schnellster Plan? Billigster Plan? Plan mit dem größten Ergebnis? 13 FAQ Kann man nicht imdb.movie imdb.acts gemeinsam betrachten? Doch aber wir nehmen noch Quelle = 1 Relation an Später (GaV) Warum sollte man imdb.movie und fd.spielt zusammen in einem Plan benutzen? Weil Quellen Fehler (fehlende Werte) enthalten Kombination kann neue (und wichtige!) Tupel produzieren Annahme: Gleiche Werte in den Joinattributen! Hier: Filmnamen, Schauspielernamen Vorsicht vor impliziten Konsistenzannahmen 14
8 Beispiel SELECT titel, regisseur, rolle FROM film, spielt WHERE spielt.schauspieler_name = Hans Albers AND spielt.rolle = Hauptrolle AND spielt.titel = film.titel Imdb.movie Vögel, Hitchcock Münchhausen, von Baky Imdb.acts Vögel, Kelly, Hauptrolle Münchhausen, Bendow, Nebenrolle fd.film Vögel, Hitchcock Münchhausen, Bürger fd.spielt Vögel, Kelly, Hauptrolle Münchhausen, Albers, Hauptrolle Movie! acts movie! spielt film acts film! spielt - Münchhausen, van Baky, Hauptrolle - Münchhausen, Bürger, Hauptrolle 15 Schritt 2: Anfrageübersetzung Jeder Teilplan kann an genau eine Quelle geschickt werden. Übersetzung der Schemaelementnamen Übersetzung einer SQL Anfrage in einen Web-Service, HTTP-Aufruf, XQuery, Übersetzung von Konstanten in einer Query - Was heißt Hauptrolle in der imdb? Anfrageübersetzung SELECT!titel, rolle FROM! spielt WHERE!schauspieler_name= Hans Albers AND! rolle= Hauptrolle??? SELECT!title, role FROM! imdb.acts WHERE!actor_name= Hans Albers AND! role= main role SELECT!title, role FROM! imdb.acts WHERE!actor_name= Hans Albers 16
9 Schritt 3: Anfrageoptimierung Lokale Optimierung: Jeder Plan einzeln Globale Optimierung: Gesamtmenge aller Pläne gemeinsam betrachten Fragen Optimale Reihenfolge der Ausführung der Teilpläne? Möglicherweise parallele Ausführung? Selektionsbedingungen global oder lokal prüfen? Teilpläne TP1: SELECT! title, director FROM! imdb.movie; TP2: SELECT! title, role FROM! imdb.acts WHERE! actor_name= Hans Albers AND! role= main role ; 17 Anfrageoptimierung - Möglichkeiten Erst TP1, dann TP2, dann Join im Mediator Verlangt nach Download aller Filme der IMDB Vermutlich sehr teuer Besser: TP1 und TP2 parallel Ergebnis von TP1 ist für TP2 unerheblich Immer noch sehr teuer Erst TP2, dann TP1 umschreiben, Join im Mediator TP2: nur wenige Tupel Pushen dieser Tupel an TP1 WHERE TITLE in ( )! Passing bindings Keine Parallelisierung mehr möglich Viel kleinere Zwischenergebnisse, vermutlich viel schneller Teilpläne TP1: SELECT! title, director FROM! imdb.movie; TP2: SELECT! title, role FROM! imdb.acts WHERE! actor_name= Hans Albers AND! role= main role ; 18
10 Schritt 4: Anfrageausführung Jeder der vier Pläne wurde optimiert und übersetzt Teilpläne müssen ausgeführt werden Anfrage abschicken, Ergebnis abwarten, lokal puffern Time-Outs überwachen Müssen alle Teilpläne ausgeführt werden?! Wenn wir P1-P4 betrachten und keine Joinbedingungen pushen können! Ergibt 8 Teilpläne - aber nur 4 verschiedene Teilpläne! Optimierungspotential! Entweder global optimieren oder dynamisch durch Caching erkennen Fehlende Operationen müssen im Mediator ausgeführt werden. Nicht-pushbare Selektionen Joins zwischen Relationen verschiedener Quellen 19 Ergebnisintegration Jeder Plan liefert eine Menge korrekter Ergebnisse. Trotzdem kann es Probleme geben Duplikate: Objekte sind in mehreren Quellen vorhanden Konflikte: Objekte sind mehrmals mit widersprüchlichen Angaben vorhanden Anfrageübersetzung Imdb.movie Vögel, Hitchcock Münchhausen, von Baky Imdb.acts Vögel, Kelly, Hauptrolle Münchhausen, Bendow, Nebenrolle fd.film Vögel, Hitchcock Münchhausen, Bürger! UNION! UNION - Münchhausen, Bürger, Hauptrolle Münchhausen, von Baky, Hauptrolle - fd.spielt Vögel, Kelly, Hauptrolle Münchhausen, Albers, Hauptrolle 20
11 Modellierung von Datenquellen Kernidee Modellierung strukturell heterogener Quellen in Bezug auf ein globales Schema als Views (Sichten) Relationales Modell Allgemein: Eine Sicht verknüpft mehrere Relationen und produziert eine Relation. Sichten zur Verknüpfung von Schemata Sicht definiert auf Relationen eines Schemas und produziert eine Relation des anderen Schemas Jetzt: Unterscheidung lokales und globales Schema 21 Global as View / Local as View Global as View Relationen des globalen Schemas werden als Sichten auf die lokalen Schemas der Quellen ausgedrückt. Local as View Relationen der Schemas der Quellen werden als Sichten auf das globale Schema ausgedrückt. 22
12 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 23 Global as View (GaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S1: IMDB(Titel, Regie, Jahr, Genre) S2: MyMovies(Titel, Regie, Jahr, Genre) S3: RegieDB(Titel, Regie) S4: GenreDB(Titel, Jahr, Genre) CREATE VIEW Film AS SELECT * FROM IMDB Typisches Merkmal bei GaV SELECT * FROM MyMovies SELECT RegieDB.Titel, RegieDB.Regie, GenreDB.Jahr, GenreDB.Genre FROM RegieDB, GenreDB WHERE RegieDB.Titel = GenreDB.Titel Join über mehrere Quellen (Anfragebearbeitung!) Quelle: VL Data Integration, Alon Halevy, University of Washington,
13 Zwei Arten von GaV Regel Einfache GaV Regeln: Quellspezifisch Lokale Anfrage adressiert nur eine Quelle Verknüpfung über Quellen hinweg übernimmt die Anfrageplanung Besser wartbar (Änderung einer Quelle kann nur wenige Sichten betreffen) Einfacher zu erweitern (bestehende Views nicht anfassen) Komplexe GaV Regeln: Quellübergreifend Lokale Anfrage ist eine Anfrage in einer Multidatenbanksprache Eine Sicht fasst alle Objekte einer globalen Relation zusammen! Sicht film, schauspieler, Anfrageplanung übernimmt nur noch Verknüpfung zwischen verschiedenen Relationen, d.h., Joins in der globalen Anfrage Weniger robust, schwerer zu erweitern! Änderung einer Quelle kann alle Sichten betreffen Konfliktlösung kann in den View eingebaut werden 25 Global as View (GaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S5: MDB(Titel, Regie, Jahr) S6: MovDB(Titel, Regie, Genre) CREATE VIEW Film AS SELECT Titel, Regie, Jahr, NULL AS Genre FROM MDB SELECT Titel, Regie, NULL AS Jahr, Genre FROM MovDB Fehlende Attribute Form des Ergebnisses; Datenfusion Quelle: VL Data Integration, Alon Halevy, University of Washington,
14 Global as View (GaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S7: KinoDB(Kino, Genre) Problem: Assoziationen werden getrennt Da Ergebnis einer Sicht nur eine globale Relation sein kann Lösung: Skolemfunktionen Tritt auf, wenn CREATE VIEW Film AS SELECT NULL, NULL, NULL, Genre FROM KinoDB CREATE VIEW Programm AS SELECT Kino, NULL, NULL FROM KinoDB Attribute verschiedener globaler Relationen in einer lokalen Relation liegen und der verbindende Key/FK lokal nicht existiert Quelle: VL Data Integration, Nicht im umgekehrten Fall: einfach lokale Relationen joinen Alon Halevy, University of Washington, Vorschau: Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S7: KinoDB(Kino, Genre) CREATE VIEW S7 AS SELECT Programm.Kino, Film.Genre FROM Film, Programm WHERE Film.Titel = Programm.Titel Umgekehrte Betrachtung Assoziationen bleiben erhalten Titel wird zwar nie instantiiert, aber man weiß, dass es einen verbindenden Titel gibt
15 Integritätsconstraints (ICs) Schränken Wertebereiche ein, schließen Werte aus, schließen Kombinationen von Werten aus,... Dienen zur näheren Bestimmung der Intension einer Relation: teure_autos( auto, preis ), preis> golfclub_mitglieder( name, alter ), alter>55 film( title, type ), type {spielfilm, doku, kurzfilm} Für die Integration sehr wichtig 29 Global as View (GaV) Gobale ICs NeuerFilm(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) IC: Jahr > 2000 S1: IMDB(Titel, Regie, Jahr, Genre) S2: MyMovies(Titel, Regie, Jahr, Genre) CREATE VIEW NeuerFilm AS SELECT * FROM IMDB WHERE Jahr > 2000 SELECT * FROM MyMovies WHERE Jahr > 2000 IC auf globalem Schema kann in diesem Fall in die Sichtdefinition aufgenommen werden Ausführung in der Quelle (push) oder im Mediator 30
16 Probleme mit globalen IC Neuerfilm( Titel, Regie, Jahr, Genre); Programm( Kino, Titel, Zeit); IC: Jahr > 2000 S1: IMDB( Titel, Regie, Jahr, Genre) S2: MyOldOrNewMovies( Titel, Regie) CREATE VIEW NeuerFilm AS SELECT!* FROM! IMDB WHERE!Jahr > 2000 SELECT Titel, Regie, NULL, NULL FROM! MyOldOrNewMovies WHERE!?? Quelle gibt keine Jahr-Informationen IC auf globalem Schema kann nicht überprüft werden Quelle kann nicht integriert werden 31 Global as View (GaV) globale ICs NeuerFilm(Titel, Regie, Jahr, Genre) Nebenbedingung: Jahr > 2000 oder NeuerFilm(Titel, Regie, Genre) Nebenbedingung: Jahr > 2000 Lokale Schemas S1: AlleFilmeNett(Titel, Regie, Jahr, Genre) S2: AlleFilmeBöse(Titel, Regie, Genre) CREATE VIEW NeuerFilm AS SELECT * FROM AlleFilmeNett Quelle S2 kann nicht WHERE Jahr > 2000 modelliert werden!! oder CREATE VIEW NeuerFilm AS SELECT Titel, Regie, Genre FROM AlleFilmeNett WHERE Jahr >
17 Global as View (GaV) Lokale ICs Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S8: NeueFilme(Titel,Regie, Genre) (IC: Jahr > 2000) CREATE VIEW Film AS SELECT Titel, Regie, NULL, Genre FROM NeueFilme Bekannte Nebenbedingung auf der Quelle kann nicht modelliert werden. Warum ist das schlecht? SELECT * FROM film WHERE jahr < Trick Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S8: NeueFilme( Titel, Regie, Jahr, Genre) IC: Jahr > 2000 CREATE VIEW Film AS SELECT!Titel, Regie, Jahr, Genre FROM! NeueFilme WHERE!Jahr > 2000 IC in Quelle wird modelliert (Geht nur, wenn das Attribut in der Quelle instantiiert wird) Die Bedingung ändert am Ergebnis nichts Für eine lokale Anfrage wäre sie sinnlos Aber sie hilft dem Anfrageplaner SELECT * FROM film WHERE jahr <
18 Global as View (GaV) lokale ICs Film(Titel, Regie, Jahr, Genre) Lokale Schemas S1: AlleFilmeNett(Titel, Regie, Jahr, Genre) S2: AlleFilmeBöse(Titel, Regie, Genre) S3: NeueFilmeNett(Titel, Regie, Jahr, Genre) (Nebenbedingung: Jahr > 2000) S4: NeueFilmeBöse(Titel, Regie, Genre) (Nebenbedingung: Jahr > 2000) S5: AktuelleFilme(Titel, Regie, Genre) (Nebenbedingung: Jahr = 2010) Jede Quelle kann modelliert werden! Jede Sicht exportiert alle Daten der Quelle! CREATE VIEW Film AS SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett (WHERE Jahr > 2000) SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, `2010, Genre FROM AktuelleFilme 35 Modellierung nur für Optimierung Global as View (GaV) ICs Film(Titel, Regie, Jahr, Genre) CREATE VIEW Film AS SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett WHERE Jahr > 2000 SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, 2004, Genre FROM AktuelleFilme Anfrage: SELECT * FROM Film SELECT * FROM (SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett WHERE Jahr > 2000 SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, 2004, Genre FROM AktuelleFilme) 36 45
19 Global as View (GaV) ICs Film(Titel, Regie, Jahr, Genre) SELECT * FROM (SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett (WHERE Jahr > 2000) SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, 2004, Genre FROM AktuelleFilme) WHERE Jahr > 2001 Anfrage: SELECT * FROM Film WHERE Jahr > 2001 Trägt voll zum Ergebnis bei Trägt nicht zum Ergebnis bei, obwohl nützlich Trägt voll zum Ergebnis bei Trägt nicht zum Ergebnis bei, obwohl nützlich Trägt voll zum Ergebnis bei 37 Global as View (GaV) ICs Film(Titel, Regie, Jahr, Genre) SELECT * FROM (SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett WHERE Jahr > 2000 SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, 2004, Genre FROM AktuelleFilme) WHERE Jahr = 2001 Anfrage: SELECT * FROM Film WHERE Jahr = 2001 Trägt voll zum Ergebnis bei Trägt nicht zum Ergebnis bei, obwohl nützlich Trägt voll zum Ergebnis bei Trägt nicht zum Ergebnis bei, obwohl nützlich Trägt nicht zum Ergebnis bei (2001 " 2004) 38
20 Global as View (GaV) ICs Film(Titel, Regie, Jahr, Genre) SELECT * FROM (SELECT * FROM AlleFilmeNett SELECT Titel, Regie, NULL, Genre FROM AlleFilmeBöse SELECT * FROM NeueFilmeNett WHERE Jahr > 2000 SELECT Titel, Regie, NULL, Genre FROM NeueFilmeBöse SELECT Titel, Regie, 2004, Genre FROM AktuelleFilme) WHERE Jahr < 1950 Anfrage: SELECT * FROM Film WHERE Jahr < 1950 Beiträge zum Ergebnis 39 Global as View (GaV) globale und lokale ICs NeuerFilm(Titel, Regie, Genre) Nebenbedingung: Jahr > 2000 Lokale Schemas S1: AlleFilmeNett(Titel, Regie, Jahr, Genre) S2: AlleFilmeBöse(Titel, Regie, Genre) S3: NeueFilmeNett(Titel, Regie, Jahr, Genre) (Nebenbedingung: Jahr > 2000) S4: NeueFilmeBöse(Titel, Regie, Genre) (Nebenbedingung: Jahr > 2000) S5: AktuelleFilme(Titel, Regie, Genre) (Nebenbedingung: Jahr = 2004) Quelle S2 kann nicht modelliert werden! CREATE VIEW NeuerFilm AS SELECT Titel, Regie, Genre FROM AlleFilmeNett WHERE Jahr > 2000??? SELECT Titel, Regie, Genre FROM NeueFilmeNett (WHERE Jahr > 2000) SELECT Titel, Regie, Genre FROM NeueFilmeBöse SELECT Titel, Regie, Genre FROM AktuelleFilme 40
21 Global as View (GaV) ICs Fazit Nebenbedingungen (ICs) im globalen Schema können die Integration von Quellen verhindern, wenn die Bedingung nicht geprüft werden kann (fehlendes Attribut). Nebenbedingungen in den lokalen Schemas können modelliert werden, (wenn sie auf exportierten Attributen gelten, oder) wenn sie auf globalen Attributen gelten und die Form attribute = <constant> haben. tragen möglicherweise nicht zum Anfrageergebnis bei, wenn Nebenbedingung nicht modelliert wurde. 41 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 42
22 Anfragebearbeitung GaV Gegeben: Anfrage an globales Schema! Insbesondere: Auf Relationen des globalen Schemas Für jede globale Relation genau eine Sicht auf lokale Quellen Gesucht: Alle Tupel, die die Anfragebedingungen erfüllen Aber: Daten sind in lokalen Quellen gespeichert. Idee: Ersetze jede Relation der Anfrage durch ihre Sicht! Sichtentfaltung, View Expansion, Query Unfolding, Geschachtelte Anfrage 43 GaV Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) SELECT Titel, Jahr FROM Film WHERE Jahr = 2003 S1: IMDB(Titel, Regie, Jahr, Genre) S2: RegieDB(Titel, Regie) S3: GenreDB(Titel, Jahr, Genre) Globale Sicht für Film SELECT Titel, Jahr FROM (SELECT * FROM IMDB! SELECT R.Titel, R.Regie, G.Jahr, G.Genre! FROM RegieDB R, GenreDB G! WHERE R.Titel = G.Titel ) WHERE Jahr =
23 GaV Beispiel SELECT F.Titel, P.Kino FROM Film F, Programm P WHERE F.Titel = P.Titel AND P.Zeit > 20:00 S1: IMDB(Titel, Regie, Jahr, Genre) S2: RegieDB(Titel, Regie) S3: GenreDB(Titel, Jahr, Genre) S7: KinoDB(Titel, Kino, Genre, Zeit) SELECT F.Titel, P.Kino FROM (SELECT * FROM IMDB UNION SELECT R.Titel, R.Regie, G.Jahr, G.Genre FROM RegieDB R, GenreDB G WHERE R.Titel = G.Titel ) AS F, (SELECT *! FROM KinoDB ) AS P WHERE F.Titel = P.Titel AND P.Zeit > 20:00 45 GaV - Schachtelung Geschachtelte Anfragen Beliebig tiefe Schachtelung Bearbeitung Konzeptionell: Ausführung der Anfragen von innen nach außen und Speicherung in temporären Relationen. Tatsächlich: Optimierungspotential durch Umschreiben der Anfrage (Entschachtelung) Caching und materialisierte Sichten (materialized views) 46
24 GaV - Schachtelung Schachtelung i.d.r. Belassen bei entfernten Quellen i.d.r. Auflösung bei materialisierten Sichten SELECT F.Titel, P.Kino FROM (SELECT * FROM IMDB UNION SELECT R.Titel, R.Regie, G.Jahr, G.Genre FROM RegieDB R, GenreDB G WHERE R.Titel = G.Titel ) AS F, (SELECT * FROM KinoDB ) AS P WHERE F.Titel = P.Titel AND P.Zeit > 20:00 SELECT F.Titel, P.Kino FROM IMDB F, KinoDB P WHERE F.Titel = P.Titel AND P.Zeit > 20:00 UNION SELECT F1.Titel, P1.Kino FROM RegieDB F1, GenreDB F2, KinoDB P1 WHERE F1.Titel = F2.Titel WHERE F1.Titel = P1.Titel AND P1.Zeit > 20:00 47 GaV - Schachtelung SELECT F.Titel, P.Kino FROM (SELECT * FROM IMDB UNION SELECT R.Titel, R.Regie, G.Jahr, G.Genre FROM RegieDB R, GenreDB G WHERE R.Titel = G.Titel ) AS F, (SELECT * FROM KinoDB ) AS P WHERE F.Titel = P.Titel AND P.Zeit > 20:00 " # P.Zeit>20:00! Titel! Titel GenreDB RegieDB IMDB KinoDB 48
25 GaV - Schachtelung # P.Zeit>20:00! Titel! Titel " # P.Zeit>20:00 "! Titel! Titel GenreDB RegieDB IMDB KinoDB GenreDB RegieDB IMDB KinoDB 49 GaV - Schachtelung! Titel " " # P.Zeit>20:00! Titel! Titel! Titel # P.Zeit>20:00 GenreDB RegieDB IMDB KinoDB GenreDB RegieDB IMDB KinoDB 50
26 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 51 Global as View / Local as View Global as View Relationen des globalen Schemas werden als Sichten auf die lokalen Schemas der Quellen ausgedrückt. Local as View Relationen der Schemas der Quellen werden als Sichten auf das globale Schema ausgedrückt. 52
27 Warum LaV? Andere Sichtweise Es gibt in der Welt eine Menge von Filmen, Schauspielern, Das globale Schema modelliert diese Welt. Theoretisch steht damit die Extension fest.! Aber niemand kennt sie.! Informationsintegration versucht sie herzustellen. Quellen speichern Sichten auf die globale Extension.! Also Ausschnitte der realen Welt Nur die können wir verwenden. Quelle 1 Film Schauspieler Quelle 3 Quelle 2 53 Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S1: IMDB(Titel, Regie, Jahr, Genre) S2: MyMovies(Titel, Regie, Jahr, Genre) S3: RegieDB(Titel, Regie) S4: GenreDB(Titel, Jahr, Genre) CREATE VIEW S1 AS SELECT * FROM Film CREATE VIEW S2 AS SELECT * FROM Film CREATE VIEW S3 AS SELECT Film.Titel, Film.Regie FROM Film CREATE VIEW S4 AS SELECT Film.Titel, Film.Jahr, Film.Genre FROM Film Quelle: VL Data Integration, Alon Halevy, University of Washington,
28 Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S9: ActorDB(Titel, Schauspieler, Jahr) Verpasste Chance CREATE VIEW S9 AS SELECT Titel, NULL, Jahr FROM Film 55 Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S7: KinoDB(Kino, Genre) CREATE VIEW S7 AS SELECT Programm.Kino, Film.Genre FROM Film, Programm WHERE Film.Titel = Programm.Titel Assoziationen des globalen Schemas können in der Sicht hergestellt werden. 56
29 Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S9: Filme(Titel, Jahr, Ort, RegieID) Regie(ID, Regisseur) CREATE VIEW S9_Filme AS SELECT Titel, Jahr, NULL, NULL FROM Film CREATE VIEW S9_Regie AS SELECT NULL, Regie FROM Film Assoziationen des lokalen Schemas können nicht abgebildet werden. 57 Local as View (LaV) Beispiel Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) S8: NeueFilme(Titel, Regie, Genre) (IC: Jahr > 2000) CREATE VIEW S8 AS SELECT Titel, Regie, Genre FROM Film WHERE Jahr > 2000 IC auf der Quelle kann modelliert werden Wenn das Attribut im globalen Schema existiert ICs müssen in der Quelle nicht explizit definiert werden Auch implizite Einschränkungen können in den View 58
30 Local as View (LaV) Globale ICs Film(Titel, Regie, Jahr, Genre) Programm(Kino, Titel, Zeit) Nebenbedingung: Jahr > 2000 S1: IMDB(Titel, Regie, Jahr, Genre) S2: MyMovies(Titel, Regie, Jahr, Genre) CREATE VIEW S1 AS SELECT * FROM NeuerFilm (WHERE Jahr> 2000) CREATE VIEW S2 AS SELECT * FROM NeuerFilm (WHERE Jahr> 2000) Nebenbedingungen auf dem globalen Schema können wir nicht sinnvoll modellieren. Das ging aber bei GaV Also hat beides Stärken und Schwächen 59 Local as View (LaV) lokale ICs Film(Titel, Regie, Jahr, Genre) CREATE VIEW S1 AS SELECT * FROM Film S1: AlleFilmeNett(Titel, Regie, Jahr, Genre) S2: AlleFilmeBöse(Titel, Regie, Genre) S3: NeueFilmeNett(Titel, Regie, Jahr, Genre) (Nebenbedingung: Jahr > 2000) S4: NeueFilmeBöse(Titel, Regie, Genre) (Nebenbedingung: Jahr > 2000) S5: AktuelleFilme(Titel, Regie, Genre) (Nebenbedingung: Jahr = 2004) Modellierung zur Optimierung Modellierung zur Beantwortbarkeit (S4 & S5) CREATE VIEW S2 AS SELECT Titel, Regie, Genre FROM Film CREATE VIEW S3 AS SELECT * FROM Film WHERE Jahr > 2000 CREATE VIEW S4 AS SELECT Titel, Regie, Genre FROM Film WHERE Jahr > 2000 CREATE VIEW S5 AS SELECT Titel, Regie, Genre FROM Film WHERE Jahr =
31 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 61 Anfrageplanung Gegeben Eine Anfrage q an das globale Schema Lokale Schemata Gesucht! Sequenz von Anfragen q1!!qn Jedes qi kann von einem Wrapper ausgeführt werden Die geeignete Verknüpfung von q1,,qn beantwortet q! Innerhalb eines Plans durch Joins: " ->! Verschiedene Pläne werden durch UNION zusammengefasst : " -> $ Von q1 qn berechnete Tupel sind korrekte Antworten auf q 62
32 Anfrageplan Wir nennen q1 qn einen Anfrageplan. Anfrageplan Gegeben eine globale Anfrage q. Ein Anfrageplan p für q ist eine Anfrage der Form q1 qn, so dass jedes qi von genau einem Wrapper ausgeführt werden kann, und jedes von p berechnete Tupel eine semantisch korrekte Antwort für q ist. Bemerkungen Semantisch korrekt haben wir noch nicht definiert. In der Regel gibt es viele Anfragepläne. Die qi heißen Teilanfragen oder Teilpläne. 63 Query Containment Intuitiv wollen wir das Folgende: Ein View v liefert (nur) semantisch korrekte Anfragen auf eine globale Anfrage q, wenn seine Extension im Ergebnis von q enthalten ist. Query containment Sei S ein Datenbankschema, I eine Instanz von S und q1, q2 Anfragen gegen I. Sei q(i) das Ergebnis einer Anfrage q angewandt auf I. Dann ist q1 enthalten in q2, geschrieben q1 % q2 genau dann wenn q1(i) % q2(i) für alle möglichen I. Bemerkung Der wichtige Teil ist der letzte: für alle möglichen Instanzen von S Die können wir natürlich nicht alle ausprobieren 64
33 Semantische Korrektheit Damit können wir definieren, wann ein Plan semantisch korrekt ist (aber wir können das noch nicht testen) Semantische Korrektheit Sei S ein globales Schema, q eine Anfrage gegen S, und p eine Verknüpfung von Views v1,,vn gegen S, die als linke Seite von LaV Korrespondenzen definiert sind. Dann ist p semantisch korrekt für q, genau dann wenn p % q. Bemerkung Also ist die Extension von p in der von q enthalten. Die Extension von q gibt es natürlich nicht. 65 Viele Anfragepläne Anfrageergebnis Gegeben eine globale Anfrage q. Seien p1,, pn die Menge aller Anfragepläne für q. Dann ist das Ergebnis von q definiert als Bemerkungen Der UNION Operator entfernt Duplikate dahinter verbirgt sich das Problem der Ergebnisintegration. Wie das Ergebnis berechnet wird, ist Sache der Anfrageoptimierung.! Pläne können sich in Teilanfragen überlappen. Das Ergebnis von q hängt von den definierten Korrespondenzen ab. 66
34 Anfragebearbeitung LaV "Query Answering Using Views" Idee: Anfrageumschreibung durch Einbeziehung der Sichten Kombiniere geschickt die einzelnen Sichten zu einer Anfrage, so dass deren Ergebnis einen Teil der Anfrage (oder die ganze Anfrage) beantworten. Gesamtergebnis ist dann die UNION der Ergebnisse mehrerer Anfrageumschreibungen 67 LaV Beispiel Lehrt(prof,kurs_id, sem, eval, univ) Kurs(kurs_id, titel, univ) Quelle 1: Alle Datenbankveranstaltungen CREATE VIEW DB-kurs AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND L.univ = K.univ AND K.titel LIKE %_Datenbanken Globale Anfrage SELECT prof FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.titel LIKE %_Datenbanken AND L.univ = HPI Umgeschriebene Anfrage SELECT prof FROM DB-kurs D WHERE D.univ = HPI Quelle 2: Alle HPI-Vorlesungen CREATE VIEW HPI-VL AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = HPI AND L.univ = HPI AND K.titel LIKE %VL_% Warum nicht Quelle 2 einbeziehen? 68
35 LaV Beispiel Lehrt(prof,kurs_id, sem, eval, univ) Kurs(kurs_id, titel, univ) Quelle 1: Alle Datenbankveranstaltungen CREATE VIEW DB-kurs AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND L.univ = K.univ AND K.titel LIKE %_Datenbanken Globale Anfrage SELECT titel, kurs_id FROM Kurs K WHERE L.univ = HPI Umgeschriebene Anfrage SELECT titel, kurs_id FROM DB-kurs D WHERE D.univ = HPI UNION SELECT titel, kurs_id FROM HPI-VL Quelle 2: Alle HPI-Vorlesungen CREATE VIEW HPI-VL AS SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = HPI AND L.univ = HPI AND K.titel LIKE %VL_% Warum hier doch Quelle 2 einbeziehen? 69 LaV Anfragebearbeitung Gegeben: Anfrage Q und Sichten V1,..., Vn Gesucht: Umgeschriebene Anfrage Q, die bei Optimierung: äquivalent ist (Q = Q ). bei Integration: maximal enthalten ist.! D.h. Q & Q und! es existiert kein Q mit Q & Q & Q wobei Q " Q. Problem: Wie definiert und testet man Äquivalenz und maximal containment? 70
36 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 71 LaV Anfrageumschreibungen Gegeben sind eine Anfrage Q (query) und eine Sicht V (view). Fragen Ist Ergebnis von V identisch dem Ergebnis von Q? Kurz: Ist V äquivalent zu Q, V = Q? Rückführung auf Enthalten sein (containment) Ist das Ergebnis von V in Q enthalten? Kurz: Ist V in Q enthalten, V % Q? Denn V % Q, Q % V ' V = Q Query containment (Wdh.) Sei S ein Datenbankschema, I eine Instanz von S und q1, q2 Anfragen gegen I. Sei q (I) das Ergebnis einer Anfrage q angewandt auf I. Dann ist q1 enthalten in q2, geschrieben q1 % q2 genau dann wenn q1(i) % q2(i) für alle möglichen I. 72
37 LaV Beispiele SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = Humboldt AND! L.univ = Humboldt AND K.titel LIKE %VL_%???! SELECT K.titel, L.prof, K.kurs_id, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = Humboldt AND! L.univ = Humboldt 73 LaV Beispiele SELECT K.titel, K.kurs_id FROM Kurs K AND K.univ = Humboldt AND K.titel LIKE %VL_% SELECT K.titel, K.kurs_id FROM Kurs K AND K.univ = Humboldt??? "??? " SELECT K.titel, K.univ FROM Kurs K AND K.univ = Humboldt AND K.titel LIKE %VL_% SELECT K.titel FROM Kurs K AND K.univ = Humboldt 74
38 LaV Beispiele Quelle 3: CREATE VIEW Hum-Kurse AS SELECT K.titel, K.univ FROM Lehrt L, Kurs K WHERE L.kurs_id = K.kurs_id AND K.univ = Humboldt AND! L.univ = Humboldt???! Quelle 5: CREATE VIEW Kurse2 AS SELECT K.titel, K.univ FROM Kurs K AND K.univ = Humboldt Prüfung von containment durch Prüfung aller möglichen Datenbanken? Zu komplex! Prüfung von containment durch Existenz eines containment mapping. NP-vollständig in Q + Q nach [CM77] Mehrere Algorithmen Besprechen wir hier nicht. 75 Anfrageumschreibung Prinzipiell: Prüfe jede Kombination an Sichten auf Containment Unendlich viele Kombinationen, da eine Sicht auch mehrfach in eine Umschreibung eingehen kann. Verbesserungen: Satz: Umschreibung mit maximal so vielen Sichten wie Relationen in Anfrage (ohne range-prädikate). Geschickte Vorauswahl der Sichten: Nutzbarkeit! Bucket Algorithmus 76
39 Kapitel 7 GaV und LaV Übersicht Anfrageplanung Global-as-View (GaV) Modellierung Anfragebearbeitung Local-as-View (LaV) Modellierung Anfragebearbeitung Containment Bucket Algorithmus 77 LaV Bucket Algorithm (BA) Problem: Man muss exponentiell viele Kombinationen auf containment prüfen. Schon die Prüfung selbst ist ein NP-vollständiges Problem! es gibt jedoch effiziente Algorithmen! idr sind die Kombinationen nicht groß (Anzahl der Relationen) Idee zur weiteren Verbesserung: Reduktion der Anzahl der Kombinationen durch geschickte Vorauswahl Jede Relation der Anfrage erhält einen bucket (Eimer). Schritt 1: Füge in jeden bucket alle Sichten, die für die Relation nutzbar sind. Schritt 2: Prüfe alle Anfrageumschreibungs-Kombinationen, die aus jedem bucket genau eine Sicht enthalten. 78
40 Datalog Notation Im Folgenden: Nur konjunktive Anfragen Nur Equijoins und Bedingungen mit =,<,> zw. Attribut und Konstanten Kein NOT, EXISTS, GROUP BY, ", X > Y,... Schreibweise: Datalog / Prolog SELECT Klausel: Regelkopf, Exportierte Attribute FROM Klausel: Relationen werden zu Prädikaten WHERE Klausel! Joins werden durch gleiche Attributnamen angezeigt! Bedingungen werden explizit angegeben SQL vs. Datalog Notation SELECT S.price P, L.region_name RN FROM sales S, time T,... WHERE!S.day_id = T.day_id AND! S.product_id = P.product_id AND! S.shop_id = L.shop_id AND! L.shop_id = 123 AND! T.year > 1999 q(p,rn) :- sales(sid,pid,tid,rid,p,...), time(tid,d,m,y), localization(sid,lid,sn,rn), product(pid,pn,pgn), Y > 1999, SID = LaV BA Beispiel Quelle 1: CREATE VIEW V1 AS SELECT E.stud, K.titel, K.sem, K.kurs_id FROM Eingeschrieben E, Kurs K WHERE E.kurs_id = K.kurs_id AND K.kurs_id 500 AND E.sem WS98 Quelle 2: CREATE VIEW V2 AS SELECT E.stud, L.prof, E.sem, L.kurs_id FROM Eingeschrieben E, Lehrt L WHERE E.kurs_id = L.kurs_id AND E.sem = L.sem Quelle 3: CREATE VIEW V3 AS SELECT E.stud, E.kurs_id FROM Eingeschrieben E WHERE E.sem WS94 Quelle 4: CREATE VIEW V4 AS SELECT L.prof, K.kurs_id, K.titel, E.sem FROM Eingeschrieben E, Kurs K, Lehrt L WHERE E.kurs_id = K.kurs_id AND E.kurs_id = L.kurs_id AND L.sem = E.sem AND E.sem WS97 V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 V2(stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) V3(stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem WS97 80
41 LaV BA Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Anfrage Q (in SQL) SELECT E.stud, K.kurs_id, L.prof FROM Lehrt L, Eingeschrieben E, Kurs K WHERE E.kurs_id = L.kurs_id AND E.sem = L.sem AND K.kurs_id = E.kurs_id AND E.sem WS95 AND kurs_id 300 V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 V2(stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) V3(stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem WS97 81 BA en detail Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Teilziele (subgoals) von Q Erzeuge für jedes Teilziel einen bucket. Fülle Sichten in die buckets. Bucket 1: Lehrt(prof, kurs_id, sem) Bucket 2: Eingeschrieben(stud, kurs_id, sem) Bucket 3: Kurs(kurs_id, titel) 82
42 BA en detail Eine Sicht wird in ein bucket gestellt, wenn mindestens ein Teilziel der Sicht geeignet ist. Also: Für jeden bucket Für jede Sicht:! Für jedes Teilziel der Sicht Prüfung auf Eignung : 1.Unifier Mapping von allen Attributen im Teilziel von Q auf Attribute im Teilziel von V. D.h.: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. 83 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. Bucket 1: L (prof, kurs_id, sem) V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 prof wird nicht exportiert! Bucket 2: E(stud, kurs_id, sem) Bucket 3: K(kurs_id, titel) 84
43 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. Bucket 1: L (prof, kurs_id, sem) V2 V2(stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) Bucket 2: E(stud, kurs_id, sem) Bucket 3: K(kurs_id, titel) 85 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V3(stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 Bucket 1: L (prof, kurs_id, sem) V2 Bucket 2: E(stud, kurs_id, sem) prof wird nicht exportiert! Bucket 3: K(kurs_id, titel) 86
44 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem WS97 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) Bucket 3: K(kurs_id, titel) 87 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 Bucket 3: K(kurs_id, titel) 88
45 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V2(stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) 89 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V3(stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 sem ( WS95 vs. sem ) WS94 Bucket 3: K(kurs_id, titel) 90
46 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. Bucket 1: L (prof, kurs_id, sem) V2 V4 V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem WS97 stud wird nicht exportiert! Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) 91 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) V1 92
47 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V2(stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) titel wird nicht exportiert! Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) V1 93 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V3(stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 sem ) WS94 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) V1 94
48 BA en detail Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Für jede Sicht: Betrachte deren Teilziele. Falls mind. ein Teilziel geeignet ist, füge Sicht in bucket ein. Prüfung auf Eignung : 1. Unifier: Alle Anfrageattribute müssen vorkommen. 2. Kompatibilität: Prädikate sind passend. V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem), K(kurs_id, titel), E(stud, kurs_id, sem), sem WS97 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3: K(kurs_id, titel) V1 V4 95 BA Besonderheiten Eine Sicht kann in verschiedenen Buckets auftauchen. Verschiedene Rollen Eine Sicht kann mehrmals in einem Bucket auftauchen. Wenn mehrere Teilziele passen Q (stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id), sem WS95, kurs_id 300 V1(stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 Bucket 1: L (prof, kurs_id, sem) V2 V4 Bucket 2: E(stud, kurs_id, sem) V1 V2 Bucket 3_neu: K(kurs_id) V1 V1 V4 96
49 LaV BA Beispiel Anfrage Q (in Datalog) Q(stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), sem WS95, kurs_id 300 Bucket 1: Lehrt(prof, kurs_id, sem) V2 V4 Bucket 2: Eingeschrieben(stud, kurs_id, sem) V1 V2 Bucket 3: Kurs(kurs_id, titel) V1 V4 Kombinationen V2, V1, V1 V4, V1, V4 V2, V2, V4 V2, V2, V1 V2, V1, V4 V4, V1, V1 V4, V2, V4 V4, V2, V1 Frage: Welche Kombinationen (Pläne) sind zulässig? 97 LaV BA Kombinationen Wieviele Kombinationen? B 1 x B 2 x...x B n (n = Q ) Falls m = Anzahl Sichten: m n Wichtig: Jede der exponentiell vielen Kombinationen liefert potentiell einen Teil des Ergebnisses. Eine Kombination Q = V1,...,Vk ist eine Anfrageumschreibung von Q, falls Q % Q (oder Q, {Prädikate} % Q) 98
50 LaV BA Kombinationen V1 (stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 V2 (stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) V3 (stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem),k(kurs_id, titel),e(stud, kurs_id, sem), sem WS97 Anfrage: Q (stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), # sem WS95, kurs_id 300 Kombinationen V2, V1, V1 V4, V1, V4 V2, V2, V4 V2, V2, V1 V2, V1, V4 V4, V1, V1 V4, V2, V4 V4, V2, V1 Einzelne Sichten nützlich (in Bezug auf Anfrage), aber zusammen Widerspruch: sem # WS98 (V1) vs. sem $ WS97 (V4) 99 LaV BA Kombinationen V1 (stud, titel, sem, kurs_id) :- E(stud,kurs_id,sem), K(kurs_id,titel), kurs_id 500, sem WS98 V2 (stud, prof, sem, kurs_id) :- E(stud, kurs_id, sem), L(prof, kurs_id, sem) V3 (stud, kurs_id) :- E(stud, kurs_id, sem), sem WS94 V4(prof, kurs_id, titel, sem) :- L(prof, kurs_id, sem),k(kurs_id, titel),e(stud, kurs_id, sem), sem WS97 Anfrage: Q (stud, kurs_id, prof) :- L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id, titel), # sem WS95, kurs_id 300 Kombinationen V2, V1, V1 V4, V1, V4 V2, V2, V4 V2, V2, V1 V2, V1, V4 V4, V1, V1 V4, V2, V4 V4, V2, V1 Q (stud, kurs_id, prof):- V2(stud, prof, sem, kurs_id), V1 (stud, titel, sem, kurs_id), V1 (stud, titel, sem, kurs_id) x markiert nicht gebrauchte Attribute. 100
51 LaV BA Kombinationen Prüfe Q Q (stud, kurs_id, prof):- V2(stud, prof, sem, kurs_id), V1 (stud, titel, sem, kurs_id), V1 (stud, titel, sem, kurs_id) Wie? Q verwendet globale Relationen, Q verwendet Sichten Durch unfolding : Q = Q (stud, kurs_id, prof):- E(stud, kurs_id, sem), L(prof, kurs_id, sem), E(stud,kurs_id,sem), K(kurs_id,titel ), kurs_id 500, sem WS98 und Finden eines containment mappings. 101 LaV BA Kombinationen Endgültiges Ergebnis: Kombination aller Kombinationen durch UNION: V1,V2 $ V2,V4 Umgeschriebene Anfrage Q : SELECT V1.stud, V1.kurs_id, V2.prof FROM V1, V2 WHERE V1.sem = V2.sem AND V1.kurs_id = V2.kurs_id UNION SELECT V2.stud, V2.kurs_id, V2.prof FROM V2, V4 WHERE V2.sem = V4.sem AND V2.kurs_id = V4.kurs_id AND V2.prof = V4.prof 102
52 Zusammenfassung Modellierung Anfragebearbeitung Flexibilität GAV Jede globale Relation definiert als Sicht auf eine oder mehr Relationen aus einer oder mehr Quellen. Meist UNION über mehrere Quellen Nebenbedingungen auf lokalen Quellen können nicht modelliert werden. Anfrageumschreibung: Einfaches View unfolding Eine große, umgeschriebene Anfrage Interessante Optimierungsprobleme Views setzen Relationen mehrerer Quellen in Beziehung LAV Globale Relationen werden durch mehrere Sichten definiert. Definition oft nur in Kombination mit anderen globalen Relationen Nebenbedingungen auf globale Relationen können nicht definiert werden. Anfrageumschreibung: Answering queries using views UNION über viele mögliche umgeschriebene Anfragen Mehrere Algorithmen Viele Anwendungen Noch interessantere Optimierungsprobleme Bucket Algorithmus Jede View bezieht sich nur auf eine Quelle 103 Literatur Gute Zusammenfassung für LaV und weiterführende Literatur: [Levy01] Alon Y. Halevy: Answering queries using views: A survey, in VLDB Journal 10: , Eher theoretisch [Ull00] Jeffrey D. Ullman: Information Integration Using Logical Views. TCS 2000: [Hull97] Managing Semantic Heterogeneity in Databases: A Theoretical Perspective. Richard Hull. PODS 1997 tutorial [Ull97] Jeffrey D. Ullman: Information Integration Using Logical Views. ICDT 1997: [CM77] Ashok K. Chandra and Philip M. Merlin. Optimal implementation of conjunctive queries in relational data bases. In Conference Record of the Ninth Annual ACM Symposium on Theory of Computing, pages 77-90, Boulder, Colorado, 2-4 May [LMSS95] Alon Y. Levy, Alberto O. Mendelzon, Yehoshua Sagiv, Divesh Srivastava: Answering Queries Using Views. PODS 1995:
Informationsintegration
Informationsintegration Übersicht Anfrageplanung Global-as-View Ulf Leser Inhalt dieser Vorlesung Das Problem Anfrageplanung: Übersicht Global-as-View Modellierung GaV und Integritätsconstraints Implementierung
MehrInformationsintegration Local-as-View: LaV. 15.6.2012 Felix Naumann
Informationsintegration Local-as-View: LaV 15.6.2012 Felix Naumann Überblick 2 Motivation Korrespondenzen Übersicht Anfrageplanung Global as View (GaV) Local as View (LaV) Modellierung Anwendungen Anfragebearbeitung
MehrAnfragebearbeitung LaV und PDMS
Anfragebearbeitung LaV und PDMS Dr. Armin Roth arminroth.de 25.06.2012 Dr. Armin Roth (arminroth.de) II Anfragebearbeitung LaV, PDMS 25.06.2012 1 / 26 Agenda 1 Anfragebearbeitung Local-as-View Nutzung
MehrKapitel 5: Anfrageverarbeitung. Multidatenbanksprachen am Beispiel von SchemaSQL
Datenintegration Datenintegration Kapitel 5: Anfrageverarbeitung Andreas Thor Sommersemester 2008 Universität Leipzig Institut für Informatik http://dbs.uni-leipzig.de 1 Inhalt Multidatenbanksprachen am
MehrIntegration, Migration und Evolution
14. Mai 2013 Programm für heute 1 2 Quelle Das Material zu diesem Kapitel stammt aus der Vorlesung Datenintegration & Datenherkunft der Universität Tübingen gehalten von Melanie Herschel im WS 2010/11.
MehrKomplexität. Matthias Sax. 9. Juli Humboldt-Universität zu Berlin. Institut für Informatik
Komplexität Matthias Sax Humboldt-Universität zu Berlin Institut für Informatik 9. Juli 2007 Matthias Sax Komplexität 1 / 21 1 Problemstellung 2 Polynomiale Fälle Ungleichheit Anfragen in der Logik der
MehrSeminar 1 SQL Abfragen DML. MatrNr Name Vorname Age Gruppe Schmidt Hans Meisel Amelie
Seminar 1 SQL Abfragen DML Studenten MatrNr Name Vorname Email Age Gruppe 1234 Schmidt Hans schmidt@cs.ro 21 331 1235 Meisel Amelie meisel@cs.ro 22 331 1236 Krause Julia krause@cs.ro 21 332 1237 Rasch
MehrAusgangspunkt. Datenintegration. Ziel. Konflikte. Architekturen. Transparenz
Ausgangspunkt Datenintegration Web Informationssysteme Wintersemester 2002/2003 Donald Kossmann Daten liegen in verschiedenen Datenquellen (Extremfall: jede URL eigene Datenquelle) Mietautos bei www.hertz.com
MehrSchema Mapping. Dr. Armin Roth arminroth.de. Dr. Armin Roth (arminroth.de) II Schema Mapping / 23
Dr. Armin Roth arminroth.de 25.04.2013 Dr. Armin Roth (arminroth.de) II Schema Mapping 25.04.2013 1 / 23 Agenda 1 Wiederholung: Schema Matching / Integration 2 Schema Mapping Definitionen Beispiel Algorithmus
MehrAnfragebearbeitung in einem RDBMS
Data Warehouses Sommersemester 2011 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen Anfragebearbeitung in einem RDBMS Anfrage (SQL) Parsing: syntaktische
MehrWiederholung VU Datenmodellierung
Wiederholung VU Datenmodellierung VU Datenbanksysteme Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Wintersemester
MehrSQL 2. Ziele. Fortgeschrittene SQL-Konstrukte. Aggregatfunktionen revisited. Subqueries. Korrelierte Subqueries
SQL 2 Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Fortgeschrittene SQL-Konstrukte groupby having union / intersect / except Aggregatfunktionen revisited Subqueries Korrelierte
MehrDieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.
Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,
MehrDatenintegration. Kapitel 0: Organisatorisches. Dr. Anika Groß Sommersemester 2016
Datenintegration Datenintegration Kapitel 0: Organisatorisches Dr. Anika Groß Sommersemester 2016 Universität Leipzig Institut für Informatik http://dbs.uni-leipzig.de 1 Organisatorisches Termin: donnerstags,
MehrData Warehousing und Data Mining
Data Warehousing und Data Mining Materialisierte Sichten I Optimierung mit MV Ulf Leser Wissensmanagement in der Bioinformatik Inhalt dieser Vorlesung Materialisierte Sichten Logische Anfrageplanung mit
MehrData Warehousing und Data Mining
Data Warehousing und Data Mining Materialisierte Sichten I Optimierung mit MV Ulf Leser Wissensmanagement in der Bioinformatik Inhalt dieser Vorlesung Materialisierte Sichten Logische Anfrageplanung mit
MehrMengenvergleiche: Alle Konten außer das, mit dem größten Saldo.
Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten
MehrData Warehousing und Data Mining
Data Warehousing und Data Mining Materialisierte Sichten I Optimierung mit MV Ulf Leser Wissensmanagement in der Bioinformatik Inhalt dieser Vorlesung Materialisierte Sichten Logische Anfrageplanung mit
MehrKapitel 1: Einführung 1.1 Datenbanken?
Kapitel 1: Einführung 1.1 Datenbanken? 1. Einführung 1.1. Datenbanken Grundlagen der Datenbanksysteme, WS 2012/13 29. Oktober 2012 Seite 1 1. Einführung 1.1. Datenbanken Willkommen! Studierenden-Datenbank
Mehr6. Sichten, Integrität und Zugriffskontrolle. Vorlesung "Informa=onssysteme" Sommersemester 2015
6. Sichten, Integrität und Zugriffskontrolle Vorlesung "Informa=onssysteme" Sommersemester 2015 Überblick Sichten Integritätsbedingungen Zugriffsrechte SQL- Schema und SQL- Katalog Das Informa=onsschema
MehrUniversität Augsburg, Institut für Informatik Wintersemester 2008/2009 Prof. Dr. W. Kießling 03. Februar Semesterklausur
Universität Augsburg, Institut für Informatik Wintersemester 2008/2009 Prof. Dr. W. Kießling 03. Februar 2009 Dr. A. Huhn, M. Endres, T. Preisinger Datenbanksysteme I Semesterklausur Hinweise: Die Bearbeitungszeit
MehrDieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.
Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,
MehrWS 2010/11 Datenbanksysteme Fr 15:15 16:45 R Vorlesung #4. SQL (Teil 2)
Vorlesung #4 SQL (Teil 2) Fahrplan Eine weitere Aggregation: median Geschachtelte Anfragen in SQL Korrelierte vs. Unkorrelierte Anfragen Entschachtelung der Anfragen Operationen der Mengenlehre Spezielle
Mehr7. XML-Datenbanksysteme und SQL/XML
7. XML-Datenbanksysteme und SQL/XML Native XML-DBS vs. XML-Erweiterungen von ORDBS Speicherung von XML-Dokumenten Speicherung von XML-Dokumenten als Ganzes Generische Dekomposition von XML-Dokumenten Schemabasierte
MehrInformationsintegration
Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter
Mehrdbis Praktikum DBS I SQL Teil 2
SQL Teil 2 Übersicht Fortgeschrittene SQL-Konstrukte GROUP BY HAVING UNION / INTERSECT / EXCEPT SOME / ALL / ANY IN / EXISTS CREATE TABLE INSERT / UPDATE / DELETE 2 SELECT Syntax SELECT FROM [WHERE [GROUP
MehrDatenbanksysteme I Aufgabenblatt 4: SQL
Hinweise: Datenbanksysteme I Aufgabenblatt 4: SQL Abgabetermin: Montag, 08.01.07, 13:30 (vor der Vorlesung) Format: Auf Papier im Fach Datenbanksysteme I im Foyer oder per E-Mail an dbs1@hpi.uni-potsdam.de
Mehrd.h. zu Definitions-Stelle eindeutiger Funktionswert x X! y Y : (x,y) f umgekehrt: (x 1,y), (x 2,y) f ist o.k. X Y f(x) = y
Kapitel 7 Normalformen und DB-Entwurf Kap. 7.1 Normalformen Theorie Funktionale Abhängigkeit: f X Y f als Relation, d.h. Menge von Paaren {(x,y)} x: Definitions-Stelle, y: Funktionswert f ist Funktion
MehrKapitel 1: Einführung 1.1 Datenbanken?
1. Einführung 1.1. Datenbanken? Seite 1 Kapitel 1: Einführung 1.1 Datenbanken? 1. Einführung 1.1. Datenbanken? Seite 2 Willkommen! Studierenden-Datenbank Hans Eifrig hat die Matrikelnummer 1223. Seine
MehrQuery Languages (QL) Relationale Abfragesprachen/Relational
Relationale Algebra Relationale Abfragesprachen/Relational Query Languages (QL) Abfragesprachen: Daten aus einer Datenbank zu manipulieren und abzufragen (retrieve information) Das relationalle Modell
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt Nr. 7 Übung zur Vorlesung Grundlagen: Datenbanken im WS13/14 Henrik Mühe (muehe@in.tum.de) http://www-db.in.tum.de/teaching/ws1314/dbsys/exercises/
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Übung zur Vorlesung Einführung in die Informatik 2 für Ingenieure (MSE) Alexander van Renen (renen@in.tum.de)
MehrDatenbanken Unit 4: Das Relationale Modell & Datenintegrität
Datenbanken Unit 4: Das Relationale Modell & Datenintegrität 15. III. 2016 Outline 1 Organisatorisches 2 SQL 3 Relationale Algebra Notation 4 Datenintegrität Organisatorisches Erster Zwischentest: nach
MehrKapitel 10: Relationale Anfragebearbeitung
Ludwig Maimilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 201/2016 Kapitel 10: Relationale Anfragebearbeitung Vorlesung:
MehrInformationsintegration Einführung
Informationsintegration Einführung 17.4.2007 Felix Naumann Integrierte Informationssysteme 2 Anfrage Integriertes Informationssystem Oracle, DB2 Anwendung Dateisystem Web Service HTML Form Integriertes
MehrInhaltsverzeichnis. Lothar Piepmeyer. Grundkurs Datenbanksysteme. Von den Konzepten bis zur Anwendungsentwicklung ISBN:
Lothar Piepmeyer Grundkurs Datenbanksysteme Von den Konzepten bis zur Anwendungsentwicklung ISBN: 978-3-446-42354-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42354-1
MehrKapitel 3: Eigenschaften von Integrationssystemen. Einordnung von Integrationssystemen bzgl. Kriterien zur Beschreibung von Integrationssystemen
Datenintegration Datenintegration Kapitel 3: Eigenschaften von Integrationssystemen Andreas Thor Sommersemester 2008 Universität Leipzig Institut für Informatik http://dbs.uni-leipzig.de 1 Inhalt Einordnung
MehrRückblick. SQL bietet viele Möglichkeiten zur Anfrageformulierung
Rückblick SQL bietet viele Möglichkeiten zur Anfrageformulierung mathematische Funktionen (z.b. ABS(A) und SIGN(A)) Aggregatfunktionen (z.b. MIN(A) und SUM(A)) Boole sche Operatoren (AND, OR, EXCEPT) Verknüpfungen
MehrInformationsintegration
Informationsintegration Anfrageplanung mit beschränkten Quellen Ulf Leser Inhalt dieser Vorlesung Gebundene und freie Variablen Anfrageplanung Verfeinerungen Ulf Leser: Informationsintegration 2 Beschränkte
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt Nr. 06 Übung zur Vorlesung Grundlagen: Datenbanken im WS16/17 Harald Lang, Linnea Passing (gdb@in.tum.de
MehrIndexstrukturen in SQL
Indestrukturen in SQL Anlegen eines Primärinde in SQL: Anlegen eines Sekundärinde in SQL: Bsp: create table Dozenten ( DNr integer primary key, Name varchar(0), Geburt date, ) create [Unique] inde indename
Mehr4. Objektrelationales Typsystem Kollektionstypen. Nested Table
Nested Table Bei einer Nested Table handelt es sich um eine Tabelle als Attributwert. Im Gegensatz zu Varray gibt es keine Beschränkung bei der Größe. Definition erfolgt auf einem Basistyp, als Basistypen
MehrAnfragebearbeitung. Anfrage. Übersetzer. Ausführungsplan. Laufzeitsystem. Ergebnis
Anfragebearbeitung Anfrage Übersetzer Ausführungsplan Laufzeitsystem Ergebnis Übersetzung SQL ist deklarativ, Übersetzung für Laufzeitsystem in etwas prozedurales DBMS übersetzt SQL in eine interne Darstellung
MehrSQL. DDL (Data Definition Language) Befehle und DML(Data Manipulation Language)
SQL DDL (Data Definition Language) Befehle und DML(Data Manipulation Language) DML(Data Manipulation Language) SQL Abfragen Studenten MatrNr Name Vorname Email Age Gruppe 1234 Schmidt Hans schmidt@cs.ro
MehrUniversität Augsburg, Institut für Informatik WS 2007/2008 Prof. Dr. W. Kießling 18. Jan Dr. A. Huhn, M. Endres, T. Preisinger Übungsblatt 12
Universität Augsburg, Institut für Informatik WS 2007/2008 Prof Dr W Kießling 18 Jan 2008 Dr A Huhn, M Endres, T Preisinger Übungsblatt 12 Datenbanksysteme I Hinweis: Das vorliegende Übungsblatt besteht
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt Nr. 8 Hausaufgabe 1 Übung zur Vorlesung Grundlagen: Datenbanken im WS13/14 Henrik Mühe (muehe@in.tum.de)
MehrGeoinformation Abbildung auf Tabellen
Folie 1 von 32 Geoinformation Abbildung auf Tabellen Folie 2 von 32 Abbildung auf Tabellen Übersicht Motivation des relationalen Datenmodells Von Objekten zu Tabellen Abbildung von Objekten Schlüssel Abbildung
MehrEs geht also im die SQL Data Manipulation Language.
1 In diesem Abschnitt wollen wir uns mit den SQL Befehlen beschäftigen, mit denen wir Inhalte in Tabellen ( Zeilen) einfügen nach Tabelleninhalten suchen die Inhalte ändern und ggf. auch löschen können.
MehrVeranstaltung Pr.-Nr.: Datenmodellierung. Veronika Waue WS 07/08. Phasenschema der Datenbankentwicklung (grob) Informationsanalyse
Veranstaltung Pr.-Nr.: 101023 Datenmodellierung Veronika Waue WS 07/08 Phasenschema der Datenbankentwicklung (grob) Informationsanalyse Konzeptualisierung und Visualisierung (z.b. mittels ERD) (Normalisiertes)
MehrSchema Mapping. Armin Roth 25.04.2013. arminroth.de. Armin Roth (arminroth.de) II Schema Mapping 25.04.2013 1 / 23
Schema Mapping Armin Roth arminroth.de 25.04.2013 Armin Roth (arminroth.de) II Schema Mapping 25.04.2013 1 / 23 Agenda 1 Wiederholung: Schema Mapping 2 Logische Mappings 3 Erzeugung der Anfragen Armin
MehrGROUP BY, HAVING und Sichten
GROUP BY, HAVING und Sichten Tutorübungen 09/33 zu Grundlagen: Datenbanken (WS 14/15) Michael Schwarz Technische Universität München 11.11 / 12.11.2014 1/12 GROUP BY HAVING Sichten Eine Tabelle studenten
Mehr2.5 Relationale Algebra
2.5 Relationale Algebra 2.5.1 Überblick Codd-vollständige relationale Sprachen Relationale Algebra Abfragen werden durch exakte Angabe der auf den Relationen durchzuführenden Operationen formuliert Relationenkalküle
MehrSQL: statische Integrität
SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen
MehrSeminar 2. SQL - DML(Data Manipulation Language) und. DDL(Data Definition Language) Befehle.
Seminar 2 SQL - DML(Data Manipulation Language) und DDL(Data Definition Language) Befehle. DML Befehle Aggregatfunktionen - werden auf eine Menge von Tupeln angewendet - Verdichtung einzelner Tupeln yu
MehrBegrenzte Freigabe privater Daten
Begrenzte Freigabe privater Daten Matthias Kirschner Einführung Architektur Semantisches Modell Query Modifikation Fazit 29.9.2005 Szenario DBTabelle mit Seminarteilnehmern Mnr Name Thema Note email 1001
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt Nr. 05 Übung zur Vorlesung Grundlagen: Datenbanken im WS16/17 Harald Lang, Linnea Passing (gdb@in.tum.de
MehrRelationales Datenbanksystem Oracle
Relationales Datenbanksystem Oracle 1 Relationales Modell Im relationalen Modell wird ein relationales Datenbankschema wie folgt beschrieben: RS = R 1 X 1 SC 1... R n X n SC n SC a a : i=1...n X i B Information
Mehr4. Übungszettel (Musterlösung)
4. Übungszettel (Musterlösung) Einführung in Datenbanksysteme Datenbanken für die Bioinformatik Heinz Schweppe, Jürgen Broß, Katharina Hahn Hinweise: Auf dem Server esel verfügbar, wird die TerraDB sowohl
MehrWirtschaftsinformatik 2. Tutorium im WS 11/12
Wirtschaftsinformatik 2. Tutorium im WS 11/12 Entity/Relationship-Modell SQL Statements Tutorium Wirtschaftsinformatik WS 11/12 2.1 Datenmodellierung mit ERM (1) Datenmodellierung zur Erarbeitung des konzeptionellen
MehrDatalog. Moritz Kaufmann 1. Juni Technische Universität München
Datalog Moritz Kaufmann 1. Juni 2015 Technische Universität München Datalog Grundlagen Zusammenfassung 1. Faktenbasis (EDB = extensionale Datenbasis) 2. + logische Herleitungsregeln Ableitung neuer Fakten
Mehr10. Datenbank Design 1
1 Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation
MehrRelationen-Algebra. Prof. Dr. T. Kudraß 1
Relationen-Algebra Prof. Dr. T. Kudraß 1 Relationale Anfragesprachen Query Language (QL): Manipulation und Retrieval von Daten einer Datenbank Relationenmodell erlaubt einfache, mächtige Anfragesprachen
Mehrinsert, update, delete Definition des Datenbankschemas select, from, where Rechteverwaltung, Transaktionskontrolle
Einführung in SQL insert, update, delete Definition des Datenbankschemas select, from, where Rechteverwaltung, Transaktionskontrolle Quelle Wikipedia, 3.9.2015 SQL zur Kommunikation mit dem DBMS SQL ist
MehrIntroduction to Data and Knowledge Engineering. 6. Übung SQL
Introduction to Data and Knowledge Engineering 6. Übung SQL Aufgabe 6.1 Datenbank-Schema Buch PK FK Autor PK FK ISBN Titel Preis x ID Vorname Nachname x BuchAutor ISBN ID PK x x FK Buch.ISBN Autor.ID FB
MehrEinleitung 19. Teil I Einführung in Datenbanksysteme 25. Kapitel 1 Wozu Datenbanksysteme da sind 27
Inhaltsverzeichnis Einleitung 19 Über dieses Buch 19 Konventionen in diesem Buch 20 Was Sie nicht lesen müssen 21 Törichte Annahmen über den Leser 21 Wie dieses Buch aufgebaut ist 22 Teil I: Einführung
MehrDieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.
Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,
MehrOracle 10g Einführung
Kurs Oracle 10g Einführung Teil 6 Vertiefung Relationale Algebra Anzeigen von Daten aus mehreren Tabellen Timo Meyer Administration von Oracle-Datenbanken Timo Meyer Sommersemester 2006 Seite 1 von 22
Mehr1. Einführung Seite 1. Kapitel 1: Einführung
1. Einführung Seite 1 Kapitel 1: Einführung 1. Einführung Seite 2 Willkommen! Studierenden-Datenbank Hans Eifrig hat die Matrikelnummer 1223. Seine Adresse ist Seeweg 20. Er ist im zweiten Semester. Lisa
MehrAggregatfunktionen in der Relationenalgebra?
Aggregatfunktionen in der Relationenalgebra? Dieter Sosna Aggregatfunktionen in der Relationenalgebra p.1/23 Gliederung Motivation Begriffe Definitionen Anwendungen Zusammenfassung Aggregatfunktionen in
MehrVerbunde (Joins) und mengentheoretische Operationen in SQL
Verbunde (Joins) und mengentheoretische Operationen in SQL Ein Verbund (Join) verbindet zwei Tabellen Typischerweise wird die Verbindung durch Attribute hergestellt, die in beiden Tabellen existieren Mengentheoretische
MehrQuery Translation from XPath to SQL in the Presence of Recursive DTDs
Humboldt Universität zu Berlin Institut für Informatik Query Translation from XPath to SQL in the Presence of Recursive DTDs VL XML, XPath, XQuery: Neue Konzepte für Datenbanken Jörg Pohle, pohle@informatik.hu-berlin.de
MehrKapitel 2. Mathematische Grundlagen. Skript zur Vorlesung Einführung in die Programmierung
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Kapitel 2 Mathematische Grundlagen Skript zur Vorlesung Einführung in die Programmierung im Wintersemester 2012/13 Ludwig-Maximilians-Universität
MehrDatenintegration & Datenherkunft Varianten der Data Provenance
Datenintegration & Datenherkunft Varianten der Data Provenance Wintersemester 2010/11 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen 1 Arten des
MehrVerbunde (Joins) und mengentheoretische Operationen in SQL
Verbunde (Joins) und mengentheoretische Operationen in SQL Ein Verbund (Join) verbindet zwei Tabellen Typischerweise wird die Verbindung durch Attribute hergestellt, die in beiden Tabellen existieren Mengentheoretische
Mehr30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling
30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen
MehrData Cubes PG Wissensmangement Seminarphase
PG 402 - Wissensmangement Seminarphase 23.10.2001-25.10.2001 Hanna Köpcke Lehrstuhl für Künstliche Intelligenz Universität Dortmund Übersicht 1. Einführung 2. Aggregation in SQL, GROUP BY 3. Probleme mit
MehrABP Wo steckt der Fehler in der SQL-Anfrage? Semantische Prüfung von Lösungen Prof. Dr. Inga Marina Saatz
ABP 017 Wo steckt der Fehler in der SQL-Anfrage? Semantische Prüfung von Lösungen 017 - Prof. Dr. Inga Marina Saatz Inhaltsübersicht Prof. Inga M. Dr. Saatz I. Saatz Datenbanken SQLearn 1 Fachbereich ABP
MehrDeclarative Data Cleaning
Declarative Data Cleaning Vortragsgrundlage: Helena Galhardas, Daniela Florescu, Dennis Shasha, Eric Simon, Cristian Augustin Saita: Declarative Data Cleaning: Language, Model, and Algorithms, in VLDB
MehrKapitel 5: Der SQL-Standard
Kapitel 5: Der SQL-Standard 5. Der SQL-Standard 5. Ein Anfrageausdruck in SQL besteht aus einer SELECT-Klausel, gefolgt von einer FROM-Klausel, gefolgt von einer WHERE-Klausel. Grundform eines SFW-Ausdruck
MehrDieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.
Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,
Mehr9. Einführung in Datenbanken
9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken
MehrDatenbanksysteme. Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern. Wintersemester 2015/16. smichel@cs.uni-kl.de
Datenbanksysteme Wintersemester 2015/16 Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern smichel@cs.uni-kl.de Verschachtelte (Engl. Nested) Anfragen Wieso und wo gibt es verschachtelte Anfragen? ˆ Unteranfragen
MehrSchlüssel. Definition: Ein Schlüssel (key) einer Relation r(r) ist eine Til Teilmenge K von R, so dass für je zwei verschiedene Tupeln t 1
Schlüssel Definition: Ein Schlüssel (key) einer Relation r(r) ist eine Til Teilmenge K von R, so dass für je zwei verschiedene Tupeln t 1 und t 2 r gilt: - t 1 (K) t 2 (K) und - keine echte Teilmenge K'
MehrDatenbanken. Seminararbeit. Einführung in das wissenschaftliche Arbeiten
Seminararbeit vorgelegt von: Gutachter: Studienbereich: Christian Lechner Dr. Georg Moser Informatik Datum: 6. Juni 2013 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einführung in Datenbanken 1 1.1 Motivation....................................
MehrInformationsintegration
Informationsintegration Einführung Ulf Leser Wissensmanagement in der Bioinformatik Informationsintegration Anfrage Integriertes Informationssystem Oracle, DB2 Anwendung Dateisystem Web Service HTML Form
MehrInformationsintegration
Informationsintegration Architekturen Vergleichskriterien für integrierte Systeme Ulf Leser Wissensmanagement in der Bioinformatik Übersicht Technische Heterogenität Technische Realisierung des Datenzugriffs
MehrDatenbanksysteme 2013
Datenbanksysteme 2013 Kapitel 8: Datenintegrität Vorlesung vom 14.05.2013 Oliver Vornberger Institut für Informatik Universität Osnabrück Datenintegrität Statische Bedingung (jeder Zustand) Dynamische
MehrDatenintegration & Datenherkunft Architekturen
Datenintegration & Datenherkunft Architekturen Wintersemester 2010/11 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen 1 Kapitel 4 Architekturen Überblick
MehrEinführung in die Informatik II
Einführung in die Informatik II Relationale Datenbanken und SQL Theorie und Anwendung Prof. Dr. Nikolaus Wulff Gründe für eine Datenbank Meist werden Daten nicht in XML-Dokumenten, sondern innerhalb einer
Mehr9. Sicherheitsaspekte
9. Sicherheitsaspekte Motivation Datenbanken enthalten häufig sensible Daten (z.b. personenbezogene oder unternehmenskritische) Vielzahl verschiedener Benutzer hat Zugriff (z.b. Anwendungen, Mitarbeiter,
MehrCognitive Interaction Technology Center of Excellence
Kanonische Abdeckung Motivation: eine Instanz einer Datenbank muss nun alle funktionalen Abhängigkeiten in F + erfüllen. Das muss natürlich immer überprüft werden (z.b. bei jedem update). Es reicht natürlich
MehrDatenbanktheorie. Literatur: Abiteboul, S., R. Hull und V. Vianu, Foundations of Databases, Addison-Wesley 1995.
FGIS SS 2009 1. Datenbanktheorie 1. Datenbanktheorie 1 Enthaltensein-Problem konjunktiver Anfragen 2 Minimierung und Chase 3 Auswertung von Verbundausdrücken Literatur: Abiteboul, S., R. Hull und V. Vianu,
MehrData Warehousing. Sommersemester Ulf Leser Wissensmanagement in der Bioinformatik
Data Warehousing Sommersemester 2004 Ulf Leser Wissensmanagement in der Bioinformatik ... Der typische Walmart Kaufagent verwendet täglich mächtige Data Mining Werkzeuge, um die Daten der 300 Terabyte
MehrInhaltsverzeichnis. Einleitung
vn Inhaltsverzeichnis Einleitung Kapitel 1: Eine Einführung in relationale Datenbanken 7 Was ist eine relationale Datenbank? 9 Verknüpfen der einzelnen Tabellen 10 Die Reihenfolge der Zeilen ist beliebig
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof Alfons Kemper, PhD Blatt Nr 2 Übung zur Vorlesung Grundlagen: Datenbanken im WS5/6 Harald Lang, Linnea Passing (gdb@intumde) http://www-dbintumde/teaching/ws56/grundlagen/
MehrKapitel 3: Indices und Sichten
Kapitel 3: Indices und Sichten Data Warehousing und Mining - 1 Gliederung im folgenden: Klassifikation Aggregationsfunktionen, Materialisierte Sichten Grundsätzliche Alternativen beim Updaten materialisierter
MehrData Warehousing. Answering Queries using Views. Ulf Leser Wissensmanagement in der Bioinformatik
Data Warehousing Answering Queries using Views Ulf Leser Wissensmanagement in der Bioinformatik Inhalt dieser Vorlesung Materialisierte Sichten Answering Queries Using Views Query Containment Ableitbarkeit
MehrUniversität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2
Universität Augsburg, Institut für Informatik WS 2009/2010 Prof. Dr. W. Kießling 06. Nov. 2009 Dr. A. Huhn, F. Wenzel, M. Endres Lösungsblatt 2 Aufgabe 1: ER-Modellierung 1. Siehe Unterstreichungen in
MehrWelche Kunden haben die gleiche Ware bestellt? select distinct a1.name, a2.name from Auftrag a1, Auftrag a2 where a1.ware = a2.ware.
*HVFKDFKWHOWH$QIUDJHQ In einer SQL-Anweisung können in der where-klausel, from-klausel, select-klausel wieder SQL-Anweisungen auftreten. Man spricht dann auch von einer geschachtelten Anfrage oder Unteranfrage.
Mehr