Informationsintegration Architekturen 3 11 2004 Felix Naumann 3

Informationsintegration Architekturen 3. 11. 2004 Felix Naumann 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06

Überblick l Überblick über Informationssysteme l l l Klassifikation Weitere Kriterien Architekturen l l l 3 Schichten Architektur. . . 5 Schichten Architektur 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 2

Klassifikation von Informationssystemen nach [ÖV 99] l Orthogonale Dimensionen l l l Verteilung Autonomie Heterogenität Orthogonal in der Lösung der jeweiligen Probleme Nicht unbedingt orthogonal in ihrer Ursache 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 3

Klassifikation von Informationssystemen nach [ÖV 91] Verteilte, homogene DBS Verteilung Verteilte, föderierte DBS Verteilte, heterogene föderierte DBS Autonomie Logisch integrierte und homogene DBS Heterogenität 3. 11. 2005 Heterogene, integrierte DBS Heterogene, föderierte DBS Felix Naumann, VL Informationsintegration, WS 06/06 Homogene, föderierte DBS 4

Erweiterung der Klassifikation nach [ÖV 99] Verteilung/Distribution Peer-to-peer z. B. A 2, D 1, H 0 Client/Server Autonomie Heterogenität 3. 11. 2005 Enge Integration Semiautonom Felix Naumann, VL Informationsintegration, WS 06/06 Isolation 5

Aut 0, Dist 0, Het 0 l l l Zwar nicht verteilte, aber dennoch mehrere DBMS. Logisch integrierte, homogene Datenbanken „Composite System“ Nicht üblich Höchstens für Shared-Everything Multiprozessor Systeme 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 6

Aut 0, Dist 0, Het 1 l l l Heterogenes, integriertes DBS Mehrere DBMS, einheitliche Sicht für Nutzer Anwendungsbeispiel l Integrierter Zugriff auf mehrere l l verschiedene DBMS (hierarchisch, relational, . . . ) auf einer Maschine. Keine Autonomie und keine Verteilung 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 Heterogenität 7

Aut 0, Dist 1, Het 0 l l Client/Server Verteilung Physische Verteilung der Daten Einheitliche Sicht für Nutzer Server l l Client l l l Datenmanagement, Optimierung, Transaktionen Anwendung, GUI, Cache Management Kommunikation mittels SQL Auch l l Multiple Client / Single Server Multiple Client / Multiple Server 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 8

Aut 0, Dist 2, Het 0 l l l P 2 P Verteiltes Informationssystem Wie A 0, D 1, H 0, aber keine Unterscheidung zwischen Client und Server „PDMS“ ohne Probleme der Heterogenität und Verteilung 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 9

Aut 1, Dist 0, Het 0 l l Homogene, föderierte DBS Semi-autonom l l Mehrere ähnliche DBMS auf einer Maschine l l l Starke Autonomie, aber Wille zur Kooperation mit anderen „Föderation“, federation Jede mit einer anderen Aufgabe Gemeinsamen Software erlaubt Zugriff. Nicht besonders realistisch 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 10

Aut 1, Dist 0, Het 1 l l l Heterogene, föderierte DBMS Z. B. Katalog DBMS und Image DBMS auf einer Maschine, die gemeinsamen Zugriff erlauben. Typisches Szenario 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 11

Aut 1, Dist 1, Het 1 l l l Verteilte, heterogene, föderierte DBMS Verteilung birgt nur wenige neue Probleme Behandlung ähnlich wie A 1, D 0, H 1 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 12

Aut 2, Dist 0, Het 0 l l Multidatenbanksystem (MDBMS) Volle Autonomie l l l Unrealistisch, da keine Heterogenität und keine Verteilung l l Keine bekannte Kooperation Keine Kommunikation untereinander Könnte auch als einzige DBMS installiert werden. Z. B. mehrere Installationen der gleichen DBMS auf einer Maschine 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 13

Aut 2, Dist 0, Het 1 l l l Wie A 1, D 0, H 1 Noch realistischer Keine Interoperation untereinander möglich Integration nur in neuer, integrierender Komponente. Z. B. DBMS und WWW Server auf einer Maschine l Nicht zur Interoperation entwickelt l 3. 11. 2005 DBMS „spricht“ kein http, WWW „spricht“ kein SQL Felix Naumann, VL Informationsintegration, WS 06/06 14

