Informationsintegration - informatik.hu-berlin.dewandelt/II2014/10... · • TP1, dann TP2, dann Join im Mediator – Benötigt Download aller Filme der IMDB – Vermutlich teuer

Informationsintegration

Ulf Leser Sebastian Wandelt

Übersicht Anfrageplanung Global-as-View

Ulf Leser: Informationsintegration 2

Inhalt dieser Vorlesung

• Das Problem

• Anfrageplanung: Übersicht

• Global-as-View

– Modellierung

– GaV und Integritätsconstraints

– Implementierung


Das Problem

Föderiertes Schema

Externes Schema 1

Externes Schema N ...

Komponenten- schema

Komponenten-schema

Lokales internes Schema

Lokales internes Schema

Exportschema Exportschema

Quelle 1 Quelle 2 Quelle 3

Mediator

Anwendung 1 Anwendung 2

Wrapper

Wrapper Wrapper

Was steckt hinter diesen Pfeilen?


Abstrakter

• Bei enger Kopplung

– Wie beschreibt man die Beziehungen zwischen dem globalen und den verschiedenen lokalen Schemata?

– Wie benutzt man diese Beziehungen zur Anfrageplanung?

– Kann man aus solchen Beziehungen das integrierte Schema erzeugen?


Korrespondenzen

• Korrespondenz: Spezifikation semantisch äquivalenter Teile in Quellschema und globalem Schema

• Regel mit zwei Teilen

– Erster Teil: Teile im Quelle

– Zweiter Teil: Teile im Zielschema

– Dazwischen: Datentransformation und Restrukturierung

• Kann unterschiedliche Mechanismen benutzen

– Global-as-View, Local-as-View, …

• Wir wollen deklarative Korrespondenzen

• Woher?

– Manuell spezifizieren

– (Semi-)automatisch finden: Schema Matching (später)


Zwei Richtungen

• Virtuelle Integration: Anfragen übersetzen

– Gegeben Anfrage an Zielschema

– Finde semantisch äquivalente Sequenz von Anfragen an Quellschemata

• Materialisierte Integration: Daten transformieren

– Gegeben Quellschemata mit Daten

– Finde semantisch äquivalente Darstellung der Daten im Zielschema

• Beide Richtungen sind ähnlich, aber nicht identisch

• Wir konzentrieren uns auf die erste Richtung


Weiteres Vorgehen

• Erst konkret, dann abstrakter

• Übersicht Anfragebearbeitung

• Global as View und View Unfolding

• Anfragekorrespondenzen und semantische Korrektheit

• Local as View und Query Containment

• Anfrageoptimierung

• Umgang mit beschränkten Quellen



• Das Problem


• Global-as-View

– Modellierung


– Implementierung


Anfragebearbeitung

• Aufgabe

– Gegeben eine Anfrage q gegen das globale Schema

– Gegeben eine Menge von Korrespondenzen zwischen globalem und lokalen Schemata

– Finde alle Antworten auf q

Globales Schema

Lokale Exportschemata

Korrespondenzen


Anfragebearbeitung

• Schritt 1: Anfrageplanung (in den nächsten Stunden)

– Welche Quellen können / sollen / müssen benutzt werden?

– Welche Teile der Anfrage sollen wohin geschickt werden?

• Schritt 2: Anfrageübersetzung

– Aus der Sprache der globalen Schema in die Sprache der Quellen

• Schritt 3: Anfrageoptimierung

– Wer führt was wann aus (Pushen, Reihenfolge)?

– Wer kann was ausführen (Kompensation)?

• Schritt 4: Anfrageausführung

– Monitoring, Puffern, Cachen, Re-Optimieren

• Schritt 5: Ergebnisintegration

– Duplikaterkennung und Konfliktauflösung


Schritt 1 & 2

Anfrage-planung

Eingabe: Benutzeranfrage und Anfragekorrespondenzen

