Peer Data Management Systems (PDMS)

Präsentation zum Thema: "Peer Data Management Systems (PDMS)"—  Präsentation transkript:

1 Peer Data Management Systems (PDMS)
Berlin, 19. Januar 2005 Armin Roth Humboldt-Universität zu Berlin Vielen Dank für die Einführung. Heute werden Sie einige Themen aus der bisherigen Vorlesung wiedertreffen, wie z.B. Local-as-View Mappings, Query Containment oder Mediatoren. Mit PDMS verfolgen wir das Ziel einer hochskalierten und gleichzeitig ausreichend effektiven und effizienten Anfragebearbeitung. Vieles von dem was ich jetzt erzähle ist ziemlich aktuelle Forschung.

2 Armin Roth, Humboldt-Universität zu Berlin
Überblick Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten Hier ein Überblick über den Vortrag. Zunächst eine Einführung in das Problem und warum integrierte, mediatorbasierte IS nicht immer die beste Lösung sind. Dann etwas über den Aufbau solcher Systeme. Den Hauptteil bildet natürlich die Anfragebearbeitung. Mit Optimierung beschäftigt sich meine Forschungsarbeit. Zum Schluss stelle ich noch einige Forschungssysteme vor. Und selbstverständlich gibt es sowohl im PDMS-Kontext als auch bei DC interessante Aufgaben für Diplomarbeiten. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

3 Rückblick: Integrierte Informationssysteme
Globales Schema Direkter Zugriff auf jedes Quellsystem Integriertes Informationssystem Oracle, DB2… Sie haben ja bereits mediator-basierte integrierte IS kennengelernt. Ein wichtiges Charakteristikum ist globale Schema, gegen das die Anfragen gestellt werden. Ausserdem hat der Mediator direkten Zugriff auf die Quellsysteme. Schon mal vorneweg: beides ist bei PDMS nicht der Fall. Anwen- dung Datei- system Web Service HTML Form 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

4 Nachteile integrierter Informationssysteme
Globales Schema: Komplex Einigungsprozess erforderlich Wartung bedeutet (aufwändige) Schema-Evolution Praxis bevorzugt dynamische Integration mit “ähnlichen” Informationssystemen → Skalierbarkeit, Flexibilität problematisch Mediator: Single point of … Control Failure Maintenance Bezüglich Skalierbarkeit und Flexibilität des Integrationssystems erweist sich ein globales Schema nämlich als hinderlich. Warum? Mit der Anzahl der teilnehmenden Quellen wächst i.A. die Komplexität des globalen Schema und vielleicht können Sie sich vorstellen, dass der entsprechende Einigungsprozess zunehmend schwieriger wird. Wenn dann Änderungen am globalen Schema notwendig werden läuft man in die Problematik der Schema-Evolution. Ausserdem arbeiten Praktiker am liebsten mit „ähnlichen“ IS zusammen anstatt sich in Riesensysteme einzuklinken. Hierzu gleich ein Beispiel. Daneben ist ein einzelner Mediator ein zentraler Kontrollpunkt, (was man in manchen Situationen vielleicht nicht möchte), ein Single of Failure und Maintenance, die z.B. in funktional strukturierten Unternehmen ziemlich unbeliebt ist. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

5 Beispiel: Standardisiertes Schema
ISO (STEP): Standard for Exchange of Product Data Teilschema Grunddaten für Automotive Mechanik-Entwurfsprozess (ISO ) Entstanden in langem Standardisierungsprozess Datentransformation aufwändig Wie gross globale Schemata werden können, möche ich Ihnen am Beispiel dieser internationalen Norm für Produktdatenaustausch zeigen. Wir schauen uns jetzt wohlgemerkt nur einen Ausschnitt an, der die Mechanik bzw. geometrischen Entwicklung in der Automobilbranche betrifft. Achten Sie bitte auch die Seitenzahl des Dokuments. In diesem etwas länglichen Anhang finden sich die Schema-Diagramme in einer speziellen objektorientierten Sprache, die leider bei Erscheinen der Norm durch die UML überholt war. Also ich denke, Sie können sich vorstellen, dass so etwas gewisse Zeit braucht, während der Sie das Ganze noch kaum nutzen können. In der Praxis existieren viele Engines zur STEP-Datentransformation, die häufig eigene „Dialekte sprechen“. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

