Informationsintegration

Transkript

1 Informationsintegration Architekturen Vergleichskriterien für integrierte Systeme 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 ( und Daten) Gleiches sagen, verschiedenes meinen (oder andersrum) Ulf Leser: Informationsintegration, Wintersemester 2008/2009 2

3 Technische Heterogenität Ulf Leser: Informationsintegration, Wintersemester 2008/2009 3

4 Mächtigere globale Anfragesprache SQL SELECT * FROM Books WHERE Author = Defoe AND PubYear = 1979 HTML Form Ulf Leser: Informationsintegration, Wintersemester 2008/2009 4

5 Kompensation 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 2008/2009 5

6 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 2008/2009 6

7 Strukturelle Heterogenität Allgemein Gleiche Dinge in unterschiedlichen ta 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: tische Heterogenität Verwendung anderer Elemente eines Datenmodells Kann meist nicht durch Anfragesprachen überwunden werden Ulf Leser: Informationsintegration, Wintersemester 2008/2009 7

8 Spezialfall: tische 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 2008/2009 8

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

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

11 Probleme Mögliche Beziehungen zwischen den Mengen realweltlicher Objekte, die durch ein Konzept repräsentiert werden Seien a,b zwei Konzepte für die Mengen A, B A=B (Äquivalenz): a und b sind (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): a und b sind nicht verwandt (häufigster Fall) Dose - Lohnsteuerjahresausgleich Ulf Leser: Informationsintegration, Wintersemester 2008/

12 Semantik: Woher nehmen? elemente 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 2008/

13 Datenkonflikte - Beispiel amazon.de H. Melville $3.98 ID Herman Melville Moby Dick $5.99 bol.de Ulf Leser: Informationsintegration, Wintersemester 2008/

14 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 voraus Ulf Leser: Informationsintegration, Wintersemester 2008/

15 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 2008/

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

17 Verteilung 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 2008/

18 Verteilung Verteilte Datenbanken Autonomie Daten liegen physisch verteilt Absichtsvolle, kontrollierte, a-priori Verteilung Existenz eines konzeptionell homogenen, verteilt realisierten s 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 2008/

19 Einschub: Verteilte Datenbanken mit Oracle Oracle-DBs können auf andere Oracle-DBs 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) Ausfallwahrscheinlichkeit 2-phase-commit Anwendung (z.b.): automatische Replikation Verschiedene Refresh-Optionen Ulf Leser: Informationsintegration, Wintersemester 2008/

20 Verteilte versus parallele Datenbanken Parallele Datenbank Verteilte Datenbank Externes 1 Externes N Konzeptionelles Internes, physisches Externes 1 Lokales konzept. Konzeptionelles Externes N Lokales konzept. Internes Internes Ulf Leser: Informationsintegration, Wintersemester 2008/

21 Einschub: Parallele Datenbanken Auswirkung nur auf der physischen Schicht Es existiert nur ein logisches 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 2008/

22 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 2008/

23 Verteilung 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 2008/

24 Verteilung Multidatenbanken Autonomie Verteilt, autonom, und etwas heterogen Keine technische Heterogenität Keine Datenmodellheterogenität Heterogenität ta können strukturell und semantisch heterogen sein Verteilte Systeme benutzen gleiche Techniken (RDBMS) 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: SQL Ulf Leser: Informationsintegration, Wintersemester 2008/

25 Verteilung 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 2008/

26 Taxonomie nach [SL90] DBMS Kontrollierte, gewollte Verteilung Kein Zugriff durch einheitlichen Mechanismus; Kataloge 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 Einfache Föderation Mehrfache Föderation Ulf Leser: Informationsintegration, Wintersemester 2008/

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

28 Kriterien föderierter Informationssysteme Nach [BKLW99] Weitere (nicht-orthogonale) Kriterien Strukturiertheit 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 2008/

29 Enge oder lose Kopplung Enge Kopplung Festes, integriertes/föderiertes Korrespondenzen regeln die Zusammenhänge Für den Benutzer einheitliche Sicht System muss Änderungen der Quellen kompensieren Lose Kopplung Kein globales, einheitliches Nutzer integrieren selber Nutzer müssen Semantik der Quellen kennen Nur technische und Datenmodellheterogenität ist gelöst Änderungen in Quellen gelangen zum Benutzer Multidatabase query language (MDBQL) Ulf Leser: Informationsintegration, Wintersemester 2008/

30 Verwendetes Datenmodell Kanonisches Datenmodell Das Datenmodell des integrierten Systems Objektorientiert, relational, XML, 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 2008/

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

32 Welche Art von Anfragen werden unterstützt? Strukturierte Anfragen 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 2008/

33 Bottom-up oder Top-down Entwurf Bottom-up Beginnt mit dem Bedarf nach der Integration einer festen Menge von genau bestimmten Quellen Globales wird durch integration 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 s 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 2008/

34 Bottom-up Entwicklung Ulf Leser: Informationsintegration, Wintersemester 2008/

35 Top-down Entwicklung Ulf Leser: Informationsintegration, Wintersemester 2008/

36 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 Ulf Leser: Informationsintegration, Wintersemester 2008/

37 Ü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 2008/

38 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, Externes 1 Externes N Konzeptionelles Internes, physisches Ulf Leser: Informationsintegration, Wintersemester 2008/

39 3-Schichten Architektur Anwendungen Externes 1 Externes N DBMS Konzeptionelles Internes Ulf Leser: Informationsintegration, Wintersemester 2008/

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

41 4-Schichten Architektur Anwendungen Externes 1 Externes N Verteilte DBMS Konzeptionelles Lokale DBMS Lokales konzept. Lokales konzept. Internes Internes Ulf Leser: Informationsintegration, Wintersemester 2008/

42 Import-/Export--Architektur [HM85] = lokales konzeptionelles Nur Teilmenge des lokalen konzeptionellen s wird der Föderation zur Verfügung gestellt Nur Teilmengen der Exportschemata sollen verwendet werden Ulf Leser: Informationsintegration, Wintersemester 2008/

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

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

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

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

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

48 5-Schichten Architektur [SL90] Externes Anwendungsabhängig Föderiertes kann sehr groß sein Vereinfachung im Exportschema Zugangskontrollen Föderiertes Integriert aus den Exportschemata Kennt Datenverteilung Auch globales, unified, Enterprise Externes 1 Exportschema Lokales Externes N Föderiertes Exportschema Komponentenschema Komponentenschema Lokales Ulf Leser: Informationsintegration, Wintersemester 2008/

49 Ü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 2008/

50 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 2008/

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

52 Föderierte Datenbanken Trotz häufiger Verwendung keine klare Definition vorhanden Klassische Definition: 5-Schichten Architektur Lokales, Komponentenschema, Exportschema, föderiertes, externes Integrierte ta verlangen 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 Ulf Leser: Informationsintegration, Wintersemester 2008/

53 Einordnung Distributed Databases Komplexität Ulf Leser: Informationsintegration, Wintersemester 2008/