Informationsintegration

Transkript

1 Informationsintegration Architekturen Ulf Leser Wissensmanagement in der Bioinformatik

2 Übersicht Technische Heterogenität Technische Realisierung des Datenzugriffs Technische Unterschiede in der Darstellung Syntaktische Unterschiede Unterschiede in der Darstellung Gleiche Dinge syntaktisch verschieden repräsentieren Datenmodellheterogenität Strukturelle Heterogenität Strukturelle Unterschiede in der Darstellung Gleiche Dinge verschieden modellieren Semantische Heterogenität Unterschiede in der Bedeutung von Namen (Schema und Daten) Gleiches sagen, verschiedenes meinen (oder andersrum) Ulf Leser: Informationsintegration, Wintersemester 2006/2007 2

3 Ausprägung 2 Anfrage Integriertes Informationssystem Heterogenität zwischen globaler Schicht und Datenquellen Quelle Ulf Leser: Informationsintegration, Wintersemester 2006/2007 3

4 Technische Heterogenität Ulf Leser: Informationsintegration, Wintersemester 2006/2007 4

5 Mächtige globale Anfragesprache SQL SELECT * FROM Books WHERE Author = Defoe AND PubYear = 1979 HTML Form Ulf Leser: Informationsintegration, Wintersemester 2006/2007 5

6 Kompensation möglich SELECT * FROM Books WHERE Author = Defoe AND PubYear = 1979 Daniel Defoe, Robinson Crusoe, 1979 PubYear = 1979 Daniel Defoe, Robinson Crusoe, 1986 Daniel Defoe, Robinson Crusoe, 1979 Daniel Defoe, Moll Flanders, 1933 Defoe Ulf Leser: Informationsintegration, Wintersemester 2006/2007 6

7 Syntaktische Heterogenität Unterschiedliche Darstellung desselben Sachverhalts Dezimalpunkt oder komma Euro oder Comma-separated oder tab-separated HTML oder ASCII oder Unicode Notenskala 1-6 oder sehr gut, gut, Binärcodierung oder Zeichen Datumsformate (12. September 2006, , 9/12/2006, ) Überwindung in der Regel nicht problematisch Umrechnung, Übersetzungstabellen, Ulf Leser: Informationsintegration, Wintersemester 2006/2007 7

8 Strukturelle Heterogenität Allgemein Gleiche Dinge in unterschiedlichen Schemata ausdrücken Andere Aufteilung von Attributen auf Tabellen Fehlende / neue Attribute (wenn Intension nicht betroffen ist) Setzt intensionale Überlappung voraus ( gleiche Dinge ) Meistens mit semantischen Heterogenität verbunden Ausnahme: 1:1 Beziehungen Spezialfall: Schematische Heterogenität Verwendung anderer Elemente eines Datenmodells Kann meist nicht durch Anfragesprachen überwunden werden Ulf Leser: Informationsintegration, Wintersemester 2006/2007 8

9 Spezialfall: Schematische Heterogenität maenner( Id, vorname, nachname) frauen( Id, vorname, nachname) Relation vs. Attribut Relation vs. Wert person( Id, vorname, nachname, maennlich?, weiblich?) person( Id, vorname, nachname, geschlecht) Attribut vs. Wert Ulf Leser: Informationsintegration, Wintersemester 2006/2007 9

10 Integrierte Sichten Verlangt viele Verrenkungen Sicht muss angepasst werden, wenn neue Filmtypen vorliegen Datenänderungen bedingen Schemaänderungen Das will man unbedingt vermeiden Ulf Leser: Informationsintegration, Wintersemester 2006/

11 Semantik von was? Name Extension Intension Realweltliche Objekte repräsentiert Konzept Ulf Leser: Informationsintegration, Wintersemester 2006/

12 Probleme Mögliche Beziehungen zwischen den Mengen realweltlicher Objekte, die Konzepte repräsentieren A=B (Äquivalenz): semantische (echte) Synonyme Kreditinstitut, Bank (?) Gibt es echte Synonyme? A B (Inklusion): B ist Hyperonym (Oberbegriff) zu A; A ist Hyponym zu B Tochter Kind A B A B (Überlappung): Schwierigster Fall Küche-Kochnische; Haus-Gebäude; Regisseur-Schauspieler A B = (Disjunktion): nicht verwandte Begriffe (häufigster Fall) Dose-Lohnsteuerjahresausgleich Ulf Leser: Informationsintegration, Wintersemester 2006/