6 PDMS als Generalisierung integrierter Informationssysteme
Integration bereits existierender integrierter Informationssysteme Beispielsweise bei Firmenzusammenschlüssen Reorganisationen Integriertes Informationssystem 1 Integriertes Informationssystem 2 Jetzt sind wir hoffentlich ausreichend motiviert, um zu lernen, wie man ein globales Schema umgehen könnte. PDMS können als Generalisierung von intergrierten IS verstanden werden, da sie diese nämlich wiederum integrieren. So etwas braucht man z.B. bei Firmenzusammenschlüssen oder –reorganisationen. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

7 Armin Roth, Humboldt-Universität zu Berlin
Überblick Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten Nun also zur Struktur von PDMS. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

8 Peers: Integrierte Informationssysteme
Lokale Mappings Peer Schema Lokale Datenquellen (lokales Schema) Peer Mappings Funktionalität Anfragen initiieren Anfragen auswerten Anfragevermittlung (Mediation) Das Interessante ist also: jeder einzelne Peer kann ein Mediator sein. Das Peer Schema beschreibt, welche Anfragen möglich sind und übernimmt somit die Rolle des globalen Schemas. Im PDMS haben wir also viele globale Schemas, wenn man so will. Er kann weiterhin über eigene Datenquellen verfügen, die ihr eigenes Schema haben und über sogenannte lokale Schema Mappings angebunden sind. Peer Mappings zwischen den Peers ermöglichen deren Kooperation. Der Peer übt also diese Funktionalitäten aus: Er kann Anfragen vom Benutzer entgegenehmen. Er wertet diese Anfragen natürlich zuerst gegen die eigenen Daten aus und In der Rolle eines Mediators reicht er Anfragen (i.A. nach einer Umformulierung) an andere Peers weiter 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

9 Armin Roth, Humboldt-Universität zu Berlin
P1 P5 P2 Hier sehen ein etwas komplizierteres Beispiel an dem wir uns später die Anfragebearbeitung anschauen. P4 P6 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin Prof(name, bereich) Kurs(kurs_id, titel, univ) Lehrt(prof,kurs_id, sem, eval, univ) Eingeschrieben(stud, kurs_id, sem) Vertiefung(stud, fach) Arbeitet(prof, fach) Betreut(prof, stud)

10 Armin Roth, Humboldt-Universität zu Berlin
Mappings eines Peers Formalismen GLaV, GaV, LaV Equality und Inclusion Mappings Inclusion Mappings sind gerichtet P M R L M: R(x, y)  L(x, y) GLaV-Mapping: Q1(P1)  Q2(P2) (Q1, Q2 : Anfragen über Peer-Mengen) Zuvor aber noch etwas zu den Mappings. In PDMS treten Global-as-view und Local-as-view Mappings in beliebiger Folge auf. Das werden wir gleich sehen. Auch der allgemeinen Fall der Global-local-as-view Mappings lässt sich auf eine Kombination von GaV und LaV zurückführen. Die Mapping-Formeln definieren eine Relation auf den Ergebnissen der Anfragen auf beiden Seiten. Wir unterscheiden zwischen Equality- und Inclusion-Mappings, wie wir es hier haben. Wichtig ist noch, dass Inclusion-Mappings gerichtet sind. Das bedeutet, die Anfrageumformulierung kann nur entlang der Richtung des Mapping erfolgen. Die Anfrageergebnisse fliessen dann entgegen der Mapping-Richtung. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

11 Armin Roth, Humboldt-Universität zu Berlin
Anwendungen für PDMS Wichtige Annahmen: Peers reichen Anfragen weiter und geben auch Daten als Anfrageergebnis zurück, die sie selbst von anderen Peers erhalten haben Denkbare Anwendungen Wissenschaftliche Daten (z.B. Life Sciences) Katastrophen-Management Gesundheitsmanagement Allgemein: Semantic Web Das Ganze funktioniert nur, wenn … 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

