Überblick - sebastian-huebner.de filead co et 2t o c ot l o d n ad d co et 2t l c ot n be n...
TRANSCRIPT
WS 04/05
Automatische Generierungeines Mediators auf Basis einer deklarativen Spezifikation
Fachbereich Mathematik / InformatikAG Künstliche Intelligenz
KolloquiumJörn Witte09.02.2005
Jörn WitteWS 04/05
2
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
3
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
4
Motivation (I)
Ausgangslage:
� Gewachsene Systeme� Zusammenhängende Daten über mehrere
Datenquellen verteilt
Idee:
� Virtuelle Integration der heterogenen, verteilten und dynamischen Informationsquellen(Materialisierung in einer neuen Datenbank nicht notwendig)
Problematik:
� Strukturelle Heterogenitätskonflikte� Semantische Heterogenitätskonflikte
Jörn WitteWS 04/05
5
Motivation (II)
Lösungsansätze zur virtuellen Integration von Daten:
� Schema Mediation in Peer Data Management Systems [Halevy03]
� MedMaker: A Mediation System Based on Declarative Specifications[Papakonstantinou96]
� Semantische Mediation [Wache03]
...da besondere Beachtung der semantischen Ebene
Jörn WitteWS 04/05
6
Motivation (III)
� Semantische Mediation nach [Wache03]
� MeSA(MeCoTA Specification Assistent)
� MeCoTA(Mediator with Context Transformation and Abstraction)
Auf kleinen Datenquellen getestet, aber:
� Theoretische Lösung - „proof-of-concept“
� Implementiert in Form eines Interpreters
...für große Datenquellen nicht unbedingt geeignet!
Jörn WitteWS 04/05
7
Ziele der Diplomarbeit
� Werkzeug zur Erzeugung eines spezifischen Mediators
� Optimierung des Anfrageprozesses
� Verbesserung der Interaktivität gegenüber MeCoTA
Jörn WitteWS 04/05
8
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
9
Was ist Mediation?
� Mediatoren “combine, integrate, and abstract the information”[Wiederhold92]
� Mediatoren realisieren eine Integrationsabbildung
� Wrapper ermöglichen eine einheitliche Schnittstelle zu den heterogenen Systemen
Informations-system 2
Informations-system 3
Informations-system 1
Mediatorschicht
Mediator
Wrapper Wrapper Wrapper
Anwendung 1 Anwendung 2
Jörn WitteWS 04/05
10
Semantische Mediation nach [Wache03]
1. Akquisition der Vollständigen Beschreibung
� syntaktische und semantische Beschreibung der Datenquellen
2. Identifikation semantisch äquivalenter Konzepte
3. Formulierung der Transformationsregeln
� Definition von Anfragezerlegungsregeln
� Definition von Kontexttransformationsregel (CT-Regel)
Assistenten unterstützen den Spezifikationsprozess
Jörn WitteWS 04/05
11
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
12
Einordnung dieser Arbeit
MeSA
Mediator
Spezifikation
Output
MeSCo
MeCoTASpecification Compiler
Jörn WitteWS 04/05
13
Aufbau des Mediatorsaus Integrationsstrukturen
IS 2
s u b s c r ib e r
bs 62
s u br es
n u mtyp
msin
na
te lep ho n
h lr Su b s c rib e r
d a taMs is dn
loc a tion
nu mb er ing Typ e
ms in
r o amin g Res tr ictio n
te lep ho n eMs is dn
inte ge r 2s trin g
n dcn a tion alD es tina tio nCo d e
n etw o rk Ac ce ss
s u b s c r ib e r
bs 62
s u br es
n u mtyp
msin
na
te lep ho n
h lr Su b s c rib e r
d a taMs is dn
loc a tion
nu mb er ing Typ e
ms in
r o amin g Res tr ictio n
te lep ho n eMs is dn
in teg er 2 str ing
n dcn a tion alD es tina tio nCo d e
n etw o rk Ac ce ss
m o b ile Su b s c r ib e r
tc Ca rme n Sub sc r ibe rId
tcW la nPas sw o rd
tc W lan Us er na me
tc Ms isd n
tcIms i
tc Su bs c ribe rSe rvic eP rofile
h lrS u b s c r ib e r
da taM sis dn
lo c atio n
nu mb er ing Typ e
ms in
r oa min gRe s tric tion
te lep h on eM sis dn
na tion a lDes tin atio nC od e
n etw o rk Ac ce ss
s u b s c rib e r
c ar me nSu b sc rib e rId
d ata Ms isd n
n u mbe r ing Ty p e
im si
r oa min gR es tric tio n
su b sc rib er Se rv ic ePro f ile
n atio n alDe s tina tion Co de
ne tw or k Acc e ss
tele p ho ne Ms isd n
w la nPa ss w or d
w la nU se rn a me
ad d Co nte xt2 L oc atio n Be rlinad dC o nte xt2 Lo c atio nL o nd on
msin L on do n2 ims i ms inBe rlin 2 imsi
subscriber
car menSub scr ibe rId
d ata Msisdn
nu mbe rin gType
ims i
roaming Re strict ion
s ubs cribe rSe rvice Pro file
nation alDe stina tio nCo de
ne tw or kAc ce ss
te le ph one Msisdn
w lan Pas sw o rd
w lan Use rna me
h lrS ub scrib er
dataMsisdn
location
numberingType
msin
roamingRestrict ion
telephoneMsisdn
nationalDestinationCode
netw orkAccess
su bscr ib er
b s6 2
su br es
n um typ
m sin
n a
te le ph on
h lr Sub scrib e r
da taM sisd n
lo cat io n
nu mbe r in gTy pe
m sin
ro am in gRes tr ic tion
te le pho neM sisd n
int ege r2 str ing
n dcnat io nalDes tin ation Cod e
net w o rk Ac ce ss
Wrapper
IS 3 Wrapper
IS 1 Wrapper
h lrS ub scrib er
dataMsisdn
location
numberingType
msin
roamingRestrict ion
telephoneMsisdn
nationalDestinationCode
netw orkAccess
h l rSu b sc ri b e r
dataMsisdn
loc atio n
n umberin gType
ms in
roamingRestric tion
teleph oneMsisdn
n atio nalDestinat ionCode
networkAcces s
h l rSu b sc ri b e r
d ata Msis dn
location
numbe ringType
msin
roa min gRestrict ion
te lephon eMs isdn
nationa lDe stin atio nCo de
n etw ork Ac cess
h lrS u bs c ri b er
d ata Ms isdn
location
numbe ring Type
msin
ro amin gRestrict ion
telephon eMsisdn
na tion alDe stin atio nCode
networkAccess
hlr Su bscri be r
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
nationalDestinationCode
netw orkAccess
su b scrib er
bs62
subres
numtyp
msin
na
telephon
hlr Sub scri be r
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
integer2string
ndcnationalDestinat ionCode
netw orkAccess
Anfrage
Mediator
Jörn WitteWS 04/05
14
Integrationsstruktur
Bestandteile der internen Repräsentation:
� Einheitliche Datenstruktur� Anfrageschnittstelle� Basierend auf dem syntaktischen Teil der Vollständigen Beschreibung [Wache03]
� Erweiterte Integrationsstruktur � Zerlegung einer Anfrage in Subanfragen an andere Informationssysteme� Beseitigung struktureller und semantischer Heterogenitätskonflikte� Grundlage ist ein bewiesener Anfrageplan
Umsetzung in einer Klassenstruktur
hlrSubscribe r
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
nationalDestinationCode
networkAccess
subscribe r
bs62
subres
numtyp
msin
na
telephon
hlrSubscribe r
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
integer2string
ndcnationalDestinationCode
networkAccess
Jörn WitteWS 04/05
15
Anfrageplanung – Warum?
� Der Ansatz von MeCoTA:
� MeCoTAwiederholt deduktives Beweisverfahren für jeden Datensatz
� Blinde Suche über alle Kontexttransformationen für jeden Datensatz
� Eigener Ansatz:
� Anfragepläne als Grundlage für den Aufbau der erweiterten Integrationsstruktur
� Vorteile:
� Einmaliger Planungsprozess � Keine unnötige Suche zur Laufzeit
Jörn WitteWS 04/05
16
msin national destination code location ...
15119800178 151 London ...
15119800140 151 Berlin ...
15119800190 151 London ...
•••
•••
•••
•••
imsi national destination code subscriberServiceProfile ...
2349915119800178 151 regserv001 ...
2629915119800140 151 regserv004 ...
2349915119800190 151 regserv003 ...
•••
•••
•••
•••
tcImsi tcSubscriberServiceProfile ...
2349915119800178 regserv001 ...
2629915119800140 regserv004 ...
2349915119800190 regserv003 ...
•••
•••
•••
- Szenario -
Erstellung einesinitialen Anfrageplans (I)
� Grundlage des initialen Anfrageplans:� Anfragezerlegungsregel
Jörn WitteWS 04/05
17
Erstellung einesinitialen Anfrageplans (II)
subscriber@commonUserProfileKonzept T
Attribut a
Attribut c
Attribut b
hlrBerlin2commonHlrKonzept T
Attr ib u t a
Attr ib u t c
Attr ib u t b
Konzept F
A ttr ib u t 1
A ttrib u t 3
A ttrib u t 2
2subscriber
Konzept F 1
Attribut a
Attribut c
Attribut b
Konzept F 2
Attribut 1
Attribut 3
Attribut 2
Konzept T
Attribut A
Attribut C
Attribut B
Attribut D
Attribut E
hlrLondon2commonHlrKonzept T
A ttr ib u t a
A ttr ib u t c
A ttr ib u t b
Konzept F
A ttr ib u t 1
A ttr ibu t 3
A ttr ibu t 2
� Zerlegung einer Anfrage in Subanfragen [Xiaolei96]
� Auflösung struktureller Integrationskonflikte
� Grundgerüst für den bewiesenen Anfrageplan
Jörn WitteWS 04/05
18
Semantische Auswertung einer Anfragezerlegungsregel (I)
Ziel:
� Semantische Heterogenitätskonflikte aufdecken
� Sequenzen von Kontexttransformationen zur Konfliktbeseitigung für einzelne Konzeptkorrespondenzen ermitteln
Problematik:
� Verschiedene Lösungswege in Abhängigkeit von den Daten
Jörn WitteWS 04/05
19
- Szenario -
Semantische Auswertung einer Anfragezerlegungsregel (I)
msin national destination code location ...
15119800178 151 London ...
15119800140 151 Berlin ...
15119800190 151 London ...
•••
•••
•••
•••
imsi national destination code subscriberServiceProfile ...
2349915119800178 151 regserv001 ...
2629915119800140 151 regserv004 ...
2349915119800190 151 regserv003 ...
•••
•••
•••
•••
tcImsi tcSubscriberServiceProfile ...
2349915119800178 regserv001 ...
2629915119800140 regserv004 ...
2349915119800190 regserv003 ...
•••
•••
•••
National Destination CodeService Profile [Profile-of -Service]range = global
IMSI (Identifier-of-Subscriber)
National Destination Code Service Profile [Profile-of -Service]
range = global
IMSI (Identifier-of-Subscriber)
range = local
MSIN (Identifier-of-Subscriber)
location = london
location
Jörn WitteWS 04/05
20
- Szenario -
Semantische Auswertung einer Anfragezerlegungsregel (I)
msin national destination code location ...
15119800178 151 London ...
15119800140 151 Berlin ...
15119800190 151 London ...
•••
•••
•••
•••
imsi national destination code subscriberServiceProfile ...
2349915119800178 151 regserv001 ...
2629915119800140 151 regserv004 ...
2349915119800190 151 regserv003 ...
•••
•••
•••
•••
tcImsi tcSubscriberServiceProfile ...
2349915119800178 regserv001 ...
2629915119800140 regserv004 ...
2349915119800190 regserv003 ...
•••
•••
•••
National Destination CodeService Profile [Profile-of -Service]range = global
IMSI (Identifier-of-Subscriber)
National Destination Code Service Profile [Profile-of -Service]
range = global
IMSI (Identifier-of-Subscriber)
range = local
MSIN (Identifier-of-Subscriber)
location = berlin
location
Jörn WitteWS 04/05
21
Semantische Auswertung einer Anfragezerlegungsregel (II)
� Formalisierung in Hornlogik� Logische Beweisverfahren auf Schema-Ebene
� Verwendung der SLD-Resolution in Verbindung mit klassischer Unifikation [Robinson79]
� Im Gegensatz dazu führt MeCoTABeweisverfahren auf Instanz-Ebene durch� Verwendung der CT-Resolution und des CT-Kalküls [Wache03]
Instanz-Ebene Schema-Ebene
mobileSubscriber
tcCarmenSubscriberId
tcWlanPassw ord
tcWlanUsername
tcMsisdn
tcImsi
midSubDB
tc Subsc riberS erviceProfi le
hlrSubscriber
dataMsisdn
location
number ingType
msin
roamingRestriction
telephoneMsisdn
nationalDestinationCode
netw orkAccess
commonUserProf ile
subscriber
carmenSubscr iber Id
dataMsisdn
numberingType
imsi
roamingRestr iction
subscr iberServiceProfile
nationalDestinationCode
netw orkAccess
commonUserProfile
telephoneMsisdn
w lanPassw ord
w lanUsername
addContext2Locati onBerlinad dContext2LocationLondon
msinLondon2imsi msinBerlin2imsi
...mobileSubscriber
15119800343
15119800000
2629915119800000
midSubDB
ssg2-fu-5-1-1
hlrSubscriber
16119801211
BERLIN
SINGLE
15119800000
ONAOFPLM
151192320000
151
GSMGPRS
commonUserProfile
subscriber
15119800343
16119801211
SINGLE
2629915119800000
ONAOFPLM
ssg 2- fu-5-1-1
151
GSMGPRS
commonUserProfile
1511923200000
ad dContext2LocationBerli n
msinBer lin2imsi
mobileSubscriber
15119800000
test
test
15119800000
2629915119800000
midSubDB
ssg2-fu-5-1-1
hlrSubscriber
16119801211
BERLIN
SINGLE
15119800000
ONAOFPLM
151192320000
151
GSMGPRS
commonUserProfile
subscriber
15119800000
16119801211
SINGLE
2629915119800000
ONAOFPLM
ssg 2- fu-5-1-1
151
GSMGPRS
commonUserProfile
1511923200000
test
test
addContext2LocationBerli n
msinBerlin2imsi
mobileSubscriber
15119800000
test
mike
15119800000
2349915119800000
midSubDB
ssg2-fu-5-1-1
hlrSubscriber
16119801211
LONDON
SINGLE
15119800000
ONAOFPLM
151192320000
151
GSMGPRS
commonUserProfile
subscriber
15119800000
16119801211
SINGLE
2349915119800000
ONAOFPLM
ssg 2-f u-5-1-1
151
GSMGPRS
commonUserProfile
1511923200000
test
mike
addCon text2Lo cation London
msinLondon2imsi
Jörn WitteWS 04/05
22
Semantische Auswertung einer Anfragezerlegungsregel (III)
Idee:
� Zielkonzepte aus den korrespondierenden Quellkonzepten einer Anfragezerlegungsregel herleiten
� Iteratives Beweisverfahren auf Basis der SLD-Resolution� dabei spezielle CT-Regeln sukzessive aus der Wissensbasis entfernen
� erfolgreiche Ableitungsketten als Auswertungsgrundlage verwenden� Abhängigkeiten von Daten sowie die Operationen der CT-Regeln werden erst
zur Laufzeit berücksichtigt
Anfragezerlegungsregel gilt als bewiesen, wenn alle Konzeptkorrespondenzen erfolgreich abgeleitet werden konnten
Jörn WitteWS 04/05
23
Erstellung eines bewiesenen Anfrageplans
� Grundlage:
� Initialer Anfrageplan � Ergebnisse der semantischen Auswertungen der
Anfragezerlegungsregeln
� Beinhaltet das Wissen zur Auflösung struktureller und semantischer Heterogenitätskonflikte
� Dient als Basis für die erweiterte Integrationsstruktur
Jörn WitteWS 04/05
24
Integrationsstrategie
� Pipelining
� Parallelisierung der einzelnen Teilschritte
� Daten werden von einem Prozess zum nächsten weitergereicht
� Keine Vorteile bei blockierenden Operationen
Vorteile:
� Hohe Interaktivität
� Keine Beschränkung der zu verarbeitenden Datenmenge
Jörn WitteWS 04/05
25
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
26
Zusammenfassung und Bewertung (I)
� Generierter Mediator besteht aus einer Menge von Integrationsstrukturen in Form von Java-Klassen
� Anfragepläne dienen dabei als Modellierungsgrundlage für den Mediator
� Anfrageplangenerierung in drei Schritten:
1. Initialer Anfrageplan
2. Semantische Auswertung der Anfragezerlegungsregeln
3. Bewiesener Anfrageplan
� Pipelining als Integrationsstrategie
Jörn WitteWS 04/05
27
Zusammenfassung und Bewertung (II)
� Domänenspezifischer, autarker Mediator
� Integrationsstruktur
� Uniforme Anfrageschnittstelle
� Abbildung des integrativen Wissens
� Unterstützung einer Konkretisierung der semantischen Beschreibung in
Abhängigkeit von den Daten
� Interaktivität gegenüber MeCoTAwurde verbessert
Jörn WitteWS 04/05
28
Zusammenfassung und Bewertung (III)
Ergebnisse:
� geringe Startzeit, d.h.
frühe Bereitstellung
integrierter Ergebnisse
im Vergleich zu MeCoTA
� Ausgeglichene Pipeline durch konstante Zufuhr von Informationen
� Ausgeglichene Pipeline
ist vorteilhaft für die
Gesamtzeit
...
MeSCoCriteria crit = new MeSCoCriteria();
crit.add(SubscriberPeer.NATIONALDESTINATIONCODE,"151");
SourceThread cup = new CommonuserprofileSubscriber
CommonuserprofileSubscriberSourceThread();
OutputTable t = new OutputTable(cup);
t.startQuery(crit);
…
0
500
1000
1500
2000
2500
3000
0 10000 20000 30000 40000 50000 60000
ms
Dat
ensä
tze
Jörn WitteWS 04/05
29
Überblick
� Einleitung
� Grundlagen
� Eigene Arbeit
� Aufbau des Mediators
� Generierung von Anfrageplänen
� Festlegung einer Integrationsstrategie
� Zusammenfassung und Bewertung
� Ausblick
Jörn WitteWS 04/05
30
Ausblick
� Umkehrung der Kontexttransformation
� Ermöglicht die Propagierung von Bedingungen an die Subanfragen
� Optimierung der Anfragepläne
� z.B. Veränderung der Join-Reihenfolge, interessante Sortierungen
� Verfahren zur Steigerung der Informationsqualität
� z.B. Duplikaterkennung
Jörn WitteWS 04/05
31
Anhang
Jörn WitteWS 04/05
32
subscriber
bs62
subres
numtyp
msin
na
telephon
hlrSubscriber
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
integer2string
ndcnationalDestinationCode
netw orkAccess
hlrLondoncommonUserProfile
subscriber
bs62
subres
numtyp
msin
na
telephon
hlrSubscriber
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
integer2string
ndcnationalDestinationCode
netw orkAccess
hlrBerlincommonUserProfile
mobileSubscriber
tcCarmenSubscriberId
tcWlanPassw ord
tcWlanUsername
tcMsisdn
tcImsi
midSubDB
tcSubscriberServiceProfi le
hlrSubscriber
dataMsisdn
location
numberingType
msin
roamingRestriction
telephoneMsisdn
nationalDestinationCode
netw orkAccess
commonUserProfile
subscriber
carmenSubscriberId
dataMsisdn
numberingType
imsi
roamingRestriction
subscriberServiceProfile
nationalDestinationCode
netw orkAccess
commonUserProfile
telephoneMsisdn
w lanPassw ord
w lanUsername
addContext2LocationBerlinaddContext2LocationLondon
2subscriber
hlrBerlin2commonHlr
hlrLondon2commonHlr
msinLondon2imsi msinBerlin2imsi
- Beispiel -
Grafische Darstellung eines bewiesenen Anfrageplans
Jörn WitteWS 04/05
33
concept( VAR_VAL_MSIN, msin , string , commonUserProfile )
term( VAR_VAL_MSIN, MSIN [Identifier of Subscriber] )
context( VAR_VAL_MSIN, range , local )
query(imsi) ← concept( VAR_VAL_IMSI, imsi, string , commonUserProfile)
∧ term( VAR_VAL_IMSI, IMSI [Identifier of Subscriber] )
∧ context( VAR_VAL_IMSI, range , global )
- Beispiel -
Überführung einer Anfragezerlegungsregel
’2subscriber’&&
template(’subscriber’,VAR_LAB_SUB,complex,VAR_VAL_S UB)::[
’imsi’ -->> template(’imsi’,
VAR_LAB_IMSI,
string,
VAR_VAL_IMSI)::[]@’commonUserProfile’,
...
]@’commonUserProfile’
<<--
[template(’hlrSubscriber’,VAR_LAB_SUB,complex,VAR_V AL_SUB)::[
’msin’ --*> template(’msin’,
VAR_LAB_MSIN,
string,
VAR_VAL_MSIN)::[]@’commonUserProfile’,
...
]@’hlrBerlin’].
Anzahl der einzelnen Beweise bzw. unterschiedlicher Wissensbasen ist abhängig � von der Anzahl der Attributkonzepte
� sowie der Kardinalität der Anfragezerlegungsregel
Jörn WitteWS 04/05
34
’addContext2LocationLondon’&&
template( VAR_NAME,
’Location Identifier’ ::[ ’location’ **>> ’london’ ],
string ,
’London’ )::[]@ ’commonUserProfile’
<<**
[??template( VAR_NAME,
’Location Identifier’ ::[],
string ,
’London’ )::[]@ ’commonUserProfile’ ].
context( VAR_NAME@addContext2LocationLondon, location , london )←concept( VAR_NAME@addContext2LocationLondon, VAR_NAME, string , commonUserProfile )
∧ term( VAR_NAME@addContext2LocationLondon, Location Identifier )
Abhängigkeiten von Daten sowie die Operationen der CT-Regeln
werden erst zur Laufzeit berücksichtigt
- Beispiel -
Überführung einer Kontexttransformationsregel