Aut 2, Dist 1/2, Het 1 l l l Verteilte MDBMS Schwierigster Fall Wie A 2, D 0, H 1 l l Verteilungsprobleme eher technisch Auch: Mediator-basierte Systeme 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 15

Taxonomie nach [SL 90] DBMS l Taxonomie nach der Autonomie Dimension Lokale und nicht-lokale Nutzer werden nicht unterschieden Nutzer muss selbst integrieren und administrieren. Nur ein föderiertes Schema 3. 11. 2005 Zentralisiertes DBMS Verteiltes DBMS Einfaches, verteiltes DBMS Multidatenbanksystem Nicht-föderierte DBS Föderierte DBS (FDBS) Lose Kopplung Enge Kopplung Einfache Föderation Mehrfache Föderation Felix Naumann, VL Informationsintegration, WS 06/06 16

Überblick l Überblick über Informationssysteme l l l Klassifikation Weitere Kriterien Architekturen l l l 3 Schichten Architektur. . . 5 Schichten Architektur 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 17

Kriterien föderierter Informationssysteme nach [BKLW 99] l Weitere (nicht-orthogonale) Kriterien l l l l l Strukturierung der Komponenten Enge und lose Kopplung Datenmodell Art der semantischen Integration Transparenz Anfrage-Paradigma Bottom-up oder Top-down Entwurf Virtuell oder materialisiert Read-only oder read-&-write Gelten zumeist auch für MDBMS 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 18

1. Strukturierung der Komponenten l Strukturiert l l l Semi-strukturiert l l Festes Schema, festes Format Beispiel: Datenbanken Struktur vorhanden, aber nur teilweise bekannt Daten sind mit Semantik gelabelt Beispiel: XML Dokumente, OEM Daten Unstrukturiert l l Keine Struktur Beispiel: Textuelle Daten, Abstracts 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 19

2. Enge und lose Kopplung l Enge Kopplung l l l Festes, integriertes/föderiertes Schema l Modelliert mit Korrespondenzen Feste Anfragesprache Lose Kopplung l l Kein festes Schema l Nutzer müssen Semantik der Quellen kennen l Integrierte Sichten helfen Feste Anfragesprache Multidatabase query language (MDBQL) [LMR 90] Schema. SQL 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 20

3. Datenmodell l l Kanonisches Datenmodell (im integrierten System) l Objektorientiertes Modell l Relationales Modell l Hierarchisches Modell l Semistrukturiertes Modell l XML Datenmodell Verlustfreie Integration ist schwierig l Beispiel: OO to Relational Mapping l l l Datenquelle: OO, kanonisches Datenmodell: Relational Schlüssel erfinden Nicht-Atomare Attribute müssen untergebracht werden. § l 3. 11. 2005 struct, set, bag, list, array Semantische Beziehungen gehen verloren (Schlüssel/Fremdschlüssel) Felix Naumann, VL Informationsintegration, WS 06/06 21

4. Art der Semantischen Integration l l l Vereinigung l Simple „Konkatenation“ von Objekten Anreicherung l Mit Metadaten Fusion l Objektidentifizierung l Re-Strukturierung l l Komplementierung l Mehrere Objekte werden zu einem integriert Aggregation l Konfliktlösung Diese Techniken sind nicht ausschließlich! 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 22

5. Transparenz l Speicherorttransparenz l l l Schematransparenz l l l Physischer Ort der Daten unbekannt IP, Quellenname, DB Name Nutzer sehen nur integriertes Schema Strukturelle Konflikte werden verborgen Sprachtransparenz l l Nutzer muss nur eine Sprache beherrschen Integriertes System übersetzt. 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 23

6. Anfrage-Paradigma l l Strukturierte Anfragen l Struktur ist Nutzern bekannt. l Struktur kann in Anfrage verwendet werden. l Z. B. DBMS + SQL „Canned queries“ l Vordefinierte Anfragen (parametrisiert) Such-Anfragen l Struktur unbekannt l Information Retrieval l Z. B. Suchmaschinen auf Texten Browsing l Kein Such-Interface l WWW 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 24