12 Armin Roth, Humboldt-Universität zu Berlin
Überblick Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

13 Armin Roth, Humboldt-Universität zu Berlin
P1 Kurs kurs_id titel fak univ fach doz P6.Event(kurs_id, fach, titel)  P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) P4.Arbeitet(prof, fach, ort)  P2.Kurs(kurs_id, titel), P2.Fak(fak, fach)  P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P5.DB_Kurs(kurs_id, titel, fak, univ, doz)  P1.Kurs(kurs_id, titel, fak, univ, fach, doz)  P6.Event(kurs_id, fach, titel) P6.Event(kurs_id, art, titel) P5 DB_Kurs kurs_id titel fak univ doz Kurs kurs_id titel Lehrt prof kurs_id sem eval fak P2 Fak fak fach Peers angereichert mit einem University-Schema Darin geht es um Kurse, deren Dozenten und Fachgebiete. So sehen dann die Peer Mappings aus. P4 Arbeitet prof fach ort P6 Event event_id art titel 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin Prof(name, bereich) Kurs(kurs_id, titel, univ) Lehrt(prof,kurs_id, sem, eval, univ) Eingeschrieben(stud, kurs_id, sem) Vertiefung(stud, fach) Arbeitet(prof, fach) Betreut(prof, stud)

14 Anfragebearbeitung: Rule-Goal Tree [HIST03]
Goal-Knoten : Prädikate (umformulierter) Anfrage(n) + zugehörige Vergleichsprädikate Rule-Knoten : entsprechen Peer-Mappings Q: q(x, y) :– P.R(x, y), x > 0 P R L M: R(x, y)  L(x, y) P.q(x, y) Q P.R(x, y), x > 0 Zunächst noch Notation für Erg. der Anfragebearbeitung M P.L(x, y), x > 0 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

15 GaV-Anfrageumformulierung
Q: P1.q(kurs_id, titel, fak, univ, fach, doz) :– P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P1 20% Kurs kurs_id titel fak univ fach doz P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach)  P1.Kurs(kurs_id, titel, fak, univ, fach, doz) M12 40% Kurs kurs_id titel Lehrt prof kurs_id sem eval fak P2 Fak fak fach [] Peer001.q(kurs_id, titel, fak, univ, fach, doz) () Q [] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz) () M12 [] Peer002.Kurs(kurs_id, titel) [] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak) [] Peer002.Fak(fak, fach) Anfrage nach allen Kursen an Peer 1 unseres Beispiels GaV-Umformulierung RG Tree sieht so aus 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

16 LaV-Anfrageumformulierung
40% Kurs kurs_id titel Lehrt prof kurs_id sem eval fak P2 Fak fak fach P4 P4.Arbeitet(prof, fach, ort)  P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) Arbeitet prof fach ort 10% [] Peer001.q(kurs_id, titel, fak, univ, fach, doz) () Q [] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz) () M12 [] Peer002.Kurs(kurs_id, titel) [] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak) () M24 [] Peer004.Arbeitet(prof__1, fach, ort__6) [unc] Peer002.Fak(fak, fach) [] Peer002.Fak(fak, fach) Goal-Nodes an Peer2 können wir weiter nach Peer 4 umformulieren Besondere: Prädikat an P4 deckt nur einen Teil der Goal-Nodes ab Im RG Tree hängt der neue Goal node unter einem der abgedeckten Goal Nodes und wir Notieren einen Verweis auf den anderen abgedeckten Goal Node. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

17 Armin Roth, Humboldt-Universität zu Berlin
Behandlung von Zyklen Equality-Mappings bedeuten Zyklen: Q1(P1) = Q2(P2)  Q1(P1)  Q2(P2)  Q1(P1)  Q2(P2) First-order Logic-Semantik: Anfragebearbeitung bei Zyklen unentscheidbar [HIST03, CGLR04] Abbruchkriterien (z.B. mehrfache Verwendung eines Mappings): verliert u.U. Antworten [Schw06] P2 P2 Q MP1P2 Schon Eq.Mappings erzeugen Zyklen in der Anfragebearbeitung. Wenn gesamtes PDMS eine FOL Semantik hat, ist die Anfragebearbeitung bei Zyklen nicht entscheidbar (wg. Terminierung und Vollständigkeit) Man kann Abbruchkriterien verwenden, z.B. … Die DA von Martin Schweigert enthält Beispiel, das zeigt, wie bei diesem Abbruchkrit. Ergebnisse verloren gehen. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