Aufgabe: Berechnet Anfragepläne. Ein Anfrageplan ist eine Menge von logischen Anfragen an Datenquellen, in der Regel verknüpft durch Join-Prädikate. Jeder Plan muss ausführbar sein und nur semantisch korrekte Ergebnisse berechnen. Sollten mehrere Anfragepläne existieren, ist es auch Aufgabe der Anfrageplanung zu entscheiden, welche davon ausgeführt werden sollen.

Ergebnis: Ein oder mehrere Anfragepläne

Anfrage- übersetzung

Eingabe: Ein Anfrageplan

Aufgabe: Ein Anfrageplan besteht aus Teilanfragen, die jeweils genau eine Datenquelle adressieren. Diese Teilanfragen sind syntaktisch auf die Integrationsschicht zugeschnitten. Die An- frageübersetzung muss jede Teilanfrage in einen unmittelbar von der betreffenden Datenquelle ausführbaren Befehl übersetzen.

Ergebnis: Ein übersetzter Anfrageplan


Schritt 3 & 4

Anfrage- optimierung

Eingabe: Ein übersetzter Anfrageplan

Aufgabe: Anfragepläne bestehen aus Teilanfragen, für die noch nicht feststeht, in welcher Reihenfolge sie berechnet und wo in ihnen enthaltene oder sie verbindende Anfrageprädikate ausgeführt werden. Die Festlegung dieser Punkte ist die Aufgabe der Anfrageoptimierung, deren Ergebnis ein (physischer) Ausführungsplan ist.

Ergebnis: Ein Ausführungsplan

Anfrage- ausführung

Eingabe: Ein Ausführungsplan

Aufgabe: Ein Ausführungsplan kann unmittelbar ausgeführt werden, muss aber in seiner Ausführung überwacht werden, da Netzwerkverbindungen oftmals unzuverlässig sind. Außerdem müssen Prädikate der Benutzeranfrage, deren Ausführung nicht an eine Datenquelle delegiert wurden, im Integrationssystem ausgeführt werden.

Ergebnis: Eine Menge von Ergebnistupeln


Schritt 5

Ergebnis- integration

Eingabe: Pro Ausführungsplan eine Menge von Ergebnistupeln

Aufgabe: Die Ergebnisse der einzelnen Ausführungspläne sind oftmals redundant oder uneinheitlich. Während der Ergebnisintegration werden die einzelnen Ergebnisse zu einem Gesamtergebnis integriert, was insbesondere Duplikaterkennung und Auflösen von Widersprüchen in den Daten erfordert.

Ergebnis: Das Ergebnis der Benutzeranfrage


Beispiel

• Filmwelt

• Vereinfachende Annahmen

– Quellen bestehen nur aus einer (Export-)Relation

– Keine Datenmodellheterogenität

• Nehmen wir jetzt immer an

– Keine strukturelle oder schematische Heterogenität

• Nehmen wir ganz selten an

– Keine semantische Heterogenität

• Gleiche Namen = gleiche Konzepte

• Nehmen wir manchmal an


Beispiel

• Globales Schema

• Datenquellen


Anfrageplanung

• Globale Anfrage

– „Alle Filme, in denen Hans Albers eine Hauptrolle spielte“

• Was kommt in Frage?

– film: Quellen imdb.movie und fd.film

– spielt: Quellen imdb.acts und fd.spielt

• Ergibt vier Anfragepläne


Vier Anfragepläne

• Jeder Plan = 2 Teilpläne

– Teilpläne sind quellspezifisch

• Wer führt Joins zwischen Teilplänen aus?

• System kann auswählen

– Alle Pläne: teuer,vollständig

– Schnellster Plan

– Plan mit dem größten Ergebnis

– …


Fragen

• Kann man nicht imdb.movie ⋈ imdb.acts gemeinsam

betrachten?

– Doch – aber wir nehmen (noch) Quelle = „eine Relation“ an

– Später (GaV)

• Warum sollte man imdb.movie und fd.spielt zusammen

in einem Plan benutzen?

– Weil Quellen unvollständig und fehlerhaft sind

– Daher können Kombination neue korrekte Tupeln produzieren

– Annahme: Gleiche Werte in den Joinattributen