7. Bottom-up oder Top-down Entwurf l l Beim Entwurf des integrierten Systems Bottom-up: l l l Ausgelöst durch den Bedarf mehrere Quellen integriert anzufragen Schemaintegration ist wichtig. Änderungen schwierig, da neu integriert werden muss. Typisches Szenario: Data Warehouse Top-down l l Ausgelöst durch globalen Informationsbedarf Vorteilhaft bei labilen Quellen Schemaintegration nicht nötig, bzw. leichter Typisches Szenario: Virtuelle Integration 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 25

7. Bottom-up Entwicklung 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 26

7. Top-down Entwicklung 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 27

8. Virtuell oder materialisiert l Virtuell l Anfragen werden in Teilanfragen übersetzt. Daten werden nur bei Bedarf übertragen und nur temporär gespeichert. Materialisiert l l Daten werden transformiert und lokal gespeichert. Anfragen werden direkt gegen die materialisierten Daten gestellt. 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 28

9. Read-only oder read-&-write l l Read-only die beliebtere Variante Write (insert & update) schwierig l l l Viele Interfaces erlauben kein Schreiben Update durch Sichten ist schwierig Bei Komplementierung: Welche Quelle? Globale Transaktionen (komplexe Protokolle) Autonomie! 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 29

Überblick l Überblick über Informationssysteme l l l Klassifikation Weitere Kriterien Architekturen l l l 3 Schichten Architektur. . . 5 Schichten Architektur 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 30

3 -Schichten Architektur l ANSI/SPARC 3 -Schichten Architektur für zentralisierte DBMS Externes. . . Externes Schema 1 Schema N Konzeptionelles Schema Internes Schema 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 31

Wdh: Das Schichtenmodell l Interne (physische) Sicht l l l Konzeptionelle (logische) Sicht l l Speichermedium (Tape, Festplatte) Speicherort (Zylinder, Block) Unabhängig von physischer Sicht Definiert durch Datenmodell Stabiler Bezugspunkt für interne und externe Sichten Externe (logische) Sicht Anwendungsprogramme l Nur auf die relevanten Daten l Enthält Aggregationen und Transformationen 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 l 32

3 -Schichten Architektur Anwendungen Externes. . . Externes Schema 1 Schema N Konzeptionelles Schema DBMS Internes Schema 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 33

4 -Schichten Architektur l l Für verteilte DBMS Neu: Trennung lokales vs. globales konzeptionelles Globales Konzeptionelles Schema ist integriert aus den lokalen konzeptionellen Schemas. Lokales und globales konzept. Schema kann gleich sein. Externes Schema 1 Externes Schema N Konzeptionelles Schema Lokales konzept. Schema Internes Schema 3. 11. 2005 . . . Felix Naumann, VL Informationsintegration, WS 06/06 . . . Internes Schema 34

4 -Schichten Architektur Anwendungen Externes Schema 1 Lokales konzept. Schema Internes Schema 3. 11. 2005 Externes Schema N Konzeptionelles Schema S M B D. t Ver Lokale DBMS . . . Felix Naumann, VL Informationsintegration, WS 06/06 . . . Internes Schema 35

Import-/Export-Schema. Architektur nach [HM 85] = lokales konzeptionelles Schema 3. 11. 2005 Idee: Nur Teilmenge des lokalen konzeptionellen Schemas wird der Föderation zur Verfügung gestellt. Felix Naumann, VL Informationsintegration, WS 06/06 Idee: Nur Teilmengen der Exportschemas sollen verwendet werden. 36

4 -Schichten Architektur l l Auch: Externes Multidatenbank. Schema 1 architektur [LMR 90] Voraussetzung l Nutzer kennen die Export-Schema jeweiligen Schemas l Multidatenbankspr Lokales konzept. ache Schema Lokales und globales konzept. Schema kann gleich sein. Internes Schema Lose Kopplung = physisches . . . Externes Schema N Export-Schema . . . Lokales konzept. Schema. . . Internes Schema 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 37