18 Armin Roth, Humboldt-Universität zu Berlin
P1 Kurs kurs_id titel fak univ fach doz P5 Mapping-Zyklus DB_Kurs kurs_id titel fak univ doz Kurs kurs_id titel Lehrt prof kurs_id sem eval fak P2 Fak fak fach Auch in unserem Beispiel haben wir einen Zyklus und ich zeige ihnen jetzt im vollständigen RG Tree dass unser PDMS System P das erwähnte Abbruchkriterium implementiert. P4 Arbeitet prof fach ort P6 Event event_id art titel 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin Prof(name, bereich) Kurs(kurs_id, titel, univ) Lehrt(prof,kurs_id, sem, eval, univ) Eingeschrieben(stud, kurs_id, sem) Vertiefung(stud, fach) Arbeitet(prof, fach) Betreut(prof, stud)

19 Armin Roth, Humboldt-Universität zu Berlin
[] Peer001.q(kurs_id, titel, fak, univ, fach, doz) () Q [] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz) () ML1 [] LS001_1.Kurs(kurs_id, titel, fak, univ, fach, doz) () M12 [] Peer002.Kurs(kurs_id, titel) () M26 [] Peer006.Event(event_id__4, art__5, titel) () M65 [] Peer005.DB_Kurs(kurs_id__8, titel, fak__9, univ__10, doz__11) () ML5 [] LS005_1.DB_Kurs(kurs_id__8, titel, fak__9, univ__10, doz__11) () M61 [] Peer001.Kurs(event_id__4, titel, fak__12, univ__13, art__5, doz__14) [] LS001_1.Kurs(event_id__4, titel, fak__12, univ__13, art__5, doz__14) () M15 [] Peer005.DB_Kurs(event_id__4, titel, fak__12, univ__13, doz__14) [] LS005_1.DB_Kurs(event_id__4, titel, fak__12, univ__13, doz__14) [unc] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak) [unc] Peer002.Fak(fak, fach) () ML2 [] LS002_1.Kurs(kurs_id, titel) [] Peer002.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak) [] LS002_1.Lehrt(prof__1, kurs_id, sem__2, eval__3, fak) () M24 [] Peer004.Arbeitet(prof__1, fach, ort__6) () ML4 [] LS004_1.Arbeitet(prof__1, fach, ort__6) [] Peer002.Fak(fak, fach) [] LS002_1.Fak(fak, fach) [] Peer005.DB_Kurs(kurs_id, titel, fak, univ, doz) [] LS005_1.DB_Kurs(kurs_id, titel, fak, univ, doz) M12 wird nicht mehr genutzt: Abbruch des Zyklus Die Anfragebearbeitung kehrt nach Durchlaufen des Zyklus wieder zum Peer 1 zurück. An dieser Stelle sehen sie, dass die Goal Nodes an Peer 1 nicht ein zweites Mal nach Peer 2 umformuliert werden. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

20 Anfrageumformulierung und Vergleichsprädikate
Überlappung Vergleichprädikate von Nutzer-Anfrage und Mappings Entlang von Mapping-Pfaden akkumulieren sich Selektionen und verringern die Kardinalität des Anfrageergebnisses 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

21 Ableitung des Anfrageplanes
Verzweigender Goal-Knoten: UNION Verzweigender Rule-Knoten: JOIN P1.q Q P1.Kurs Peer002.q UNION P2.Kurs P2.Lehrt P2.Fak JOIN Anfrageplan enthält nur noch Relationen von lokalen Quellen und Operatoren UNION und JOIN. Besonderheit bei LaV-Umformulierung, die nicht alle Goal Nodes des vorausgehenden Join abdeckt. P4.Arbeitet UNION JOIN UNION (deckt P2.Lehrt und P2.Fak ab) 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

