Peer Data Management mit System P Ilmenau, 17. Mai 2006 Felix Naumann Armin Roth naumann@informatik.hu-berlin.de aroth@informatik.hu-berlin.de Humboldt-Universität zu Berlin Überblick Arbeitsgruppe Informationsintegration an der HU Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 2 1
Humboldt-Universität zu Berlin Wilhelm und Alexander von Humboldt Einheit von ehre und Forschung Freiheit und Unabhängigkeit der Wissenschaft 29 Nobelpreisträger Mommsen, Hertz, Koch, Hahn, Planck, Einstein,... 38,000 Studenten, (1100 Informatik) 500 Professoren (21 Informatik) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 3 Humboldt-Universität zu Berlin 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 4 2
Campus Adlershof 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 5 Forschungsgruppe Informationsintegration eitung: Felix Naumann (naumann@informatik.hu-berlin.de) Mitarbeiter Jens Bleiholder (bleiho@informatik.hu-berlin.de) Informationsfusion in relationalen Daten Melanie Weis (mweis@informatik.hu-berlin.de) Objektidentifikation in XM Daten Affiliated Armin Roth (aroth@informatik.hu-berlin.de) Datenqualität in Peer-Data-Management-Systemen Alexander Bilke (bilke@cs.tu-berlin.de) Schema Matching Forschungsthemen Objektidentifikation Informationsfusion Optimierung Visualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 6 3
Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 8 Integrierte Informationssysteme Anfrage Integriertes Informationssystem Oracle, DB2 Anwendung Dateisystem HTM Form Integriertes Info.-system 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 9 4
Warum ist Informationsintegration so schwer? [Halevy04] Alon Halevy: It s plain hard! System-bedingte Gründe Verschiedene Plattformen Anfragebearbeitung über mehrere Systeme Soziale Gründe Finden relevanter Daten in Unternehmen Beschaffen relevanter Daten in Unternehmen Menschen zur Zusammenarbeit überreden ogik-bedingte Gründe Schema- und Datenheterogenität Dies ist unabhängig von der jeweiligen Integrationsarchitektur. 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 10 Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <publication> <title> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </title> <auth> Scheth & arson </auth> </publication> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 11 5
Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <publication> <title> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </title> <auth> Scheth & arson </auth> </publication> <Titel> </Titel> <Autor> </Autor> <Autor> </Autor> <year> </year> Schema Mapping Schema Integration Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 12 Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <publication> <title> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </title> <auth> Scheth & arson </auth> </publication> Schema Integration Schema Mapping <Titel> Federated Database Systems </Titel> XQuery <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> XQuery <Autor> Scheth & arson </Autor> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 13 6
Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <publication> <title> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </title> <auth> Scheth & arson </auth> </publication> <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> Scheth & arson </Autor> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 14 Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <publication> <title> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </title> <auth> Scheth & arson </auth> </publication> <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> Scheth & arson </Autor> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 15 7
Informationsintegration A B <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> Scheth & arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> James arson </Autor> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 16 Informationsintegration A B 1sec. 5sec. <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> Scheth & arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> James arson </Autor> Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 17 8
Informationsintegration A B 1sec. 5sec. <Titel> Federated Database Systems </Titel> <Autor> James arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> <Autor> Scheth & arson </Autor> <Titel> Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases </Titel> WS B <Autor> James arson </Autor> WS A WS B Integration Identifizierung Fusion Optimierung Visiualisierung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 18 Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 19 9
Schematische Heterogenität - Beispiel Männer( Id, Vorname, Nachname) Frauen( Id, Vorname, Nachname) Relation vs. Attribut Relation vs. Wert Person( Id, Vorname, Nachname, männlich, weiblich) Person( Id, Vorname, Nachname, Geschlecht) Attribut vs. Wert 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 20 Schematische Heterogenität - Beispiel Normalisiert vs. Denormalisiert Assoziationen zwischen Werten wird unterschiedlich dargestellt Durch Vorkommen im gleichen Tupel Durch Schlüssel-Fremdschlüssel Beziehung ARTICE artpk title pages AUTHOR artfk name vs. PUBICATION pubid title date author 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 21 10
Schematische Heterogenität - Beispiel Geschachtelt vs. Flach Assoziationen werden unterschiedlich dargestellt Als geschachtelte Elemente Als Schlüssel-Fremdschlüssel Beziehung ARTICE artpk title pages AUTHOR name vs. PUBICATION pubid title author 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 22 Schema Mapping Beispiel Normalisiert vs. Denormalisiert 1:1 Assoziationen zwischen Werten wird unterschiedlich dargestellt Durch Vorkommen im gleichen Tupel Durch Schlüssel- Fremdschlüssel Beziehung ARTICE artpk title pages AUTHOR artfk name PUBICATION pubid title date author SEECT artpk AS pubid title AS title null AS date null AS author FROM ARTICE UNION SEECT null AS pubid null AS title null AS date name AS author FROM AUTHOR 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 23 11
Schema Mapping Beispiel ARTICE artpk title pages AUTHOR artfk name SEECT FROM WHERE PUBICATION pubid title date author Dies ist nur eine von vier Interpretationen! artpk AS pubid title AS title null AS date name AS author ARTICE, AUTHOR ARTICE.artPK = AUTHOR.artFK 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 24 Schema Mapping Beispiel PUBICATION title date author SEECT SK(title) AS artpk title AS title null AS pages FROM PUBICATION ARTICE artpk title pages AUTHOR artfk name SEECT SK(title) AS artfk author AS name FROM PUBICATION 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 25 12
Schema Mapping im Kontext 1. Schema Matching & Korrespondenzen 2. Schema Mapping 3. Mapping Interpretation 4. Datentransformation 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 26 Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 27 13
Föderierte Datenbanken Globales Schema & direkter Zugriff auf Datenquellen Aufwändig in Implementierung und Wartung (Evolution) Skalierbarkeit und Flexibilität schlecht FDBMS Mediator ist single point of failure. Oracle, DB2 Anwendung Dateisystem service HTM Form 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 28 PDMS verallgemeinert integrierte Informationssysteme Integriertes Informationssystem Integriertes Informationssystem Integriertes Informationssystem Integriertes Informationssystem 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 29 14
Peers okale Mappings Peer Schema okale Datenquellen (lokale Schemata) Funktionalität Anfragen stellen Anfragen planen Anfragen ausführen Peer Mappings av, GaV, GaV 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 30 P 1 P 5 P 2 P 4 P6 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 31 15
Anwendungen für PDMS Peers müssen Anfragen planen und weiterleiten können. Anfrageergebnisse empfangen, transformieren und zurückreichen können. Anwendungen Wissenschaftliche Daten, life sciences Katastrophen-Datenmanagement Gesundheitsinformationssysteme / Krankenhausinformationssysteme Große, lose gekoppelte Integrationssysteme Semantic? 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 33 PDMS Projekte Mariposa Stonebraker et al. Piazza Halevy, Ives, Tatarinov et al. Hyperion Miller et al. Edutella Nejdl et al. PeerDB Ng, Ooi, Tan PIER Hellerstein et al. CoDB Franconi et al. System P Alleinstellungsmerkmale Fuzzy Pruning okale Anfrageplanung 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 34 16
PDMS vs. P2P Dateiaustausch P2P 1. Nur ganze Dateien (niedrige Granularität) 2. Einfachste Anfragen Dateinamen, Keywords 3. Unvollständige Anfrageergebnisse 4. Einfaches Schema 5. Hoch dynamisch 6. Millionen Peers 7. Datenübertragung direkt PDMS 1. Objekte (hohe Granularität) 2. Komplexe Anfragen Anfragesprache (SQ, etc.) 3. Vollständige Anfrageergebnisse (zumindest erwartet) 4. Schema 5. Annahme: Kontrollierte Dynamik 6. Zig peers 7. Datenübertragung entlang des Mapping-Pfads 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 35 PDMS vs. FDBMS Vorteile Nutzer müssen nur das eigenen Schema kennen. Alle Daten sind erreichbar (über die transitive Hülle der Mappings). Neue Schemata und Peers können leicht hinzugefügt werden (inkrementell). Mappings nur zu ähnlichsten Schemata Nachteile / Probleme Mappings automatisch erstellen Mapping Komposition Viele Mappingschritte Effizienz Skalierbarkeit Datenqualität Effiziente Platzierung von Daten Read-only oder Updates? 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 36 17
Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 37 P 1 Kurs kurs_id titel fak univ fach doz P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P 5 DB_Kurs P5.DB_Kurs(kurs_id, titel, fak, univ, doz) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) kurs_id titel fak univ doz Kurs kurs_id titel ehrt prof kurs_id sem eval fak P 2 P6.Event(kurs_id, fach, titel) P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) Fak fak P4.Arbeitet(prof, fach, ort) P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) fach P5.DB_Kurs(kurs_id, titel, fak, univ, doz) P6.Event(kurs_id, art, titel) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P6.Event(kurs_id, fach, titel) P 4 Arbeitet prof fach ort P6 Event event_id art titel 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 38 18
GaV-Anfrageumformulierung Q: P 1.q(kurs_id, titel, fak, univ, fach, doz) : P 1.Kurs(kurs_id, titel, fak, univ, fach, doz) P 1 Kurs kurs_id titel fak univ fach doz 20% M 1 2 P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) Kurs kurs_id titel ehrt prof kurs_id sem eval fak 40% P 2 Fak fak fach [] Peer001.q(kurs_id, titel, fak, univ, fach, doz) () Q [] Peer001.Kurs(kurs_id, titel, fak, univ, fach, doz) () M 1 2 [] Peer002.Kurs(kurs_id, titel) [] Peer002.ehrt(prof 1, kurs_id, sem 2, eval 3, fak) [] Peer002.Fak(fak, fach) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 40 av-anfrageumformulierung Kurs kurs_id titel ehrt prof kurs_id sem eval fak 40% P 2 Fak fak fach P 4 Arbeitet prof 10% fach ort P4.Arbeitet(prof, fach, ort) P2.ehrt(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) () M 1 2 [] Peer002.Kurs(kurs_id, titel) [] Peer002.ehrt(prof 1, kurs_id, sem 2, eval 3, fak) () M 2 4 [] Peer004.Arbeitet(prof 1, fach, ort 6) [unc] Peer002.Fak(fak, fach) [] Peer002.Fak(fak, fach) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 41 19
Sukzessive Anfrageumformulierung: Der rule-goal-tree P1.q Q P1.Kurs Peer002.q P2.Kurs P2.ehrt P2.Fak UNION JOIN P4.Arbeitet UNION JOIN UNION (deckt P2.ehrt und P2.Fak ab) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 45 Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 46 20
Effizienz gering, aufgrund redundanter Pfade Hoher fan-out im rule-goal trees. Beispiel [Schw06]: 31 Peers Avg. connectivity: 5 34378 Union- und 17035 Join-Operationen Entspricht ursprünglichem Entwurf Wie skalieren? 100e oder 1000e Peers? 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 47 Containment-basiertes Pruning in Piazza [TH04] Prune h falls (i) g enthält h (g und h am selben Peer) (ii) keine Joins zwischen g und f Vorteil: Effizienz steigt um eine Größenordnung Äquivalente Umformung: Ergebnis ist vollständig Nachteil: Globales Wissen nötig Autonomie der Peers eingeschränkt P*.f P.g Q P.h 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 48 21
Vollständigkeit in PDMS Einsicht: Vollständiges Ergebnis ist zu teuer Also: Optimierungsziel Vollständigkeit Extensionale Vollständigkeit : Tupel Intensionale Vollständigkeit : Nicht-null-Werte Projektionen und Selektionen in Peer-Mappings führen zu Informationsverlust. Idee: Gezieltes Beschneiden des Anfrageplans 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 49 Unvollständige Mappings Anfrage Peer 1 Part Descr. Make Peer 3 Part Make Peer 2 Peer 4 Part Descr. Make Part Descr. Make Peer 3 Part Descr. Make Problem: Kumulierte Projektionen in Schemata in Mappings 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 50 22
Selektive Mappings Anfrage Peer 1 (ATU) Part Descr. Peer 2 (Ford) Part Descr. Make = Ford Make = Ford Problem: Kumulierte Selektionen implizit in Schemata explizit in Mappings Punktanfragen und Bereichsanfragen Peer 4 (Opel) Part Descr. Make Peer 3 (Autohaus) Part Descr. Make (= Opel ) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 51 P 1 Kurs kurs_id titel fak univ fach doz 20% Kurs kurs_id titel ehrt prof kurs_id sem eval fak P 2 P6.Event(kurs_id, fach, titel) P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) 100 % P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P 4 100 % Arbeitet prof 10% 10 % P 5 10 % fach DB_Kurs ort P5.DB_Kurs(kurs_id, titel, fak, univ, doz) P1.Kurs(kurs_id, titel, fak, univ, fach, doz), doz = Freytag kurs_id P6 Event Fak titel 20% fak fak P4.Arbeitet(prof, fach, ort) P2.Kurs(kurs_id, titel), P2.ehrt(prof, kurs_id, sem, eval, fak), P2.Fak(fak, fach), ort 10000, ort 11000 event_id fach univ 80% art doz 100 % titel P5.DB_Kurs(kurs_id, titel, fak, univ, doz) P6.Event(kurs_id, art, titel) P1.Kurs(kurs_id, titel, fak, univ, fach, doz) P6.Event(kurs_id, fach, titel) 100 % 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 52 23
Überblick Arbeitsgruppe Informationsintegration Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 53 System P [RN05] Relationales Datenmodell mit Punkt- und Range-Anfragen GaV- und av-umformulierung Budget- und Vollständigkeitsgesteuerte Anfragebearbeitung Visualisierung der Anfragebearbeitung Aktuelle Entwicklung: Kardinalitätsschätzung mit selbstadaptiven Histogrammen Ausblick: Kostenmodell, Parallele Anfragebearbeitung, Information Overlap 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 54 24
S008_1: ocalsource S009_1: ocalsource S007_1: ocalsource Peer009: Peer Peer008 : Peer S010_1: ocalsource Peer007: Peer Peer010: Peer Peer006: Peer S006_1: ocalsource e : S001_1: ocalsource Peer001: Peer Peer005: Peer S005_1: ocalsource Peer0 02: Pee r Peer004: Peer Peer003: Peer S002_1: ocalsource S004_1: ocalsource S003_1: ocalsource System P: Physikalische Architektur Monitor Peer: Generierung Steuerung Visualisierung PDMS Peers: Speicherung lokaler Daten Anfragebearbeitung Kommunikation: Asynchron (mit Timeout) Zwischen JVMs: JXTA Monitor Peer JXTA PDMS Peers 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 55 Vollständigkeits-gesteuerte Anfragebearbeitung [RN05] Idee: Mappings mit geringem Informationsverlust bevorzugen Beschneiden des Suchraums Einfache Pruning-Strategie Annahme: potentielle Selektivitäten/Kardinalitäten einzelner Peer Mappings bekannt Threshold-basiertes Beschneiden des Anfrageplanes (s. Diagramm) Implementiert in System P Nachteile: eeres Anfrageergebnis oder unkontrollierbar hohe Kosten möglich (Worst Case) 1 0.8 0.6 0.4 0.2 0 withoutp runing moderate pruning strong pruning 100 200 300 400 500 Cost( #mappings used) 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 56 25
e Budget- und Vollständigkeitsgesteuerte Anfragebearbeitung [RN06] Idee: Beschränkung des Ressourcenbedarfs einer Anfrage Anfragen tragen eigenes Budget Auswahl von Teilplänen mit potentiell hoher Ergebnismenge Verschiedene Strategien Greedy (Depth-first) Weighted (Breadth-first) Variationen: Rückgabe nicht verbrauchten Budgets Ausblick: Auswahl vielversprechender Teilpläne ähnlich zu [NF04] 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 57 Rückblick Informationsintegration Probleme Schema Mapping Peer Data Management PDMS Architektur Anfrageplanung Skalierbarkeit System P Armin Roth http://www.informatik.hu-berlin.de/mac/systemp 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 58 26
Referenzen [CGR04] [HIST03] [Hübn06] [NF04] [RN05] [RN06] [Schw06] [TH05] Calvanese, D., Giacomo, G.D., enzerini, M., Rosati, R.: ogical foundations of peer-to-peer data integration. In: Proc. of the Symposium on Principles of Database Systems (PODS), 2004. 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übner, T.: Entwicklung einer Testumgebung für ein Peer Data Management System. Humboldt-Universität zu Berlin, Diplomarbeit, 2006. Naumann, F.; Freytag, J.-C.; eser, U.: Completeness of integrated information sources. Information Systems, 29(7):583 615, 2004. Roth, A., Naumann, F.: Benefit and cost of query answering in PDMS. In: Proc. of the Intl. Workshop on Databases, Information Systems and Peer-to-Peer Computing (DBISP2P), 2005. Roth, A., Naumann, F.: System P: Query Answering in PDMS under imited Resources. In Proc. of the Intl. Workshop on Information Integration on the (II), 2006. Schweigert, M.: Entwurf eines Peer Data Management Systems mit Steuerungs- und Simulationskomponente. Humboldt-Universität zu Berlin, Diplomarbeit, 2006. 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. 17. Mai 2006 Felix Naumann, Humboldt-Universität zu Berlin 59 27