4 -Schichten Architektur Anwendungen (müssen selbst integrieren) Externes Schema 1 . . . Export-Schema Lokale DBMS Lokales konzept. Schema Internes Schema 3. 11. 2005 Externes Schema N Felix Naumann, VL Informationsintegration, WS 06/06 . . . Internes Schema 38

5 -Schichten Architektur [SL 90] l l Neu: l Interne Schemas werden nicht mehr betrachtet. l Exportschemas l Integriertes, föderiertes Schema Terminologie l Komponentenschema = lokales konzept. Schema l Föderiertes Schema = globales konzept. Schema 3. 11. 2005 Externes Schema 1 . . . Externes Schema N Föderiertes Schema Exportschema Komponenten-. . . Komponentenschema Lokales Schema Felix Naumann, VL Informationsintegration, WS 06/06 . . . Lokales Schema 39

5 -Schichten Architektur [SL 90] Anwendungen Externes Schema 1 . . . Externes Schema N Föderiertes Schema S M B D. Föd Lokale DBMS Exportschema Komponentenschema Lokales internes Schema 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 Exportschema. . . Komponentenschema Lokales internes Schema 40

5 -Schichten Architektur [SL 90] l Lokale Schemas l l Komponentenschemas l l Konzeptionell Kanonisches Datenmodell Fügt fehlende Semantik hinzu. Übergang durch Mappings. Exportschemas l l Teilmenge des Komponentenschemas Verwaltet Zugangsberechtigungen 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 41

5 -Schichten Architektur [SL 90] l Föderiertes Schema l Integriert aus den Exportschemas l Kennt Datenverteilung l Andere Namen: l l l Import Schema Globales Schema Enterprise Schema Unified Schema Externes Schema l Föderiertes Schema kann sehr groß sein Vereinfachung im Exportschema l „Schema Evolution“ leichter l Zusätzliche Integritätsbedingungen l Zugangskontrollen 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 42

5 -Schichten Architektur [SL 90] l Mischformen l Einige Schichten nicht immer nötig. l l l Z. B. wenn lokales und Komponentenschema gleich sind. Z. B. wenn komplettes Komponentenschema exportiert werden soll. Ein Komponentenschema kann mehrere Exportschemas haben. Große FDBS können mehrere föderierte Schemas haben. Föderation! l Nur semi-autonom l Lokale DBMS müssen bereits kanonisches Datenmodell unterstützen. 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 43

Vergleich der Architekturen [Con 97] l Import/Export 1. 2. 3. 4. l Lose Kopplung Integration durch Nutzer und globalen Admin Zugriff über lokales System Keine globale DBMSFunktionalität 3. 11. 2005 4 -Schichten 1. Lose Kopplung 2. l Integration durch Nutzer Zugriff über globale Schnittstellen 4. DBMSFunktionalität nur durch Multidatenbank. Felix Naumann, VL Informationsintegration, WS 06/06 sprachen 3. 5 -Schichten 1. 2. 3. 4. Lose und enge Kopplung Integration durch globalen Administrator Zugriff durch globales System DBMSFunktionalität im globalen System 44

Zusammenfassung l 1. l 2. VL 7 (8. 11. 05) 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 45

Literatur l Wichtige Literatur l l [ÖV 99] Principles of Distributed Database Systems. M. Tamer Özsu, Patrick Valduriez, Prentice Hall, 1999. [SL 90] Amit P. Sheth and James A. Larson, Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases, ACM Computing Surveys, Vol. 22(3), pp 183 -236, 1990. [Con 97] Stefan Conrad, Föderierte Datenbanksysteme. Springer, Heidelberg 1997. Weitere Literatur l l [LMR 90] W. Litwin, L. Mark, N. Roussoupoulos, Interoperability of Multiple Autonomous Databases, ACM Computing Surveys, Vol. 22(3), pp 267 -293, 1990. [HM 85] Dennis Heimbigner, Dennis Mc. Leod: A Federated Architecture for Information Management. ACM Trans. Inf. Syst. 3(3): 253 -278 (1985) 3. 11. 2005 Felix Naumann, VL Informationsintegration, WS 06/06 46