• Hier: Filmnamen, Schauspielernamen


Beispiel

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


Münchhausen, Albers, Hauptrolle

Movie ⋈ acts

-

film ⋈ spielt

Münchhausen, Bürger, Hauptrolle

film ⋈ acts

-

movie ⋈ spielt

Münchhausen, van Baky, Hauptrolle


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 titel, rolle

FROM fd.spielt

WHERE s…_name=‚Hans Albers‘

AND rolle=‚Hauptrolle‘

• Jeder Teilplan kann an eine Quelle geschickt werden

– Übersetzung der Schemaelementnamen

– Übersetzung SQL Anfrage in Web-Service, HTTP, XQuery, …

– Übersetzung von Konstanten in einer Query

• Was heißt „Hauptrolle“ in der imdb?


Anfrageoptimierung

TP2:

SELECT title, role

FROM imdb.acts



TP1:

SELECT title, director

FROM imdb.movie;

• Lokale Optimierung: Jeder Plan einzeln

• Globale Optimierung: Gesamtmenge aller Pläne (später)

• Fragen

– Optimale Reihenfolge der Ausführung der Teilpläne?

– Möglicherweise parallele Ausführung?

– Bedingungen pushen oder lokal ausführen?


Einige Möglichkeiten

• TP1, dann TP2, dann Join im Mediator

– Benötigt Download aller Filme der IMDB

– Vermutlich teuer

• TP1 und TP2 parallel

– Ergebnis von TP1 ist für TP2 unerheblich

– Immer noch teuer

• Erst TP2, dann TP1 umschreiben, Join im Mediator – Pushen der Tupel aus TP2 an TP1 (WHERE TITLE in (…))

– Keine Parallelisierung ganzer Anfragen mehr möglich

• Aber Pipelining

– Kleinere Zwischenergebnisse, vermutlich schneller

TP2:

SELECT title, role

FROM imdb.acts



TP1:

SELECT title, director

FROM imdb.movie;


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

• Fehlende Operationen im Mediator ausführen

– Nicht-pushbare Selektionen

– Joins zwischen Quellen


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

imdb.movie

Vögel, Hitchcock

Münchhausen, von Baky

imdb.acts


Münchhausen, Bendow, Nebenrolle

fd.film

Vögel, Hitchcock

Münchhausen, Bürger

fd.spielt


Münchhausen, Albers, Hauptrolle

… ⋈ … UNION … ⋈ … UNION …

-

Münchhausen, Bürger, Hauptrolle

Münchhausen, von Baky, Hauptrolle

-



• Das Problem


• Global-as-View

– Modellierung


– Implementierung


Modellierung von Datenquellen

• Relationales Modell

• Kernidee: Modellierung strukturell heterogener Quellen in Bezug auf ein globales Schema als Views (Sichten)

• Sichten verknüpfen Relationen miteinander

• Sichten sind hier definiert auf Relationen eines Schemas (mehrerer Schemata) und produzieren eine Relation des anderen Schemas


Global as View / Local as View

• Global as View (GaV)

– Relationen des globalen Schemata werden als Sichten auf die lokalen Schemata der Quellen ausgedrückt

• Local as View (LaV)

– Relationen der Schemata der Quellen werden als Sichten auf das globale Schema ausgedrückt


Global as View Beispiel

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

UNION

SELECT *

FROM MyMovies

UNION

SELECT RegieDB.Titel, RegieDB.Regie, GenreDB.Jahr, GenreDB.Genre

FROM RegieDB, GenreDB

WHERE RegieDB.Titel = GenreDB.Titel

Quelle: VL „Data Integration“, Alon Halevy, University of Washington, 2002

Film( Titel, Name, Jahr, Genre)

Regisseur( Name, Foto, Alter)


Zwei Arten von GaV Regel

• Einfache GaV Regeln: Quellspezifisch

– Verknüpfung über Quellen hinweg übernimmt die Anfrageplanung

– Besser wartbar, denn Änderung einer Quelle betrifft wenige, klar definierte Sichten