22 Effizienzprobleme durch Redundanzen
Redundante Mapping-Pfade führen zu stark verzweigten Rule-Goal Trees Beispiel [Schw06]: 31 Peers Rang ca. 5 (Anzahl von Peers, zu denen ein Peer Mappings hat) 34378 Union- und Join-Operationen 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

23 Armin Roth, Humboldt-Universität zu Berlin
Überblick Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

24 Containment-based Pruning [TH04]
PDMS Piazza (s.u.) Pruning von h, wenn (i) g (alle Antworten von) h enthält (g und h müssen am selben Peer liegen) (ii) keine Joins zwischen g und f Vorteil: Steigerung der Effizienz um etwa eine Grössenordnung Keine Antworten gehen verloren Nachteil: f bzw. g und h können an unterschiedlichen Peers liegen (hier P* bzw. P)  Kenntnis nicht-lokaler Teile des Rule-Goal Tree erforderlich Eingriff in (Kommunikations-) Autonomie der Peers Q … P*.f … … P.g P.h 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

25 Qualitätsgesteuerte Anfragebearbeitung
Wichtiges Qualitätskriterium in Informationsintegration: Vollständigkeit Extensionale Vollständigkeit: Tupelanteil Intensionale Vollständigkeit: Dichte von Datenwerten ( NULL) Projektionen und Selektionen in Peer-Mappings führen zu Informationsverlust Konzessionen an Vollständigkeit In meiner Forschungsarbeit nutze ich vollständigkeits-basierte Anfragebearbeitung. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

26 P1 P5 P2 P4 P6 20% Kurs kurs_id titel fak univ fach doz 10 % DB_Kurs
P5.DB_Kurs(kurs_id, titel, fak, univ, doz)  P1.Kurs(kurs_id, titel, fak, univ, fach, doz), doz = ‚Freytag‘ P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach)  P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P5 DB_Kurs kurs_id titel fak univ doz 100 % 20% 80% Kurs kurs_id titel Lehrt prof kurs_id sem eval fak (Anzahl der Erg.tupel bezogen auf gesamntes PDMS) Selektivität P1.Kurs(kurs_id, titel, fak, univ, fach, doz)  P6.Event(kurs_id, fach, titel) P2 Fak fak fach P5.DB_Kurs(kurs_id, titel, fak, univ, doz)  P6.Event(kurs_id, art, titel) P6.Event(kurs_id, fach, titel)  P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) 10 % P4.Arbeitet(prof, fach, ort)  P2.Kurs(kurs_id, titel), P2.Lehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach), ort  10000, ort  11000 100 % Hier sind Projektionen und Selektionen in Mappings rot markiert. Selektionen dienen dazu (u.U. implizites) Wissen über die Wertebereiche von Attributwerten explizit in den Mappings zu vermerken. Wir nehmen dann, dass wir aus Erfahrung wissen, wieviel Tupel zu bestimmten Anfragen von den einzelnen Mappings zurück zu erwarten sind (hierzu verwenden wir zukünftig Histogramme). P4 Arbeitet prof fach ort P6 100 % 100 % 10% Event event_id art titel 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin Prof(name, bereich) Kurs(kurs_id, titel, univ) Lehrt(prof,kurs_id, sem, eval, univ) Eingeschrieben(stud, kurs_id, sem) Vertiefung(stud, fach) Arbeitet(prof, fach) Betreut(prof, stud)