13 Semantik: Woher nehmen? Schemaelemente sind erst mal nur Namen Was bestimmt die Semantik eines Namens? Für Attributnamen Datentyp Constraints (Schlüssel, FK, unique, CHECK, ) Zugehörigkeit zu einer Relation Andere Attribute dieser Relation Beziehung der Relation zu anderen Relationen Dokumentation Vorhandene Werte Wissen über den Anwendungsbereich Der Kontext Ulf Leser: Informationsintegration, Wintersemester 2006/

14 Kontext Semantik eines Namens hängt vom Kontext ab Beispiel Unternehmen A: angestellte( ) Unternehmen B: mitarbeiter( ) Mitarbeiter und Angestellte kann man als Synonyme betrachten Aber: A.angestellte B.mitarbeiter = Wenn Personen nicht in zwei Unternehmen beschäftigt sind Erst bei einem Merger von A und B werden A.angestellte und B.mitarbeiter zu Synonymen Sollten dann zu einer Tabelle integriert werden Ulf Leser: Informationsintegration, Wintersemester 2006/

15 Entstehung von Inter-Source-Konflikten Bei der Integration von Informationssystemen Lokal konsistent aber global inkonsistent Voraussetzung sind Duplikate Extensionale Redundanz Andere Datentypen ( 1 versus eins ) Andere lokale Schreibweisen oder Konventionen Skalen (inch cm), Währungen, rechtliche Bedingungen (MWST), Übertragungsfehler Fehlerhafte Parser beim ETL Fehlendes Verständnis für die Bedeutung der Dinge Mangelnde Dokumentation, falsches Re-engineering, Verwendung unterschiedlicher Standards Produktnummern, Produktklassen, Berufsbezeichnungen, Verschiedene Messungen Temperatur an einem Tag? Ulf Leser: Informationsintegration, Wintersemester 2006/

16 Voraussetzung: Identität Konzept = Realweltobjekt Name = Identifikation, Schlüssel Duplikate: Semantische Konflikte auf Datenebene Synonyme: Verschiedene IDs für gleiches Objekt Personalausweisnummer und Führerscheinnummer ISBN und Kombination Autor/Titel Homonym: Gleiche IDs für verschiedene Objekte Dann ging was schief (gefälschte Pässe, ) Oder über Unternehmensgrenzen hinweg (Kunden.ID, ) Schwieriges Problem: Lokale IDs Schlüssel gelten in einer Tabelle Häufig verwendet man nur surrogate Keys (sequence) Die bedeuten nichts außerhalb der eigenen Datenbank Integration erfordert Duplikaterkennung Ulf Leser: Informationsintegration, Wintersemester 2006/

17 Transparenz Verteilung, Autonomie, Heterogenität kann in unterschiedlichem Maße überwunden werden Ortstransparenz Benutzer müssen den Ort der integrierten Systeme nicht kennen Keine URLs, Datenbankpräfixe, Quellentransparenz, Verteilungstransparenz Benutzer weiß nicht, welche Quelle für eine Anfrage benutzt werden kann (und muss daher nicht auswählen) Benutzer weiß nicht, welche Quelle für eine Anfrage benutzt wurde (Datenherkunft) Setzt ein globales Schema voraus Ulf Leser: Informationsintegration, Wintersemester 2006/

18 Will man nicht immer! Intuitiv strebt man maximale Transparenz an Tatsächlich ist das oft kontraproduktiv Benutzer kennen und lieben ihre Datenquellen Datenherkunft ist wichtigstes Kriterium für Einschätzung der Qualität der Informationen Zugriff durch globales Schemas nur bei Kenntnis dieses Benutzer muss neues Schema lernen Globale Schemata können sehr kompliziert werden Da sie viele Quellen integrieren Für kleine Zugriffe unnötig schwierig Transparenz bedingt Informationsverlust Ulf Leser: Informationsintegration, Wintersemester 2006/

19 Inhalt diese Vorlesung Klassifikation Verteilter, autonomer, heterogener Systeme Führt zu möglichen Architekturen Weitere Klassifikationskriterien Schichtenaufbau integrierter Systeme 3-5 Schichten Ulf Leser: Informationsintegration, Wintersemester 2006/