– Einfacher zu erweitern mit neuen Quellen, denn bestehende Views müssen nicht angefasst werden

• Komplexe GaV Regeln: Quellübergreifend

– Sicht ist eine Anfrage in einer Multidatenbanksprache

– Sicht fasst alle Objekte einer globalen Relation zusammen

– Anfrageplanung übernimmt nur noch Verknüpfung zwischen verschiedenen Relationen, d.h., Joins in der globalen Anfrage

– Weniger robust, schwerer zu erweitern

– Relationenspezifische Konfliktlösung kann in Sicht definiert werden


Fehlende Attribute, Umbenennung, …

S5: MDB( Titel, Regie, Jahr DATE)

S6: MovDB( Titel, Regie, Genre)

Film( Titel, Name, Jahr NUM(2), Genre)


Wie kommt man hier weiter?

(S5/S6 -> Film)


Fehlende Attribute, Umbenennung, …

S5: MDB( Titel, Regie, Jahr DATE)

S6: MovDB( Titel, Regie, Genre)

CREATE VIEW Film (Titel, Name, Jahr, Genre) AS

SELECT Titel, lastname(Regie), SQL.year(Jahr), NULL AS Genre

FROM MDB

UNION

SELECT Titel, Regie, NULL AS Jahr, Genre

FROM MovDB Fehlendes Attribut

• Andere Namen, fehlende Attribute, unterschiedliche Granularität, unterschiedliche Datentypen etc. relativ problemlos

Film( Titel, Name, Jahr NUM(2), Genre)


Datentyp

Umbenennung Granularität


Strukturelle Heterogenität – Aufsplittung

S7: FilmRegie( Titel, Name, Jahr)

S7: Genre (Titel, Genre)

CREATE VIEW Film AS

SELECT Titel, Name, Jahr, Genre

FROM FilmRegie, genre

WHERE filmregie.titel=genre.titel



• Zunächst kein Problem

• Aber Heterogenität in der Kardinalität film-genre

– Ist 1:1 im globalen Schema, 1:n in S7

– Führt zu mehreren Tupeln für einen Film im globalen Schema

– Problem – oder nicht


Strukturelle Heterogenität – Verschmelzung

S7: FilmRegie( Titel, DirFoto)

CREATE VIEW Film AS

SELECT Titel, NULL, NULL, Null

FROM FilmRegie

CREATE VIEW Regisseur AS

SELECT NULL, DirFoto, NULL

FROM FilmRegie



• Problem: Assoziationen werden getrennt

• Tritt nur auf, wenn Attribute verschiedener globaler Relationen in einer lokalen Relation liegen und der verbindende Key/FK nicht existiert

– Möglichkeit: Künstlichen Schlüssel erzeugen


Vorschau: Local as View (LaV)

S7: FilmRegie( Titel, DirFoto)

CREATE VIEW S7 AS

SELECT F.Titel, R.Foto

FROM Film, Regisseur

WHERE F.Name = R.name



• Umgekehrte Betrachtung

• Assoziationen bleiben erhalten – name wird zwar nie instantiiert

– Aber man weiß, dass es einen verbindenden Namen gibt

– Damit kann man auch Anfragen planen



• Das Problem


• Global-as-View

– Modellierung


– Implementierung


Integritätsconstraints

• 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>50.000

– golfclub_mitglieder( name, alter), alter>55

– film( title, type), type{spielfilm, doku,

kurzfilm}

– …

• Sind für korrekte Integration wichtig


Globale Integritätsconstraints


S2: MyMovies( Titel, Regie, Jahr, Genre)

Neuerfilm( Titel, Regie, Jahr, Genre);

Regisseur( Name, Foto, Alter);

IC: Jahr > 2000

CREATE VIEW NeuerFilm AS

SELECT * FROM IMDB

WHERE Jahr > 2000

UNION

SELECT * FROM MyMovies

WHERE Jahr > 2000

• IC auf globalem Schema in die Sichtdefinition aufnehmen

• Ausführung in der Quelle (push) oder im Mediator


Probleme mit globalen IC