27 Vollständigkeits-gesteuerte Anfragebearbeitung [RN05]
Idee: Mappings mit geringem Informationsverlust bevorzugen Beschneiden des Suchraums Strategien Threshold-basiertes Beschneiden (s. Diagramm) Budget-gesteuertes Vorgehen Implementiert in System P Completeness : e Cost (# mappings used) 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

28 Armin Roth, Humboldt-Universität zu Berlin
Überblick Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

29 Armin Roth, Humboldt-Universität zu Berlin
Piazza [HIST03, TH04] Semantik: First order Logic (FOL) gesamtes PDMS hat eine Semantik Anfragen: Subset von XQuery Punktanfragen mit Negation Containment-basiertes Pruning von geschachtelten XQuery-Anfragen Minimalisierung umformulierter Anfragen 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

30 Armin Roth, Humboldt-Universität zu Berlin
Hyper [CGLR04] Epistemische Logik: Jeder Peer hat eigene Semantik Peers geben nur weiter, was sie sicher wissen Vorteile Peers sind wirklich modulare Einheiten Ermittlung aller Certain Answers ist in polynomieller Datenkomplexität (FOL-Semantik: unentscheidbar) 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

31 Armin Roth, Humboldt-Universität zu Berlin
System P [RN05] Relationales Datenmodell mit Punkt- und Range-Anfragen GaV- und LaV-Umformulierung Vollständigkeits-gesteuerte Anfragebearbeitung Visualisierung der Anfragebearbeitung Aktuelle Entwicklung: Selektivitätsschätzung mit selbstadaptiven Histogrammen Ausblick: Kostenmodell, Parallele Anfragebearbeitung 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

32 Zusammenfassung + Ausblick
PDMS: Dezentral organisiert (kein globales Schema) Hohe Flexibilität und Dynamik Ineffizienz durch Redundanzen Informationsverluste entlang Mapping-Pfade Vollständigkeits-basierte Anfragebearbeitung Ausblick: Kostenmodell Management von Schemata und Mapping-Netzen Erweitern von Peer-Schemata (Schema-Discovery) 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

33 Studien-/Diplomarbeitsthemen System P
Parallele Anfragebearbeitung und Budget-Strategien (Experimente) Ranking von Anfrageergebnissen nach Relevanz u.v.m. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

34 Diplomarbeiten Cross-domain PDM
gegeben Enterprise-PDM-Backbone Datenmanagement Informationsmodelle Constraints Instanzen Anfragebearbeitung Access Limitations (bzgl. Zugriffsmethoden) Authorisierung P P WfMS-Funktionalität (z.B. Änderungs-, Konfigurations- und Freigabeprozesse) R CAD E/E … Schema Mapping Tool (Data/Schema Interplay) Semantic Description of Data Services in a SOA Integration Mappings zwischen Informationsmodellen Mappings zwischen Prozess-Metamodellen Prozess-Synchronisation gesucht Enterprise Model Management (in a SOA context) 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin

35 Fragen? aroth@informatik.hu-berlin.de
Skalierbare und flexible Informationsintegration Struktur eines PDMS Anfragebearbeitung in PDMS Optimierungsansätze Forschungssysteme Diplomarbeiten

36 Armin Roth, Humboldt-Universität zu Berlin
Literatur [CGLR04] Calvanese, D., Giacomo, G.D., Lenzerini, M., Rosati, R.: Logical foundations of peer-to-peer data integration. In: Proc. of the Symposium on Principles of Database Systems (PODS), 2004. [HIST03] Halevy, A.Y., Ives, Z., Suciu, D., Tatarinov, I.: Schema mediation in peer data management systems. In: Proc. of the Int. Conf. on Data Engineering (ICDE), 2003. [Hübn06] Hübner, T.: Entwicklung einer Testumgebung für ein Peer Data Management System. Humboldt-Universität zu Berlin, Diplomarbeit, 2006. [RN05] Roth, A., Naumann, F.: Benefit and cost of query answering in PDMS. In: Proc. of the Int. Workshop on Databases, Information Systems and Peer-to-Peer Computing (DBISP2P), 2005. [Schw06] Schweigert, M.: Entwurf eines Peer Data Management Systems mit Steuerungs- und Simulationskomponente. Humboldt-Universität zu Berlin, Diplomarbeit, 2006. [TH05] Tatarinov, I., Halevy, A.: Effcient query reformulation in peer data management systems. In: Proc. of the ACM Int. Conf. on Management of Data (SIGMOD), 2004. 19. Januar 2005 Armin Roth, Humboldt-Universität zu Berlin