20 Klassifikation [ÖV91] Verteilte, homogene DBS Verteilung Verteilte, föderierte DBS Verteilte, heterogene DBS Logisch integrierte und homogene DBS Heterogenität Verteilte, heterogene föderierte DBS Autonomie Ulf Leser: Informationsintegration, Wintersemester 2006/

21 Verteilung 1. Zentrale Datenbank Autonomie Heterogenität Normalfall homogene, zentrale Datenbank Daten/Berechnung können trotzdem begrenzt verteilt sein Filesystem: Partitionierung, RAID, SAN Berechnung: Cluster Parallele Datenbanken Datenbank entsteht aus homogenem Entwurf Wenn Redundanz / Heterogenität, dann mit Absicht und kontrolliert Problem: Weiterentwicklung (Evolution) Zentrale Kontrolle und Administration Ulf Leser: Informationsintegration, Wintersemester 2006/

22 Verteilung 2. Verteilte Datenbanken Autonomie Daten liegen physisch verteilt Absichtsvolle, kontrollierte, a-priori Verteilung Existenz eines konzeptionell homogenen, verteilt realisierten Schemas Ziele Höhere Performanz durch Parallelisierung Höhere Sicherheit vor Katastrophen Höhere Ausfallsicherheit durch redundant ausgelegte Systeme (Replikation) Knoten haben keine Autonomie Heterogenität wird unterdrückt Ortstransparenz, aber keine Verteilungstransparenz Aliase und Proxy kapseln entfernte Orte Heterogenität Verteilungstransparenz durch Sichten möglich, aber nicht durch System erzeugt Ulf Leser: Informationsintegration, Wintersemester 2006/

23 Einschub: Verteilte Datenbanken mit Oracle Oracle-DB können auf andere Oracle-DB zugreifen Database Links CREATE [PUBLIC] DATABASE LINK <link_name> CONNECT TO <user_name> <IDENTIFIED BY <password> USING '<service_name>'; service_name muss über Konfigurationsfiles aufgelöst werden SELECT col1, col2, FROM Zugriff wie auf lokale Tabelle (Joins, Selektion, Projektion, ) Transparenz durch Sicht möglich CREATE VIEW myview AS SELECT * FROM tab1@link_name; Schwieriger Verteilte Optimierung (später) 2-phase-commit Anwendung (z.b.): automatische Replikation Verschiedene Refresh-Optionen Ulf Leser: Informationsintegration, Wintersemester 2006/

24 Einschub: Partitionierung Aufteilung der Daten einer Tabelle in Untereinheiten Für den Benutzer transparente Partitionierung Nach Definition der Partitionen Muss vom System unterstützt werden Für den Benutzer nicht transparente Partitionierung Explizites Anlegen mehrerer Tabellen Anfragen müssen entsprechend formuliert werden Geht immer Daten sind im Ergebnis physisch verteilt Verschiedene Platten, verschiedene Controller Voraussetzung zur verteilten Bearbeitung Ulf Leser: Informationsintegration, Wintersemester 2006/

25 Vertikale Partitionierung id price amount code form CASH VISA VISA id price amount id code form CASH VISA VISA Ulf Leser: Informationsintegration, Wintersemester 2006/

26 Bewertung Zerstört semantische Einheiten die Tupel Zusammenfassen erfordert (teure) Joins Geeignete Technik zur Auslagerung... von selten benutzten Attributen von Attributen, die häufiger als andere verändert werden (und deshalb zu Reorganisation / Row Splits führen) von BLOBs, LONG, etc. Transparenz für Benutzer ist möglich Definition eines Views Performanceverschlechterung, wenn Optimierer mit dem View nicht richtig umgehen kann Benötigt immer zusätzliche Joins Forschung: Column-wise databases Ulf Leser: Informationsintegration, Wintersemester 2006/

27 Horizontale Partitionierung id price amount code form CASH VISA VISA CASH CASH CASH VISA CASH VISA VISA CASH VISA Ulf Leser: Informationsintegration, Wintersemester 2006/

28 Horizontale Partitionierung Wichtige Erweiterung der meisten kommerziellen RDBMS der letzten Jahre Hauptvorteile Datenmanagement Partitionen als eigenständige Datenbankobjekte Parallele Verarbeitung Scans können Partitionen auslassen (Partition pruning) Ulf Leser: Informationsintegration, Wintersemester 2006/