S2: MyOldOrNewMovies( Titel, Regie) CREATE VIEW NeuerFilm AS

SELECT *

FROM IMDB

WHERE Jahr > 2000

UNION

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 garantiert korrekt integriert werden

Neuerfilm( Titel, Regie, Jahr, Genre);

Regisseur( Name, Foto, Alter);

IC: Jahr > 2000


Lokale Integritätsconstraints

S8: NeueFilme( Titel, Regie, Genre)

IC: Jahr > 2000

CREATE VIEW Film AS

SELECT Titel, Regie, NULL, Genre

FROM NeueFilme

• IC in Quelle ist nicht im View ausgedrückt

• Warum ist das schlecht?

SELECT * FROM film WHERE jahr < 1950




Viele Quellen, lokale IC – Zu Hause ansehen

CREATE VIEW Film AS

SELECT *

FROM AlleFilmeNett

UNION


FROM AlleFilmeBöse

UNION

SELECT *

FROM NeueFilmeNett

UNION


FROM NeueFilmeBöse

UNION

SELECT Titel, Regie, 2012, Genre

FROM AktuelleFilme


Regisseur( Name, Foto, Alter) 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)

(Hintergrundwissen: Jahr > 2000)

S5: AktuelleFilme(Titel, Regie, Genre)

(Hintergrundwissen : Jahr = 2012)


Auswirkungen 1

Anfrage: SELECT * FROM Film

CREATE VIEW Film AS

SELECT *

FROM AlleFilmeNett

UNION


FROM AlleFilmeBöse

UNION

SELECT *

FROM NeueFilmeNett

UNION


FROM NeueFilmeBöse

UNION


FROM AktuelleFilme




CREATE VIEW Film AS

SELECT *

FROM AlleFilmeNett

UNION


FROM AlleFilmeBöse

UNION

SELECT *

FROM NeueFilmeNett

UNION


FROM NeueFilmeBöse

UNION


FROM AktuelleFilme

Auswirkungen 2

Anfrage: SELECT * FROM Film

WHERE Jahr > 2001

Trägt voll zum Ergebnis bei

Trägt nicht zum Ergebnis bei (NULL > 2001)


Trägt nicht zum Ergebnis bei (leider)





CREATE VIEW Film AS

SELECT *

FROM AlleFilmeNett

UNION


FROM AlleFilmeBöse

UNION

SELECT *

FROM NeueFilmeNett

UNION


FROM NeueFilmeBöse

UNION


FROM AktuelleFilme

Auswirkungen 3


Trägt nicht zum Ergebnis bei

Trägt nicht zum Ergebnis bei (2000 > 1950)




Regisseur( Name, Foto, Alter) Anfrage: SELECT * FROM Film

WHERE Jahr < 1950


Fazit

• Integritätsconstraints im globalen Schema

– Verhindern die Integration von Quellen, wenn die Bedingung nicht durch eine Anfrage an die Quelle geprüft werden kann

• Integritätsconstraints in lokalen Schemata

– Können in globaler Sicht modelliert werden, wenn

• Nur exportierte Attribute betroffen sind (zur Optimierung)

• Nur nicht exportierte Attribute betroffen sind, die im globalen Schema vorhanden sind und die Form „attribute = const“ haben (als

konstante Spalten)

– Können ignoriert werden, wenn sie Attribute betreffen, die im globalen Schema nicht enthalten sind



• Das Problem


• Global-as-View

– Modellierung


– Implementierung / Anfragebearbeitung


Anfragebearbeitung – GaV

• Gegeben: Anfrage an globales Schema

• Gesucht: Alle Tupel, die die Anfragebedingungen erfüllen und in mindestens einer Quelle vorhanden sind

• Idee: Ersetze jede Relation der Anfrage durch ihre Sicht

– Sichtentfaltung, View Expansion, Query Unfolding

– Ergibt geschachtelte Anfrage


GaV – Beispiel 1

Film(Titel, Regie, Jahr, Genre)

Programm(Kino, Titel, Zeit)

SELECT *

FROM Film SELECT *

