Architekturen zur Informationsintegration

Informationsintegration
Architekturen
Ulf Leser
Wissensmanagement in der
Bioinformatik
Ü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
Ausprägung 2
Anfrage
Heterogenität
zwischen
globaler
Schicht und
Datenquellen
Integriertes Informationssystem
Quelle
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
3
Technische Heterogenität
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
4
Mächtige globale Anfragesprache
SQL
SELECT
FROM
WHERE
AND
*
Books
Author = „Defoe“
PubYear = 1979
HTML
Form
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
5
Kompensation möglich
SELECT
FROM
WHERE
AND
*
Books
Author = „Defoe“
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
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, 12.9.2006, 9/12/2006, …)
• Überwindung in der Regel nicht problematisch
• Umrechnung, Übersetzungstabellen, …
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
7
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
Spezialfall: Schematische Heterogenität
maenner( Id, vorname, nachname)
frauen( Id, vorname, nachname)
Relation vs. Wert
Relation vs. Attribut
person( Id, vorname, nachname,
maennlich?, weiblich?)
person( Id, vorname, nachname,
geschlecht)
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Attribut vs. Wert
9
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/2007
10
Semantik von was?
Name
Extension
Realweltliche Objekte
Intension
repräsentiert
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Konzept
11
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/2007
12
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/2007
13
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/2007
14
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/2007
15
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/2007
16
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/2007
17
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/2007
18
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/2007
19
Klassifikation
Verteilte,
homogene
DBS
[ÖV91]
Verteilung
Verteilte,
heterogene
DBS
Logisch
integrierte und
homogene DBS
Verteilte,
föderierte
DBS
Verteilte,
heterogene
föderierte DBS
Autonomie
Heterogenität
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
20
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/2007
21
Verteilung
2. Verteilte Datenbanken
Autonomie
• Daten liegen physisch verteilt
•
•
•
Heterogenität
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
Verteilungstransparenz durch Sichten möglich, aber nicht durch System
erzeugt
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
22
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 tab1@link_name;
• 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/2007
23
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/2007
24
Vertikale Partitionierung
id
id
price
amount
code
form
1
50
4
011010 CASH
2
60
2
110101 VISA
3
20
1
001101 VISA
price
amount
id
code
...
form
1
50
4
1
011010 CASH
2
60
2
2
110101 VISA
3
20
1
3
001101 VISA
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
...
25
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/2007
26
Horizontale Partitionierung
id
price
amount
code
form
1
50
4
011010 CASH
2
60
2
110101 VISA
3
20
1
001101 VISA
4
30
4
110101 CASH
...
1
50
4
011010 CASH
1
50
4
011010 CASH
2
60
2
110101 VISA
4
30
4
110101 CASH
3
20
1
001101 VISA
2
60
2
110101 VISA
4
30
4
110101 CASH
3
20
1
001101 VISA
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
27
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/2007
28
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/2007
29
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/2007
30
Vergleich
Parallele
Datenbank
Externes
Schema 1
...
Verteilte
Datenbank
Externes
Schema N
Externes
Schema 1
...
Externes
Schema N
Konzeptionelles Schema
Konzep. Schema
Konzep. Schema
Internes, physisches Schema
Internes Schema
Internes Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
31
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/2007
32
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/2007
33
Verteilung
3. Verteilte & heterogene DB
Autonomie
• Daten liegen physisch verteilt vor
• Daten sind heterogen
Heterogenität
• Z.B. aufgrund der Historie der Entstehung
• Keine Autonomie
• Heterogenität sollte also nicht schlimmer werden
• Typischer Zwischenzustand
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
34
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/2007
35
Verteilung
5. Multidatenbanken
Autonomie
• Verteilt, autonom, und etwas heterogen
•
•
•
•
Heterogenität
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
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
36
Verteilung
6. Verteilt, heterogen, autonom
Autonomie
Heterogenität
• 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
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
37
Taxonomie nach [SL90]
DBMS
Kontrollierte, gewollte Verteilung
Kein Zugriff durch einheitlichen
Mechanismus
Nutzer muss selbst integrieren
(durch Views etc.)
Nur ein föderiertes Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
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
38
Überblick
• Klassifikation
• Verteilter, autonomer, heterogener Systeme
• Weitere Klassifikationskriterien
• Schichtenaufbau integrierter Systeme
• 3-5 Schichten
• Prominente Architekturen
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
39
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/2007
40
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/2007
41
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/2007
42
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/2007
43
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/2007
44
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/2007
45
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/2007
46
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/2007
47
Bottom-up Entwicklung
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
48
Top-down Entwicklung
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
49
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/2007
50
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/2007
51
Ü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/2007
52
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/2007
53
3-Schichten Architektur
Anwendungen
Externes ... Externes
Schema 1
Schema N
Konzeptionelles Schema
DBMS
Internes Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
54
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
...
Externes
Schema N
Konzeptionelles
Schema
Lokales konzept. ...
Schema
Internes
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
...
Lokales konzept.
Schema
Internes
Schema
55
4-Schichten Architektur
Anwendungen
Externes
Schema 1
Externes
Schema N
Konzeptionelles
Schema
Vert. DBMS
Lokale DBMS
...
Lokales konzept. ...
Schema
Internes
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
...
Lokales konzept.
Schema
Internes
Schema
56
Import-/Export-Schema-Architektur
= lokales
konzeptionelles
Schema
Idee: Nur Teilmenge des
lokalen konzeptionellen
Schemas wird der Föderation
zur Verfügung gestellt.
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
[HM85]
Idee: Nur Teilmengen
der Exportschemas
sollen verwendet
werden.
57
Multidatenbankarchitektur
• Siehe [LMR90]
• Voraussetzung
• Nutzer kennen die
jeweiligen Schemas
• Multidatenbanksprache
• Lose Kopplung
Externes
Schema 1
...
Export-Schema
Export-Schema
Lokales konzept. ...
Schema
Internes
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Externes
Schema N
...
Lokales konzept.
Schema
Internes
Schema
58
4-Schichten Architektur
Anwendungen
Anwendungen
müssen selbst
integrieren
Lokale DBMS
Externes
Schema 1
...
Export-Schema
Export-Schema
Lokales konzept. ...
Schema
Internes
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Externes
Schema N
...
Lokales konzept.
Schema
Internes
Schema
59
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
Externes
Schema N
...
Föderiertes Schema
Exportschema
Exportschema
Komponenten- ...
schema
Komponentenschema
Lokales
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
...
Lokales
Schema
60
5-Schichten Architektur [SL90]
Anwendungen
Föderiertes DBMS
Externes
Schema 1
...
Föderiertes Schema
Exportschema
Lokale DBMS
Externes
Schema N
Komponentenschema
Lokales
internes
Schema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Exportschema
...
...
Komponentenschema
Lokales
internes
Schema
61
5-Schichten Architektur [SL90]
• Exportschemas
•
•
•
Externes
Schema 1
Teilmenge des
Komponentenschemas
Zugangsberechtigungen
Unnötig, wenn komplettes Schema
exportiert wird
...
Föderiertes Schema
• Komponentenschemas
•
•
•
•
Kanonisches Datenmodell
Fügt fehlende Semantik hinzu
Übergang durch Mappings
Unnötig, wenn lokales =
kanonisches Datenmodell
Exportschema
Exportschema
Komponenten- ...
schema
Komponentenschema
• Lokale Schemas
•
Externes
Schema N
Konzeptionell
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Lokales
Schema
...
Lokales
Schema
62
5-Schichten Architektur [SL90]
• Externes Schema
Externes
Schema 1
• Föderiertes Schema kann sehr
groß sein → Vereinfachung im
Exportschema
• Schema Evolution leichter
• Zugangskontrollen
...
Föderiertes Schema
• Föderiertes Schema
• Integriert aus den Exportschemas
• Kennt Datenverteilung
• Andere Namen:
• Import, global, unified,
Enterprise Schema
Externes
Schema N
Exportschema
Exportschema
Komponenten- ...
schema
Komponentenschema
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
Lokales
Schema
...
Lokales
Schema
63
Ü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/2007
64
Data Warehouses
Metadaten
Quelle 1
RDBMS
Quelle 2
IMS
Staging Area
Staging Area
Mart 2
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/2007
65
Mediator-Wrapper Architektur
• Virtuelle Integration
• Unabhängig von
Strukturiertheit
Anwendung 1
• Quellspezifische Wrapper
• Datenmodelltransformation
• Übersetzung von Anfragen
• Mediatoren als
Mehrwertdienste
• Datenintegration
• Verdichtung
• …
Anwendung 2
Mediator
Wrapper 1
Wrapper 2
Wrapper 3
Quelle 1
Quelle 2
Quelle 3
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
66
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/2007
67
Einordnung
Distributed Databases
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
C
p
om
ty
i
x
le
68
Literatur
• Wichtige Literatur
•
•
•
[ÖV99] Principles of Distributed Database Systems. M. Tamer Özsu, Patrick
Valduriez, Prentice Hall, 1999.
[SL90] Amit P. Sheth and James A. Larson, Federated Database Systems
for Managing Distributed, Heterogeneous, and Autonomous Databases,
ACM Computing Surveys, Vol. 22(3), pp183-236, 1990.
[Con97] Stefan Conrad, Föderierte Datenbanksysteme. Springer,
Heidelberg 1997.
• Weitere Literatur
•
•
[LMR90] W. Litwin, L. Mark, N. Roussoupoulos, Interoperability of Multiple
Autonomous Databases, ACM Computing Surveys, Vol. 22(3), pp267-293,
1990.
[HM85] Dennis Heimbigner, Dennis McLeod: A Federated Architecture for
Information Management. ACM Trans. Inf. Syst. 3(3): 253-278 (1985)
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
69