29 Prinzip CREATE TABLE sales_range (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE(sales_date) ( PARTITION t21 VALUES LESS THAN(TO_DATE('02/01/2000','DD/MM/YYYY')), PARTITION t22 VALUES LESS THAN(TO_DATE('03/01/2000','DD/MM/YYYY')), PARTITION t23 VALUES LESS THAN(TO_DATE('04/01/2000','DD/MM/YYYY')), PARTITION t24 VALUES LESS THAN(TO_DATE('05/01/2000','DD/MM/YYYY')) ); Partitionen sind eigene Datenbankobjekte Eigene DDL Kommandos Müssen explizit angelegt werden Können einzeln positioniert und gemanaged werden Nach Anlage vollkommen transparente Benutzung Partitionierungskriterium kann auch jederzeit geändert werden Ulf Leser: Informationsintegration, Wintersemester 2006/

30 Verteilte versus parallele Datenbanken ANSI/SPARC 3-Schichten Architektur für zentralisierte DBMS Externes Schema 1... Externes Schema N Konzeptionelles Schema Internes, physisches Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

31 Vergleich Parallele Datenbank Verteilte Datenbank Externes Schema 1... Externes Externes Schema N Schema 1... Externes Schema N Konzeptionelles Schema Konzep. Schema Konzep. Schema Internes, physisches Schema Internes Schema Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

32 Einschub: Parallele Datenbanken Auswirkung nur auf der physischen Schicht Es existiert nur ein logisches Schema Interquery: Queries werden (jeweils als ganzes) auf verschiedene Knoten verteilt Intraquery: Einzelne Queries werden aufgebrochen und die Fragmente verteilt (z.b. Partitionen) Shared Nothing (DB2) Verschiedene Knoten haben eigene Platten Zentrale Instanz verteilt Anfragen Verteilungsmöglichkeiten mit Konfiguration festgelegt Shared Disc (Oracle) Alle Knoten greifen auf gleiche Platten zu Schwierige Synchronisation Dynamische Verteilung je nach Last möglich Ulf Leser: Informationsintegration, Wintersemester 2006/

33 Einschub: Gateways Ähnlich verteilte Datenbanken Zugriff z.b. über ODBC Umwandlung von Datentypen Unterstützung verschiedener SQL-Dialekte Kompensation fehlender Funktionen Siehe auch: GARLIC (später) Ulf Leser: Informationsintegration, Wintersemester 2006/

34 Verteilung 3. Verteilte & heterogene DB Autonomie Daten liegen physisch verteilt vor Daten sind heterogen Z.B. aufgrund der Historie der Entstehung Keine Autonomie Heterogenität sollte also nicht schlimmer werden Typischer Zwischenzustand Heterogenität Ulf Leser: Informationsintegration, Wintersemester 2006/

35 Verteilung 4. Verteilte & autonome DB Autonomie Heterogenität Verteilte, aber homogene Datenbestände Entsteht durch freiwillige Übernahme von Regeln Standards, Verträge, Autonomie wird teilweise aufgegeben Z.B. Aufgabe von Designautonomie Z.B. nicht Kommunikationsautonomie Z.B. nicht juristische Autonomie Ulf Leser: Informationsintegration, Wintersemester 2006/

36 Verteilung 5. Multidatenbanken Autonomie Verteilt, autonom, und etwas heterogen Keine technische und Datenmodellheterogenität Z.B.: verteilte Systeme benutzen gleiche Techniken (RDBMS) Schemata können strukturell und semantisch heterogen sein Zugriff über einheitliche Sprache Oder Simulation durch Wrapper (später) Autonomie bleibt bewahrt Aber Zugriff muss möglich sein (Kommunikationsautonomie) Zugriff über Multidatenbanksprachen Qualifizierung von Tabellennamen mit Datenbanknamen Ähnlich Database-Links; Beispiel: SchemaSQL Heterogenität Ulf Leser: Informationsintegration, Wintersemester 2006/

37 Verteilung 6. Verteilt, heterogen, autonom Autonomie Das ist das hauptsächliche Szenario dieser Vorlesung Quellen behalten volle Autonomie Wissen u.u. nichts von ihrer Integration Nehmen u.u. keine Rücksicht bzgl. Änderungen Quellen sind heterogen Quellen sind verteilt Heterogenität Ulf Leser: Informationsintegration, Wintersemester 2006/

38 Taxonomie nach [SL90] DBMS Kontrollierte, gewollte Verteilung Kein Zugriff durch einheitlichen Mechanismus Zentralisiertes DBMS Einfaches, verteiltes DBMS Nicht-föderierte DBS Verteiltes DBMS Multidatenbanksystem Föderierte DBS (FDBS) Nutzer muss selbst integrieren (durch Views etc.) Lose Kopplung Enge Kopplung Nur ein föderiertes Schema Einfache Föderation Mehrfache Föderation Ulf Leser: Informationsintegration, Wintersemester 2006/

39 Überblick Klassifikation Verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter Systeme 3-5 Schichten Prominente Architekturen Ulf Leser: Informationsintegration, Wintersemester 2006/

40 Kriterien föderierter Informationssysteme Nach [BKLW99] Weitere (nicht-orthogonale) Kriterien 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 Ulf Leser: Informationsintegration, Wintersemester 2006/

41 Struktur der Komponenten Strukturiert Festes Schema, festes Format Beispiel: Datenbanken Semi-strukturiert Struktur vorhanden, aber höchstens teilweise festgelegt Individuelle Abweichungen jederzeit möglich Vor allem neue Attribute, Tabellen, Elemente, Prädikate, Daten sind mit semantischen Tags versehen Beispiel: XML/RDF ohne Schemata, OEM Daten, UNQL, ACeDB, Unstrukturiert Keine Struktur Search, Information Retrieval, Informationsextraktion Beispiel: Textuelle Daten, Webseiten, Berichte Ulf Leser: Informationsintegration, Wintersemester 2006/

42 Enge oder lose Kopplung Enge Kopplung Festes, integriertes/föderiertes Schema Korrespondenzen regeln die Zusammenhänge Für den Benutzer einheitliche Sicht Erfordert Kooperation der Quellen Anpassungen, Schemaevolution Lose Kopplung Kein globales, einheitliches Schema Nutzer müssen Semantik der Quellen kennen Nutzer integrieren selber Nur technische und Datenmodellheterogenität ist gelöst Verlangt weniger Kooperation Zugriff muss möglich sein, aber Schemata können sich ändern Multidatabase query language (MDBQL) Ulf Leser: Informationsintegration, Wintersemester 2006/

43 Verwendetes Datenmodell Kanonisches Datenmodell Objektorientiertes Modell Relationales Modell XML Datenmodell Abbildung zwischen Datenmodellen ist schwierig Relational zu XML Abbildung von m:n Beziehungen? OO zu Relational Schlüssel versus ID, Assoziation versus Foreign Keys, Vererbung? Abbildung in semantisch schwächere Datenmodelle bringt Verlust Muss durch Anwendung kompensiert werden Integration semantisch starker Modelle ist schwieriger Ulf Leser: Informationsintegration, Wintersemester 2006/

44 Art der semantischen Integration Vereinigung Simple Konkatenation von Objekten Anreicherung Mit Metadaten Keine Konfliktauflösung Erzeugt mehr, aber nicht notwendigerweise bessere Daten Sehr häufig! Datenfusion Objektidentifizierung Re-Strukturierung Komplementierung Konfliktlösung Ulf Leser: Informationsintegration, Wintersemester 2006/

45 Welche Transparenz wird erreicht? Orttransparenz Physischer Ort der Daten unbekannt IP, Quellenname, DB Name Verteilungstransparenz Nutzer sehen nur integriertes Schema Strukturelle Konflikte werden verborgen Schnittstellentransparenz Nutzer muss nur eine Sprache beherrschen Integriertes System übersetzt Ulf Leser: Informationsintegration, Wintersemester 2006/

46 Welche Art von Anfragen werden unterstützt? Strukturierte Anfragen Schema ist Nutzern bekannt und wird in Anfragen verwendet Z.B. SQL, OQL, QBE Canned queries Vordefinierte Anfragen mit Parametern Z.B.: Webformulare, Funktionen Such-Anfragen (Information Retrieval) Struktur unbekannt oder nicht vorhanden Z.B. Suchmaschinen auf Texten Browsing Kein Such-Interface Beispiel: WWW, Hypertext, Reports Ulf Leser: Informationsintegration, Wintersemester 2006/

47 Bottom-up oder Top-down Entwurf Bottom-up Beginnt mit dem Bedarf nach der Integration einer festen Menge von genau bestimmten Quellen Globales Schema wird durch Schemaintegration erstellt Änderungen in Quellen i.d.r. schwierig (Neuintegration) Verbunden mit hohen Ansprüchen an Vollständigkeit und Qualität Typisches Szenario: Data Warehouse, Merging von Unternehmensdatenbanken Top-down Ausgelöst durch globalen Informationsbedarf Neuentwurf des globalen Schemas Quellen werden nach Bedarf und Eignung hinzugefügt Verlangt flexiblere Integrationsmechanismen Vorteilhaft bei volatilen Quellen (Web) Verbunden mit geringeren Ansprüchen an Vollständigkeit und Qualität Typisches Szenario: Webintegration, Integration als Service Ulf Leser: Informationsintegration, Wintersemester 2006/

48 Bottom-up Entwicklung Ulf Leser: Informationsintegration, Wintersemester 2006/

49 Top-down Entwicklung Ulf Leser: Informationsintegration, Wintersemester 2006/

50 Virtuell oder materialisiert Virtuell Kein zentraler Datenpool Anfragen werden in Teilanfragen zerlegt und in den Quellen beantwortet Daten werden nur bei Bedarf übertragen und höchstens temporär gespeichert Immer aktuell, potentiell langsam, eingeschränkte Queries Materialisiert Aufbau eines zentralen Datenpools Redundante Datenhaltung Daten werden offline transformiert und integriert Anfragen werden direkt gegen die materialisierten Daten gestellt Potentiell veraltet, sehr schnell, volle Queries Setzt Zugriff auf komplette Datenbasis voraus Später mehr Ulf Leser: Informationsintegration, Wintersemester 2006/

51 Read-only oder read-&-write Read-only die beliebtere Variante Write (insert & update) schwierig Viele Interfaces erlauben kein Schreiben Update durch Sichten ist schwierig Bei Komplementierung: Welche Quelle? Globale Transaktionen (komplexe Protokolle) Autonomie! Ulf Leser: Informationsintegration, Wintersemester 2006/

52 Überblick Klassifikation Verteilter, autonomer, heterogener Systeme Führt zu möglichen Architekturen Weitere Klassifikationskriterien Schichtenaufbau integrierter Systeme 3-5 Schichten Prominente Architekturen Ulf Leser: Informationsintegration, Wintersemester 2006/

53 ANSI/SPARC 3-Schichten Architektur Externe (logische) Sicht Je nach Anwendung Nur relevante Daten Sichten (Views) Konzeptionelle (logische) Sicht Unabhängig von physischer Sicht Definiert durch Datenmodell Stabiler Bezugspunkt Interne (physische) Sicht Dateistruktur Speicherort (Zylinder, Block) Indexe, Partitionen, Ulf Leser: Informationsintegration, Wintersemester 2006/

54 3-Schichten Architektur Anwendungen Externes Schema 1... Externes Schema N DBMS Konzeptionelles Schema Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

55 4-Schichten Architektur Für verteilte DBMS Lokales vs. globales konzeptionelles Schema Globales konzeptionelles Schema integriert die lokalen konzeptionellen Schemata Lokales und globales konzeptionelles Schema können gleich sein Aber Datenbestände unterschiedlich Externes Schema 1 Lokales konzept. Schema Internes Schema... Konzeptionelles Schema Externes Schema N Lokales konzept. Schema Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

56 4-Schichten Architektur Anwendungen Externes Schema 1... Externes Schema N Vert. DBMS Konzeptionelles Schema Lokale DBMS Lokales konzept. Schema... Lokales konzept. Schema Internes Schema... Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

57 Import-/Export-Schema-Architektur [HM85] = lokales konzeptionelles Schema Idee: Nur Teilmenge des lokalen konzeptionellen Schemas wird der Föderation zur Verfügung gestellt. Idee: Nur Teilmengen der Exportschemas sollen verwendet werden. Ulf Leser: Informationsintegration, Wintersemester 2006/

58 Multidatenbankarchitektur Siehe [LMR90] Voraussetzung Nutzer kennen die jeweiligen Schemas Multidatenbanksprache Lose Kopplung Externes Schema 1 Export-Schema... Externes Schema N Export-Schema Lokales konzept. Schema... Lokales konzept. Schema Internes Schema... Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

59 4-Schichten Architektur Anwendungen Anwendungen müssen selbst integrieren Externes Schema 1 Export-Schema... Externes Schema N Export-Schema Lokale DBMS Lokales konzept. Schema... Lokales konzept. Schema Internes Schema... Internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

60 5-Schichten Architektur [SL90] Eigentlich 6 Schichten Interne Schemas werden nicht mehr betrachtet Integriertes, föderiertes Schema Komponentenschema = lokales konzept. Schema Föderiertes Schema = globales konzept. Schema Externes Schema 1 Föderiertes Schema Exportschema Lokales Schema Externes Schema N Exportschema Komponentenschema Komponentenschema Lokales Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

61 5-Schichten Architektur [SL90] Anwendungen Externes Schema 1... Externes Schema N Föderiertes DBMS Föderiertes Schema Exportschema Exportschema Lokale DBMS... Komponentenschema Komponentenschema Lokales internes Schema Lokales internes Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

62 5-Schichten Architektur [SL90] Exportschemas Teilmenge des Komponentenschemas Zugangsberechtigungen Unnötig, wenn komplettes Schema exportiert wird Komponentenschemas Kanonisches Datenmodell Fügt fehlende Semantik hinzu Übergang durch Mappings Unnötig, wenn lokales = kanonisches Datenmodell Lokale Schemas Konzeptionell Externes Schema 1 Föderiertes Schema Exportschema Lokales Schema Externes Schema N Exportschema Komponentenschema Komponentenschema Lokales Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

63 5-Schichten Architektur [SL90] Externes Schema Föderiertes Schema kann sehr groß sein Vereinfachung im Exportschema Schema Evolution leichter Zugangskontrollen Föderiertes Schema Integriert aus den Exportschemas Kennt Datenverteilung Andere Namen: Import, global, unified, Enterprise Schema Externes Schema 1 Föderiertes Schema Exportschema Lokales Schema Externes Schema N Exportschema Komponentenschema Komponentenschema Lokales Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

64 Überblick Klassifikation Verteilter, autonomer, heterogener Systeme Führt zu möglichen Architekturen Weitere Klassifikationskriterien Schichtenaufbau integrierter Systeme 3-5 Schichten Prominente Architekturen Ulf Leser: Informationsintegration, Wintersemester 2006/

65 Data Warehouses Quelle 1 RDBMS Staging Area Metadaten Mart 2 Quelle 2 IMS Staging Area Cube Mart 1 Materialisierte Integration Regelmäßiger Export, Transformation, Import einer festen Zahl von Datenquellen (ETL Prozess) Redundante Datenhaltung wegen unterschiedlicher Verwendung (OLAP versus OLTP) Kommerziell extrem wichtig Ulf Leser: Informationsintegration, Wintersemester 2006/

66 Mediator-Wrapper Architektur Virtuelle Integration Unabhängig von Strukturiertheit Quellspezifische Wrapper Datenmodelltransformation Übersetzung von Anfragen Mediatoren als Mehrwertdienste Datenintegration Verdichtung Anwendung 1 Anwendung 2 Mediator Wrapper 1 Wrapper 2 Wrapper 3 Quelle 1 Quelle 2 Quelle 3 Ulf Leser: Informationsintegration, Wintersemester 2006/

67 Föderierte Datenbanken Trotz häufiger Verwendung keine klare Definition vorhanden Klassischer Definition: 5-Schichten Architektur Lokales Schema, Komponentenschema, Exportschema, föderiertes Schema, externes Schema Integrierte Schemata verlangen aber semantische Integration Datenbankhersteller meiden dieses Gebiet Federated databases heute Allgemeiner Begriff für integrierten Zugang Kommerziell meistens über Multidatenbanksprachen Definition von Sichten zur Erstellung (teil-)integrierter Schema Ulf Leser: Informationsintegration, Wintersemester 2006/

68 Einordnung Distributed Databases Complexity Ulf Leser: Informationsintegration, Wintersemester 2006/

69 Literatur Wichtige Literatur [ÖV99] Principles of Distributed Database Systems. M. Tamer Özsu, Patrick Valduriez, Prentice Hall, [SL90] Amit P. Sheth and James A. Larson, Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases, ACM Computing Surveys, Vol. 22(3), pp , [Con97] Stefan Conrad, Föderierte Datenbanksysteme. Springer, Heidelberg Weitere Literatur [LMR90] W. Litwin, L. Mark, N. Roussoupoulos, Interoperability of Multiple Autonomous Databases, ACM Computing Surveys, Vol. 22(3), pp , [HM85] Dennis Heimbigner, Dennis McLeod: A Federated Architecture for Information Management. ACM Trans. Inf. Syst. 3(3): (1985) Ulf Leser: Informationsintegration, Wintersemester 2006/