FROM ( SELECT *

FROM IMDB

UNION

SELECT R.Titel, R.Regie, G.Jahr, G.Genre

FROM RegieDB R, GenreDB G

WHERE R.Titel = G.Titel)

S1: IMDB(Titel, Regie, Jahr, Genre)

S2: RegieDB(Titel, Regie)

S3: GenreDB(Titel, Jahr, Genre)

• Generiert nicht alle möglichen Tupel

• Entscheidung über gewünschte Tupeln ist in der Sichtdefinition festgelegt

– Bei einfachen GaV Regeln trifft diese Entscheidung der Planer


GaV – Beispiel 2

SELECT F.Titel, P.Kino, F.Regie

FROM Film F, Programm P

WHERE F.Titel = P.Titel

AND P.Zeit > 20:00

SELECT F.Titel, P.Kino, F.Regie

FROM ( SELECT *

FROM IMDB

UNION

SELECT R.Titel, R.Regie, G.Jahr, G.Genre


WHERE R.Titel = G.Titel) AS F,

( SELECT *

FROM KinoDB) AS P


AND P.Zeit > 20:00

S1: IMDB(Titel, Regie, Jahr, Genre)

S2: RegieDB(Titel, Regie)

S3: GenreDB(Titel, Jahr, Genre)

S7: KinoDB(Titel, Kino, Zeit)




Direkte Übersetzung

P.Zeit>20:00

⋈Titel

KinoDB IMDB RegieDB GenreDB

⋈Titel

∪

SELECT F.Titel, P.Kino

FROM ( SELECT * FROM IMDB

UNION

SELECT R.Titel, R.Regie, …


WHERE R.Titel = G.Titel) AS F,

( SELECT *

FROM KinoDB) AS P


AND P.Zeit > 20:00

titel,kino


Predicate-Pushdown

P.Zeit>20:00

⋈Titel


⋈Titel

∪ P.Zeit>20:00

⋈Titel


⋈Titel

∪

titel,kino

titel,kino


Alternative Join-Ausführung

P.Zeit>20:00

⋈Titel


⋈Titel

∪

P.Zeit>20:00

⋈Titel


⋈Titel

∪

titel,kino titel,kino


Anderes Beispiel

S5: MDB(Titel, Zeit, Regie)

S6: MovDB(Kino, Genre, Titel)

CREATE VIEW Film AS

SELECT MDB.Titel, Regie, NULL, Genre

FROM MDB, MovDB

WHERE MDB.Titel = MovDB.Titel

CREATE VIEW Programm AS

SELECT Kino, MDB.Titel, Zeit

FROM MovDB, MDB


SELECT F.Titel, P.Kino

FROM Film F, Programm P


AND P.Zeit > 20:00

SELECT F.Titel, F.Jahr

FROM ( SELECT Titel, Regie, NULL, Genre

FROM MDB, MovDB


) AS F,

( SELECT Kino, Titel, Zeit

FROM MovDB, MDB


) AS P


AND P.Zeit > 20:00




Direkte Übersetzung

P.Zeit>20:00

⋈Titel

MovDB MDB

⋈Titel ⋈Titel

SELECT F.Titel, F.Kino

FROM ( SELECT Titel, Regie, NULL, Genre

FROM MDB, MovDB


) AS F,

( SELECT Kino, Titel, Zeit

FROM MovDB, MDB


) AS P


AND P.Zeit > 20:00

titel,Kino


Entschachteln

P.Zeit>20:00

⋈Titel

MovDB MDB

⋈Titel ⋈Titel P.Zeit>20:00

⋈Titel

MovDB MDB

titel,Kino

titel,Kino


Projektionen pushen

P.Zeit>20:00

⋈Titel

MovDB MDB

titel,Kino

P.Zeit>20:00

⋈Titel

MovDB MDB

titel titel,Kino

Documents

Informationsintegration - informatik.hu-berlin.dewandelt/II2014/10... · • TP1, dann TP2, dann Join im Mediator – Benötigt Download aller Filme der IMDB – Vermutlich teuer