D I P L O M A R B E I T AGENTELLIGENCE. Anwendungsmöglichkeiten verteilter Informationssysteme auf ein System zur Flugreiseinformation.

Transkript

1 D I P L O M A R B E I T AGENTELLIGENCE Anwendungsmöglichkeiten verteilter Informationssysteme auf ein System zur Flugreiseinformation Von Dennis Christiani (LQJHUHLFKWDP-XQLEHLP,QVWLWXWI U$QJHZDQGWH,QIRUPDWLN XQG)RUPDOH%HVFKUHLEXQJVYHUIDKUHQ DQGHU8QLYHUVLWlW.DUOVUXKH 5HIHUHQW3URI'U5XGL6WXGHU %HWUHXHU'U6WHIIHQ6WDDE +HLPDWDQVFKULIW 6WXGLHQDQVFKULIW 5 KHU+ WWHD *HUZLJVWU (VFKZHLOHU.DUOVUXKH

2 Mein Dank gilt den zahlreichen Reisebüroagenten, die mich mit ihrem touristischen Fachwissen beraten haben; des Weiteren Herr Uli Sambeth von der proquest GmbH, der mir diese Arbeit ermöglicht und Herrn Dr. Steffen Staab, der diese Arbeit betreut hat. Insbesondere danke ich Herrn Holger Haag für den Rat und die unermüdliche Unterstützung in allen Bereichen, sowie allen die diese Arbeit Korrektur gelesen haben. 2

3 (,1/(,781* 1.1 MOTIVATION UND ZIEL DIESER ARBEIT AUFBAU DER DIPLOMARBEIT (25,(9(57(,/7(5,1)250$7,2166<67(0( 2.1 ASPEKTE DER INTEGRATION VERSCHIEDENER INFORMATIONSQUELLEN... 7 $XWRQRPLH +HWHURJHQLWlW 9HUWHLOXQJ (YROXWLRQVIlKLJNHLW 2.2 KLASSIFIKATIONSKRITERIEN VERTEILTER INFORMATIONSSYSTEME DWHULDOLVLHUHQGHYVYLUWXHOOH6\VWHPH (QJHYVORVH.RSSOXQJGHU.RPSRQHQWHQGDWHQEDQNV\VWHPH 6WUXNWXULHUWHVHPLVWUXNWXULHUWHXQGXQVWUXNWXULHUWH.RPSRQHQWHQGDWHQ %RWWRPXSYV7RSGRZQ 7UDQVSDUHQ] $EIUDJHDUWHQ =XJULIIVUHFKWH =XJULIIVPHWKRGHQ 2.3 VERSCHIEDENE ANSÄTZE DER DATENINTEGRATION QLYHUVHOOH'%06 'DWD:DUHKRXVH 0HWDVXFKPDVFKLQHQ 0XOWLGDWHQEDQNV\VWHPH ) GHULHUWH'DWHQEDQNV\VWHPH)'%6 0HGLDWRUHQ Metadaten Anfragemediation Schnittstelle Applikation zu Mediationsschicht Aufbau der Mediationsschicht Schnittstelle Mediationsschicht zu Datenquelle KLASSIFIKATION UND DISKUSSION DER DATENINTEGRATIONSANSÄTZE $*(17(//,*(1&( 3.1 INFORMATIONSQUELLEN )OXJSUHLVLQIRUPDWLRQVV\VWHPH Airline Reservierungssysteme (GDS) Published Fares CRS Private Fares Nettotarifdatenbanken XML-basierte Preisinformationen Steuern und Flughafengebühren =XVDW]LQIRUPDWLRQHQI U.XQGHQXQG$JHQWHQ Zielgebietsinformationen Informationen aus vergangenen Buchungen Konkurrenzpreise Yield Management MODELLIERUNG EINES VERTEILTEN INFORMATIONSSYSTEMS ZUR FLUGBUCHUNG.. 41 $XWRQRPLH+HWHURJHQLWlW9HUWHLOWKHLWXQG(YROXWLRQGHU4XHOOHQ 3

4 Preisinformationsquellen Zusatzinformationsquellen Interne Zusatzinformationsquellen $QIRUGHUXQJHQDQGDV,QIRUPDWLRQVV\VWHP 0RGHOOLHUXQJHLQHV,QIRUPDWLRQVV\VWHPV GlobalRequest QueryDispatcher Request Objekte Backofficedata Source Meta Daten Cache Wrapper Info Objekte ResultIntegrator Klasse FareCalculation Klasse Integriertes Ergebnis... 76,03/(0(17,(581* 4.1 STAND DER SOFTWARE PRIORISIERUNG DER TASKS BEREITS UMGESETZTE TASKS GEPLANTES WEITERES VORGEHEN &+/866%(75$&+781* $1+b1*( 6.1 LITERATURNACHWEISE ABBILDUNGS- UND TABELLENVERZEICHNIS

5 (LQOHLWXQJ 1.1 Motivation und Ziel dieser Arbeit Auch, oder vielleicht gerade die Reiseindustrie gehört zu den Branchen, in die in den letzten Jahren der E-Commerce Einzug gehalten hat. Reiseportale und Internet Booking Engines (IBEs) verzeichnen ein kontinuierliches Wachstum der Buchungszahlen. Immer mehr Kunden nutzen das Internet, um sich z.b. über Flugpreise verschiedener Anbieter oder auch das Zielgebiet zu informieren. Das ständig wachsende Informationsangebot des WWW bietet immer mehr Möglichkeiten, dieses Informationsbedürfnis umfassend zu stillen. Dieser fortlaufende Wandel erfordert eine entsprechende Anpassung und Erweiterung der IT- Produkte in der Reiseindustrie. Sowohl im Bereich des E-Commerce als auch der IT- Lösungen für den Einsatz in Reisebüros müssen Informations- oder Verkaufssysteme den sich ständig erweiternden Informationsquellen Rechnung tragen. Eine Studie von Dr. Fried & Partner [Fried 2001] kam zu dem Ergebnis, dass durch Einsatz automatisierender Software bis zu 60% der Prozesszeit einer Flugbuchung im Vergleich zu einer herkömmlichen Buchung im Reisebüro eingespart werden kann. Diese Reduzierung wird hauptsächlich dadurch erreicht, dass zeitraubende Kommunikationsprozeduren entfallen, bei denen der Reisebüroagent als Vermittler zwischen Preisauskunfts- bzw. Flugreservierungssystem und Kunde agiert. Der Kunde eines Reisebüros möchte sich beispielsweise über eine Flugreise nach Neuseeland informieren. Um die Fragen des Kunden nach Flugpreisen, Einreisebestimmungen und zu erwartendem Klima usw. zu beantworten, bedient sich der Reisebüroagent einer Vielzahl von Informationsquellen. Insbesondere bei den Flugpreisen stehen in der Regel mehrere Tarifquellen zur Verfügung, die, abhängig vom Ziel der Reise, unterschiedlich relevant sind. Eine dieser Informationsquellen ist dabei auch der Agent selbst, genauer gesagt: die Erfahrung und das Wissen, das er im Laufe der Zeit angesammelt hat. Dazu gehört z.b. Wissen über die eben angesprochene Relevanz der jeweiligen Tarifquelle oder eine gewisse Kenntnis des Tarifgefüges und Flugplanes der Airlines. Dieses Wissen erlaubt ihm, abhängig von den Bedürfnissen und der Flexibilität des Kunden, den günstigsten Tarif herauszufinden oder auch eine Airline zu wählen, die aus Sicht des Reisebüros den größten Profit bringt. Alle bisher angesprochenen Informationen liegen heutzutage in elektronischer Form vor, sei es im Internet, in speziellen Flugpreisinformationssystemen, in lokalen Flugtarif- und Kalkulationsdatenbanken oder Backofficedatenbanken, die in Form der Buchungsdaten das das Wissen und die Erfahrung des Reisebüroagenten widerspiegeln. Dies bietet das Potenzial, IT-Lösungen zu entwickeln, die all diese Informationen aus verteilten Informationsquellen integrieren. Ein solches integriertes Informationssystem kann dem Reisebüroagenten dienen, indem z.b. die Prozesszeit für die Informationsrecherche bei einer persönlichen Beratung des Kunden reduziert wird. Es kann dem Reisebürounternehmen nutzen, indem es weniger Aufwand in die Ausbildung der Agenten investieren muss, da der Agent nur noch auf einem System angelernt wird und die Erfahrung und das Wissen aller Agenten schon zu einem gewissen Anteil im System integriert sind. Es kann zu guter Letzt vielleicht sogar soweit gehen, den Flugbuchungsprozess, wie er in einem Reisebüro stattfindet, durch ein E-Commercesystem weitgehend abzubilden und somit einen virtuellen Reisebüroagenten im Internet zu kreieren. Ziel der vorliegenden Diplomarbeit ist es zu untersuchen, inwieweit der Prozess einer Flugreiseauskunft, so wie sie im Reisebüro stattfindet, durch die Integration verteilter Informationsquellen automatisiert und optimiert werden kann. 5

6 1.2 Aufbau der Diplomarbeit Diese Arbeit ist in drei Teile gegliedert. Im ersten Teil werden Motivation, Ziel und der Aufbau der Arbeit vorgestellt. Im zweiten Teil werden zunächst die Probleme erläutert, die im Zusammenhang mit der Integration verteilter heterogenen Informationssysteme auftreten können. Anschließend werden Kriterien vorgestellt, nach denen sich die verschiedenen existierenden Ansätze zur Integration verteilter Informationssysteme klassifizieren lassen. Es folgt eine Darstellung der derzeit bekannten Integrationsansätze, eine den zuvor genannten Kriterien entsprechende Einordnung, sowie eine Diskussion ihrer Vor- und Nachteile. Der dritte Teil der Arbeit stellt die Domäne der Flugpreisinformationssysteme vor und erläutert die technischen Aspekte wie z.b. Reservierungssysteme und deren Anbindung. Darüber hinaus werden eine Reihe für die Flugreise relevante Informationsquellen aufgezeigt, die vor dem Hintergrund der Automatisierung und Optimierung des Flugauskunftssprozesses von Interesse sind. Es wird ein Modell entwickelt, das die Integration einer Auswahl der zuvor präsentierten Informationsquellen ermöglicht. Dabei werden die in Teil 2 erarbeiteten Erkenntnisse und Klassifikationen einbezogen. Anhand einer Fallstudie wird das Modell parallel zu seiner Entwicklung näher erläutert und verifiziert. Abschließend werden in einem Abschnitt zur Implementierung der Stand der airquest Software zu Beginn der Arbeit erläutert, sowie Maßnahmen vorgestellt, die teilweise schon während der Arbeit umgesetzt wurden, bzw. als Resultat der Arbeit in naher Zukunft umgesetzt werden sollen. Im vierten Teil werden dann die Kernaussagen der Arbeit zusammengefasst und in einem Ausblick Punkte bzw. offene Fragen angesprochen, auf die in dieser Arbeit nicht näher eingegangen wurde, die aber für eine weitere Entwicklung dieses Themas von Interesse sein könnten. 7KHRULHYHUWHLOWHU,QIRUPDWLRQVV\VWHPH Durch die sich ständig weiterentwickelnde weltweite Vernetzung werden täglich mehr Informationsquellen online zugänglich und können in Informationssysteme eingebunden werden. Aufgrund dieser Entwicklung ist in den letzen Jahren der Umfang moderner Informationssysteme gewachsen. Zum Einen durch immer größere und detailliertere Datenbanken, zum Anderen durch zunehmende Kombination von Informationen aus verschiedenen voneinander unabhängigen Quellen. Moderne Informationssysteme sind somit heutzutage abhängig von einer Vielzahl heterogener Quellen. Diese Quellen sind in der Regel sowohl voneinander unabhängig als auch von der Applikation, die sie abfragen. Sie werden autonom entwickelt und gewartet. So werden z.b. Daten, die in Applikationen wie Lagerhaltungssystemen, Produktionssystemen oder Lohnabrechnungssystemen verarbeitet werden, auch für übergeordnete Anwendungen wie z.b. entscheidungsunterstützende Systeme oder Planungssysteme herangezogen. Die Entwicklung dieser übergeordneten Systeme geschieht meist relativ unabhängig von den zu integrierenden Komponenten. Die Vielzahl an Quellen in einem System zu vereinen gehört zu den Herausforderungen bei der Planung und Entwicklung solcher Systeme. Viele aus funktionaler Sicht des Systems irrelevanten aber dennoch wichtige Details müssen beachtet werden. Während das Ansteuern unterschiedlicher Plattformen und Betriebssysteme heutzutage weitgehend gelöst ist, führen Differenzen in Schnittstellen, Datenbeschreibungen, Abstraktionslevels und der präzisen Bedeutung benutzter Termini zu Problemen beim automatisierten Zugriff auf verteilte Informationen. [vergl.wiederhold 95] 6

7 Im Folgenden sollen zunächst die Aspekte verteilter Informationssysteme und im Anschluss eine Übersicht über die zur Zeit bekanntesten Ansätze sowie ihre Vor- und Nachteile vorgestellt werden. 2.1 Aspekte der Integration verschiedener Informationsquellen Verteilte Informationssysteme bieten dem Benutzer Zugang zu Informationen, basierend auf Daten verschiedener Informationsquellen. Eine weitergehende Klassifizierung ist möglich, indem man Informationssysteme unter den Aspekten Autonomie, Heterogenität, Verteilung der Informationsquellen sowie ihrer Evolutionsfähigkeit betrachtet. Zunächst werden daher die oben genannten Dimensionen näher vorgestellt, bevor anschließend auf die verschiedenen Ansätze verteilter Informationssysteme eingegangen wird. $XWRQRPLH Autonomie im Kontext von verteilten Informationssysteme meint die Autonomie der Informationsquellen. Grundsätzlich gilt, dass die Komponentensysteme unabhängig voneinander betrieben und weiterentwickelt werden und die Teilnahme eines Komponentensystems an einem verteilten Informationssystem nicht die Arbeit existierender lokaler Anwendungen beeinträchtigen darf. Hierbei lassen sich drei Arten der Autonomie unterscheiden [vergl. Saake 1999 u. Convey et al. 2001] (QWZXUIVDXWRQRPLH Entwurfsautonomie bedeutet, dass die lokalen Datenbankschemata bzw. Repräsentationsformen für die lokalen Anwendungen entworfen wurden und deßhalb beibehalten werden müssen. Jede Quelle ist unabhängig in Bezug auf ihr Datenmodell, der Bezeichnung von Daten, ihrer semantischen Bedeutung oder Einschränkungen usw..rppxqlndwlrqvdxwrqrplh Die Kommunikationsautonomie betrifft die Kommunikation mit anderen Systemen. Die lokalen Systeme unterstützen unterschiedliche Kooperationsprotokolle, so dass etwa die ordnungsgemäße Einhaltung eines 2-Phasen-Commit-Protokolls (2PC- Protokoll) nicht vorausgesetzt werden kann. Jede Quelle ist unabhängig in der Entscheidung, welche Informationen sie in das Informationssystem einbringt und auf welche Anfragen sie antwortet. $XVI KUXQJVDXWRQRPLH Die Komponenten sind autonom in der Ausführung von Datenbankoperationen. Dies betrifft insbesondere Transaktionsverwaltung, hierbei speziell die Mehrbenutzersynchronisation, die Anfragebearbeitung und die Integritätssicherung. +HWHURJHQLWlW Aufgrund der autonomen Entwicklung der Komponentensysteme trifft man bei deren Integration auf die verschiedensten Formen der Heterogenität zwischen den Systemen - von unterschiedlicher Hardware über verschiedene Datenmodelle bis hin zu differierendem Verständnis über die Semantik der enthaltenen Daten. Insbesondere bei Betrachtung des relationalen Datenmodells existiert eine große Spanne möglicher Konflikte. [Convey et al. 2000] haben verschiedenen Taxonomien für Formen von Heterogenität vorgestellt und verglichen. 7

8 Nach [Jarke et al. 2000] lassen sich Heterogenitätskonflikte wie folgt klassifizieren: Unter den Begriff +HWHURJHQLWlWVNRQIOLNWH fallen Probleme im Zusammenhang mit der Nutzung unterschiedlicher Datenmodelle in den verschiedenen Schemata. Ein Beispiel hierfür ist die Nutzung einer objektorientierten Datenbank in einem der Komponentenschemata, während das integrierte Schema aller Komponenten relational dargestellt werden soll. 1DPHQVJHEXQJVNRQIOLNWH treten auf, wenn verschiedene Schemata den selben Term zur Beschreibung unterschiedlicher Konzepte (Homonyme) oder aber verschiedene Terme zur Beschreibung ein und des selben Konzeptes (Synonyme) benutzen. Ein Homonym wäre z.b. die Vergabe des selben Tabellennamens für zwei in den jeweiligen Komponentenschemata unterschiedliche Konzepte. Um ein Synonym würde es sich dagegen handeln, wenn Attribute mit gleicher Bedeutung in den jeweiligen Komponentenschemata unterschiedlich benannt wären. Werden in den Komponentenschemata unterschiedliche Abstraktionslevel zur Beschreibung der gleichen Dateneinheit benutzt, spricht man von einem VHPDQWLVFKHQ.RQIOLNW Ein solcher Fall liegt vor, wenn z.b. in der einen Informationsquelle zwischen Autos und LKws unterschieden wird, während eine andere Quelle diese beiden Einheiten unter dem Begriff Automobil zusammenfasst. 6WUXNWXUHOOH.RQIOLNWH entstehen, wenn verschiedene Schemata die gleiche Information auf unterschiedliche Weise darstellen. Beispielsweise wenn in einem Schema die Informationen über Autos und ihre Besitzer in einer Tabelle gespeichert sind, ein anderes Schema diese Informationen aber in zwei getrennten Tabellen Autos und Besitzer darstellt. Zu strukturellen Konflikten ist auch die unterschiedliche Darstellung der Daten an sich zu zählen, d.h. ob die Daten strukturiert, semistrukturiert oder unstrukturiert vorliegen. 1 Auch wenn [Jarke et al. 2000] die oben vorgestellte Klassifikation zum Konsens langer Diskussionen in der Literatur erheben, so lassen sich durchaus auch Klassifikationen finden, die hiervon abweichen. [Vargun 1999] versteht die oben genannten Formen der Heterogenität als Folge semantischer Konflikte. Außerdem werden einige weitere Klassen unterschieden, die in [Jarke et al. 2000] nicht einbezogen sind und nachfolgend vorgestellt werden. 'RPDLQNRQIOLNWH treten auf, wenn in verschiedenen Schemata unterschiedliche Werte zur Darstellung des selben Konzeptes verwendet werden, z.b. in einer Quelle der Kaufpreis eines Autos als Integerwert, in einer anderen Quelle als String gespeichert ist. Wenn ein Konzept in einer Quelle durch das Schema, in einer anderen aber regulär als Teil der Daten definiert ist, spricht man von einem 0HWDGDWHQNRQIOLNWDieser tritt auf, wenn z.b. eine Quelle zwischen Autos und LKws unterscheidet, indem sie jeweils eine Tabelle für Autos und eine für LKws unterhält. Ob der Datensatz ein Auto oder ein LKw spezifiziert, hängt davon ab, in welcher Tabelle er steht. Eine andere Quelle stellt Autos und LKws in einer Tabelle dar und unterscheidet durch ein Feld im Datensatz, ob es sich um ein Auto oder LKw handelt. [Vargun 1999] beschreibt IHKOHQGH $WWULEXWH als eine eigene Klasse von Heterogenität. In [Jarke et al. 2000] fallen fehlende Attribute unter die Klasse der semantischen Konflikte. Beispiel für ein solchen Fall wäre ein Szenario, in dem eine Informationsquelle in der 1 siehe auch Abschnitt

9 Autoverkaufliste ein Datum für den letzten Ölwechsel vorsieht, das in anderen Informationsquellen nicht vorgesehen ist. +DUGZDUH 6RIWZDUHNRQIOLNWH bezeichnen Konflikte, die entstehen, wenn verschiedene zu integrierende Informationssysteme auf unterschiedlicher Hardware, Betriebssystemen, Kommunikationsprotokollen usw. laufen. Übereinstimmend mit [Convey et al. 2000] ist auch der Verfasser dieser Arbeit der Ansicht, dass letzterer Konflikt weniger durch semantische Inkonsistenzen begründbar ist, als vielmehr ein Low-Level Problem, das wenig mit der Semantik der Informationssysteme zu tun hat. [Leser et al. 1999] haben die verschiedenen Formen von Heterogenität in einer Übersicht zusammengefasst. Syntaktische Heterogenität o Technische Heterogenität ƒunterschiedliche Hardware ƒunterschiedliche Protokolle ƒunterschiedliche technische Zugriffsmethoden o Schnittstellenheterogenität ƒunterschiedliche Anfragesprachen ƒunterschiedliche logische Zugriffsmethoden Logische Heterogenität o Datenmodellheterogenität ƒunterschiedliche Datenmodelle ƒunterschiedliche Modellierungskonstrukte o Semantische Heterogenität ƒtabellennamen, Attributnamen und Klassennamenkonflikte ƒtabellenstrukturkonflikte (fehlende oder implizierte Attribute) ƒintegritätsbedingungskonflikte bei Tabellen und Attributen ƒdefault-wert-konflikte bei Attributen ƒfalsche oder veraltete Attributwerte (Daten) ƒunterschiedliche Repräsentationen (Ausdrücke, Einheit, Genauigkeit) Strukturelle Heterogenität o Tabellen-Attribut-Konflikte ƒstrukturkonflikte (Relationen zwischen Klassen) ƒabstraktionslevel-konflikte (Generalisierung, Aggregation) o Schematische Heterogenität ƒaggregation-level Mismatches ƒattribut-attributwert Konflikte 9HUWHLOXQJ Wie der Begriff verteilte Informationssysteme schon zeigt, ist Verteilung ein wesentlicher Aspekt. Da beim Aufbau großer Informationssysteme in der Regel existierende Systeme berücksichtigt werden müssen, in denen die Daten originär erfasst und verwaltet werden, entsteht automatisch ein verteiltes System. Die Verteilung wird in vielen Fällen zusätzlich durch die Organisationsstrukturen vorgegeben, die sich aus den historisch gewachsenen Kompetenzbereichen ergeben. Jedes Komponentensystem 2 kann wiederum in sich verteilt sein. Je nach verwendetem Ansatz und Konzept der Datenintegration (hierauf wird in einem 2 Unter Komponentensystemen werden in dieser Arbeit jeweils die Systeme verstanden, aus denen die Daten und Informationen in ein gemeinsames System integriert werden. 9

10 späteren Kapitel noch eingegangen) braucht diese Verteilung nicht berücksichtigt zu werden, da das Komponentensystem nach außen gekapselt auftritt und nur die Schnittstelle für die Integration von Interesse ist. [vergl. Leser et al. 1999] (YROXWLRQVIlKLJNHLW Verteilte Informationssysteme (VIS) können verschiedene Grade der Evolutionsfähigkeit besitzen. Grundsätzliches Ziel sollte sein, Änderungen im System mit relativ einfachem Aufwand durchführen zu können. Hierbei können Änderungen in verschiedenen Formen erforderlich sein. [vergl. Leser et al. 1999] /RJLVFKH bqghuxqjhq beziehen sich auf Änderungen oder Erweiterungen eines der Komponentenschemas oder auch des globalen Modells aller integrierten Schemata. Würden z.b. in einer Informationsquelle neben Autos und LKws auch Fahrräder in die Informationen mit aufgenommen, so würde dies zur Erweiterung des Komponentenschemas führen. Soll das übergreifende Informationssystem zusätzlich diese Informationen nach außen abfragbar machen, so muss auch das globale Modell entsprechend angepasst werden..rqiljxudwlrqvlqghuxqjhq sind Änderungen in Bezug auf die Anzahl der integrierten Informationssysteme oder des Ortes eines der Komponentensysteme, z.b. wenn ein weiterer Anbieter für Automobile an das System angeschlossen werden soll oder eine Informationsquelle, die bisher lokal verfügbar war, ausgelagert und über ein WAN oder das WWW in das Informationssystem integriert werden soll. Von V\VWHPWHFKQLVFKHU (YROXWLRQ spricht man, wenn das Datenbankmanagementsystem einer lokalen Komponente geändert wird, die Funktionalität des übergreifenden Informationssystems geändert wird oder das Informationssystem von heute die Komponente eines größeren übergreifenden Systems von morgen wird. Beispiele hier wären die Umstellung des DBMS von Oracle auf Informix, die Möglichkeit ein lokal verfügbares übergreifendes Informationssystem durch ein Webinterface auch über das WWW zugänglich zu machen oder die Einbringung des Informationssystems in ein Metasystem, das wiederum mehrere Informationssysteme verwandten Inhalts zusammenfasst. 2.2 Klassifikationskriterien verteilter Informationssysteme Die eingangs schon erwähnte immer schneller wachsende Menge an Daten, die in elektronischer Form zur Verfügung stehen und die damit im vorangegangenen Kapitel beschriebenen einhergehenden Aspekte, haben zu der Entwicklung verschiedener datenintegrierender Ansätze geführt. In [Busse 1999 S. 9 ff] findet sich eine ausführliche Sammlung von Klassifikationskriterien verteilter Informationssysteme in Bezug auf deren Umgang mit Autonomie, Heterogenität, Verteiltheit und Evolution. Im Folgenden sollen diese Kriterien in Anlehnung an [Busse 1999] ergänzt um weitere in der Literatur auffindbare Klassifikationsansätze z.b. in [Domenig, Dittrich 2000] vorgestellt werden. Anschließend werden die derzeit nach [Domenig, Dittrich 2000] und [Busse 1999] unterscheidbaren Ansätze der Datenintegration vorgestellt und in einer Übersicht die positiven und negativen Aspekte der einzelnen Ansätze diskutiert. 0DWHULDOLVLHUHQGHYVYLUWXHOOH6\VWHPH Zunächst lassen sich materialisierende und virtuelle Systeme unterscheiden. Beim materialisierenden Ansatz spricht man auch von der In-Advance-Integration oder 10

11 auswertungsorientierten Integration [vergl. Vossen 1999]. Die relevanten Informationen werden den verfügbaren Quellen im voraus entnommen, gegebenenfalls angemessen gefiltert, aufbereitet und konsolidiert und in einer zentralen Datenbank abgelegt. Wird dann eine Anfrage gestellt, so wird diese direkt auf der neuen Datenbank ausgewertet, also ohne Rückgriff auf die Quellen. Der virtuelle Ansatz hingegen verzichtet auf die Materialisierung der Daten in einer zentralen Datenbank. [Vossen 1999] spricht auch von einer On-Demand-Integration oder anfrageorientierten Integration. Zu einer gegebenen Anfrage oder Anwendung werden zunächst die relevanten Informationsquellen bestimmt und sodann für jede Quelle eine entsprechende Teilanfrage generiert. Die zurückgelieferten Resultate werden integriert und schließlich an die Anwendung zurückgeliefert. Die Integration der Daten geschieht somit on the fly während der Anfragebearbeitung. (QJHYVORVH.RSSOXQJGHU.RPSRQHQWHQGDWHQEDQNV\VWHPH Der virtuelle Zusammenschluss mehrer Informationsquellen (Datenbanken) wird auch als Föderation und Systeme, die auf diesem Zusammenschluss aufbauen, als föderierte Datenbanksysteme (FDBS) bezeichnet. Zwei Arten von Föderation lassen sich unterscheiden, wobei die Klassifikation auf dem Grad an Autonomie 3 der jeweiligen Komponentensysteme beruht [vergl. Leser et al S. 17]. Man spricht von einer HQJHQ.RSSOXQJ wenn die Komponentendatenbanksysteme (KDBS) einen Teil der Autonomie aufgeben, damit das FDBS einen integrierten Zugriff und weitergehende Datenbankfunktionalität wie Integritätssicherung und Transaktionen anbieten kann. Andernfalls wird von loser Kopplung gesprochen [Saake 1999 S. 604] Eine enge Kopplung erfordert ein vereinheitlichtes globales Schema, das dann als Zugangsschema zum föderierten Informationssystem für jeden Anwender dient. Man spricht auch von einem integriertem oder föderiertem Schema. Die semantische Bedeutung des integrierten Schemas muss dabei eine Untergruppe der Vereinigung der semantischen Bedeutungen aller Komponentenschemata darstellen. Die Hauptaufgabe bei der Benutzung des integrierten Schemas liegt in der Handhabung und Auflösung der logischen Heterogenität 4 der Quellschemata. Sowohl bei der Schemaintegration als auch während der Anfragebearbeitung müssen dem eng gekoppeltem System die Zusammenhänge zwischen Anfrage, integriertem Schema und Komponentenschemata in Form von Metadaten bekannt sein. Diese Metadaten können beispielsweise in Form von Ontologien vorliegen. Das macht die Nutzung eng gekoppelter Systeme für die Anwender und zugreifenden Applikationen recht komfortabel, da kein Wissen über die Komponentenschemata mehr erforderlich ist. Auf der anderen Seite sind sie abhängig von korrekten Metadaten und den darauf basierenden Übersetzungsmechanismen. Kennzeichen eng gekoppelter Systeme ist daher auch, dass die Föderation durch einen entsprechenden Administrator erstellt und überwacht wird. Seine Aufgabe ist es, sich mit den Administratoren der Komponentensysteme abzusprechen, welche Teile der lokal verwalteten Daten in die Föderation eingehen und wie die lokalen Datenbankschemata auf ein Föderierungsschema abgebildet werden [vergl. Conrad 1997 S. 42]. /RVH JHNRSSHOWH Systeme basieren hingegen nicht auf einem solchen integrierten Schema. Sie stellen lediglich eine vereinheitlichte Anfragesprache bereit, mit der die Daten der Komponenten abgefragt werden können. Diese Sprache abstrahiert von den Abfragesprachen der Komponentensysteme und verdeckt technische und semantische Heterogenitäten. Somit ist jeder Anwender bzw. jede 3 siehe auch Abschnitt siehe auch Abschnitt

12 Applikation, die auf das lose gekoppelte System zugreift, selbst für die Handhabung und Auflösung der logischen Heterogenität zwischen den Komponenten sowie die Auswahl der Quellen verantwortlich. Diese Funktionalität kann alternativ durch eine Zwischenschicht, sogenannte Middleware übernommen werden, die den Quellsystemen ihre Autonomie belässt und lediglich eine vermittelnde Position zwischen Benutzer bzw. Applikation und Datenquellen einnimmt. Lose gekoppelte Systeme können nur auf Quellen basierend gebildet werden, die einen Zugriff per Abfragesprache gleich welcher Art 5 erlauben. Des Weiteren können keine Zugangsbeschränkungen oder zwingende Abfrageelemente modelliert werden 6WUXNWXULHUWHVHPLVWUXNWXULHUWHXQGXQVWUXNWXULHUWH.RPSRQHQWHQGDWHQ Verteilte Informationssysteme (VIS) unterscheiden sich in den Komponententypen, die sie integrieren können. Je nach VIS kann es möglich sein, strukturierte, semi-strukturierte und unstrukturierte Komponenten zu integrieren. Nach [Busse 1999] zeichnen sich VWUXNWXULHUWH Quellen dadurch aus, dass sie Daten nach einem vordefinierten Schema darstellen. Alle Datenelemente sind durch das Schemaelement definiert, dem sie angehören. Dieses diktiert das Format aller Datenelemente und solche, die nicht in das Schema passen, können nicht in den Datensatz aufgenommen werden. Auch VHPLVWUXNWXULHUWH Datenquellen stellen ihre Daten in strukturierter Form dar, allerdings ist der Aufbau nicht in Form eines strikten Schemas vorgegeben, vielmehr enthält jeder einzelne Datensatz seine eigene semantische Definition. Eine solche Datenquelle könnte beispielsweise aus einer Sammlung von XML-Dokumenten bestehen. Die XML Tags definieren die Semantik und die Summe aller möglichen Tags entspricht dann dem Gesamtschema der Quelle. 6 Unter XQVWUXNWXULHUWH Datenquellen fallen alle Quellen, deren Daten gar keine Struktur haben, wie z.b. Textdokumente oder HTML-Dokumente, bei denen die Informationen in Form von freiem Text vorliegen. %RWWRPXSYV7RSGRZQ Eng gekoppelte Systeme lassen sich nach zwei Gesichtspunkten entwickeln. Bei der 7RS 'RZQMethode startet die Entwicklung ausgehend von den Anforderungen an das gekoppelte System. Zuerst wird in der Regel ein globales Schema festgelegt, das alle der Anforderung entsprechenden Konzepte enthält. Von diesem Schema ausgehend, werden die geeigneten Komponentensysteme bestimmt und logisch sowie semantisch mit dem globalen Schema in Beziehung gesetzt. Bei der %RWWRP8S Entwicklung verhält es sich genau umgekehrt. Hier besteht die Anforderung darin, eine festgelegte Menge von Komponenten in ein integriertes System zu verwandeln, also ausgehend von den Komponentenschemata ein globales Schema abzuleiten. 7UDQVSDUHQ] Transparenz für den Anwender bzw. die Applikation ist laut [Busse 1999] das ultimative Ziel der Integration. Ein perfekt integriertes System würde dem Benutzer die Illusion vermitteln nur mit einem zentralen, lokalen, homogenen Informationssystem zu interagieren. [Busse 1999] unterscheiden drei Arten von Transparenz: 5 siehe auch Abschnitt XML Dokumente müssen einer Document Type Definititon (DTD) genügen. Diese DTD kann als Definition des Gesamtschemas betrachtet werden. 12

13 6WDQGRUWWUDQVSDUHQ] besagt, dass der Benutzer keine Information bezüglich des physikalischen Standorts der Informationsquelle benötigt. Es ist irrelevant, ob die Quelle lokal vorliegt oder nicht. Die Angabe einer IP-Adresse bzw. eines Hostnamens reicht für den Zugriff aus. Besteht 6FKHPDWUDQVSDUHQ] so benötigt der Benutzer kein Wissen über unterschiedliche Bezeichnungen der Attribute oder Entities in den verschiedenen Datenquellen. Alle logischen Konflikte sind verdeckt. Hierzu ist dann allerdings ein integriertes Schema, also ein eng gekoppeltes System Vorraussetzung. Braucht sich der Anwender bzw. die Applikation nicht mit unterschiedlichen Anfragesprachen oder Zugangsmechanismen zu befassen, so spricht man von 6SUDFKWUDQVSDUHQ]. Das bedeutet, dass dem Anwender verborgen bleibt, in welche Anfragesprachen seine Anfrage zerlegt wird und ob seine Anfrage als SQL-Statement oder in Form eines Remote Procedure Calls (RPC) an die Komponentensysteme weitergeleitet wird. Diese drei Transparenzarten adressieren jeweils verschiedene Formen von Heterogenität. Die Standorttransparenz eliminiert die technische Heterogenität, die Schematransparenz versteckt die logische Heterogenität und die Sprachtransparenz deckt die Bereiche der Interfaceheterogenitäten ab. Eine völlige Transparenz zu erreichen, ist sehr schwierig bis unmöglich, da hierzu in allen Quellen die entsprechenden Abfragemöglichkeiten vorhanden sein müssen. Lässt eine der Quellen nur bestimmte Anfragearten zu, dann ist eine Kompensation, falls überhaupt, nur möglich, wenn der komplette Datensatz zur Verfügung steht und die fehlende Abfragemöglichkeit in einem nachgeschalteten Schritt auf Basis dieses kompletten Datensatzes nachgebildet wird. Den kompletten Datensatz herunterzuladen kann allerdings aufgrund des Umfanges recht teuer sein. [vergl. Busse 1999] $EIUDJHDUWHQ Informationssysteme können nach den Abfragearten unterschieden werden, die sie unterstützen [vergl. Busse 1999]. 6WUXNWXULHUWH$EIUDJHQ enthalten einen gewissen Aufbau der Informationselemente, die zur Abfrage der Informationsquelle angegeben werden, wie z.b eine SQL-Abfrage an ein DBMS.,QIRUPDWLRQ 5HWULHYDO $EIUDJHQ suchen ihre Informationen durch Ähnlichkeitsanalysen der angegebenen Suchbegriffe zu Textdokumenten, also z.b., wie oft und wie nahe beisammen die entsprechenden Suchbegriffe in den durchsuchten Dokumenten vorkommen. Die Technik des Information Retrieval ist Gegenstand vieler Forschungsarbeiten und soll im Rahmen dieser Arbeit nicht weiter erläutert werden. Siehe auch [Beaeza-Yates, Ribiero-Neto 1999]. =XJULIIVUHFKWH Verteilte Informationssysteme sind in der Regel dazu ausgelegt, Informationen von verschiedenen Quellen zu beziehen, also lesend auf die Komponentensysteme zuzugreifen. Aus diesem und einer Reihe von weiteren Gründen wird deßhalb meist auf einen Schreibzugriff auf die Quellen verzichtet. Zu diesen Gründen zählen z.b. [vergl. Busse 1999]: Viele Schnittstellen, z.b Webschnittstellen, erlauben keinen Schreibzugriff. 13

14 Der Schreibzugriff über ein integriertes Schema wirft die Frage auf, welche Quelle aktualisiert werden soll, wenn die entsprechende Klasse in mehreren Datenquellen existiert. Globale Transaktionen erfordern komplexe Protokolle, um die Integrität und Konsistenz der Daten sicherzustellen. Beispiel hierzu wäre das 2-Phase-Comitt (2PC) Protokoll Die Autonomie der Quellen wird durch die Möglichkeit des Schreibzugriffes stark eingeschränkt und wiederspricht somit einer der Grundideen verteilter Informationssysteme, den Quellsystemen eine möglichst große Autonomie zu gewähren. Dennoch ist eine Differenzierung der Systemansätze in nur lesend und Schreib- Lesezugriff möglich. =XJULIIVPHWKRGHQ Nach [Busse 1999] lassen sich drei Arten von Zugriffsmethoden unterscheiden. Unter der Zugriffsmethode werden die Möglichkeiten verstanden, mit denen die Daten der verschiedenen Komponenten abgefragt werden können. Insbesondere bei der dynamischen virtuellen Integration sind diese von Bedeutung. Typischerweise hat ein Client ein oder mehrere der folgenden Zugriffsmöglichkeiten. Zugriff durch eine $EIUDJHVSUDFKH, wie zum Beispiel SQL. Dieser Zugriff kann einmal durch die Schnittstelle der Datenquelle selbst wie z.b. Open Database Connectivity ODBC oder Java Database Connectivity JDBC ermöglicht werden. Auch die Abfrage über ein spezielles Formular im Web oder eine spezielle Methode innerhalb der CORBA API ist denkbar. Zugriff durch eine SDUDPHWULVLHUWHJHNDSVHOWH$QIUDJH. Unter diesem Begriff lässt sich eine vordefinierte Abfrage verstehen, die einige variable Elemente enthält. Am Beispiel einer SQL-Anfrage würde eine solche Abfrage typischerweise aus festen Select- und From-Ausdrücken, festen Join-Bedingungen im Where-Ausdruck und weiteren festen Bedingungen im Where-Ausdruck bestehen, wobei die Werte, mit denen die Attribute verglichen werden, frei spezifiziert werden können. Zugriff durch EURZVLQJ. Vor allem im Web können Daten oft nur angezeigt und nicht durchsucht werden. Unter dieser Vorraussetzung ist eine Abfrage/Suche begrenzt auf ein Durchforsten der Datenbestände im Web, wie es die Indexserver der Suchmaschinen mit ihren Searchrobots betreiben. Vom Gesichtspunkt der Heterogenität, fallen die unterschiedlichen Zugriffsmethoden sowohl in den Bereich der technischen Heterogenität als auch der Heterogenität der Abfragesprachen. 2.3 Verschiedene Ansätze der Datenintegration Nicht alle der eben vorgestellten Kriterien lassen sich orthogonal auf alle Ansätze anwenden. Während z.b. die Klassifikation bezüglich der integrierten Komponenten in strukturierte, semi-strukturierte und unstrukturierte Komponenten auf alle Ansätze anwendbar ist, so lässt sich z.b. die Klassifikation in enge oder lose gekoppelte Ansätze nur auf virtuell integrierte Systeme anwenden. Im Folgenden sollen nun die derzeit unterscheidbaren Ansätze 14

15 der Datenintegration vorgestellt und abschließend in einer Übersicht die Klassifikationskriterien, soweit dies möglich ist, zugeordnet werden. 8QLYHUVHOOH'%06 Bei diesem Ansatz werden die Daten der lokalen Systeme zu einem universellen DBMS migriert. Dieses DBMS ist dann in der Lage, alle oder zumindest viele Typen von Information zu bearbeiten. Beispiele dafür sind objekt-relationale oder objektorientierte DBMS. Daten lokaler Systeme werden extrahiert, integriert und in einer zentralen Datenbank gespeichert. Nach vollzogener Migration werden die lokalen Systeme zumindest prinzipiell nicht weiter verwendet. Eine weitergehende Erläuterung zu universellen DBMS findet sich bei [Behm et al. 1997]. Dieser Ansatz gehört zur Gruppe der materialisierenden Ansätze. 'DWD:DUHKRXVH Auch der Data Warehouse Ansatz gehört zu den materialisierenden Ansätzen der Datenintegration. Man unterscheidet grob zwei Arten von Datenbankanwendungen: online transaction processing (OLTP) und online analytical processing (OLAP). Unter OLTP fallen solche Anwendungen wie Buchung eines Fluges in einem Flugreservierungssystem oder Verarbeitung einer Bestellung in einem Handelsunternehmen. OLTP-Anwendungen realisieren das operationale Tagesgeschäft eines Unternehmens. Sie zeichnen sich dadurch aus, dass sie nur begrenzte Datenmengen für eine auszuführende Transaktion zu verarbeiten haben. OLTP-Anwendungen operieren auf dem jüngsten aktuell gültigen Zustand des Datenbestandes. Demgegenüber verarbeiten OLAP-Anwendungen große Datenmengen und insbesondere greifen sie auf historische Daten zurück, um daraus z.b. Rückschlüsse auf die Entwicklung des Unternehmens zu gewinnen. Typische OLAP-Anfragen in (...) den beiden Beispielszenarien (Fluggesellschaft und Handelsunternehmen) wären etwa: Wie hat sich die Auslastung der Transatlantikflüge über die letzen zwei Jahre entwickelt? Wie haben sich besonders offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt? OLAP-Anwendungen bilden also die Grundlage für die strategische Unternehmensplanung (...) Es besteht mittlerweile Konsens, dass man OLTP- und OLAP- Anwendungen nicht auf demselben Datenbestand (d.h. auf derselben physischen Datenbasis) ausführen sollte. Hierfür gibt es mehrere Gründe: OLTP-Datenbanken sind hinsichtlich logischem und physischem Entwurf auf Änderungsaktionen mit Zugriff auf sehr begrenzte Datenmengen hin optimiert. Die operationalen Datenbestände eines Unternehmens sind meist auf viele Datenbanken oft auch unterschiedlicher Hersteller verteilt. Für OLAP-Auswertungen benötigt man diese Informationen aber in konsolidierter, integrierter Form. OLAP-Anfragen sind sehr komplex; ihre (parallel ablaufende) Auswertung könnte die Leistungsfähigkeit der OLTP- Anwendungen deutlich beeinträchtigen. Aus oben skizzierten Gründen wird heute der Aufbau eines sogenannten Date Warehouse propagiert. Darunter versteht man ein dediziertes Datenbanksystem, in dem die für Decision- Support-Anwendungen notwendigen Daten eines Unternehmens in konsolidierter Form gesammelt werden. [Kemper 1997, S. 458] Im Gegensatz zum oben beschriebenen Ansatz sind beim Data Warehouse Ansatz die zugrundeliegenden Quellsysteme also weiterhin im Einsatz und werden von OLTP- 15

16 Anwendungen genutzt. Die Daten werden lediglich von den Informationsquellen importiert. Typischerweise geschieht dies allerdings nicht im selben Umfang und derselben Form, wie die Daten im Quellsystem vorliegen, sondern transformiert, bereinigt, und für bestimmte Analyseaufgaben vorbereitet. Wie oft der Datenbestand des Data Warehouse periodisch aufgefrischt wird, hängt von den jeweiligen Anforderungen der Anwendungen ab. Diese Auffrischung geschieht dann allerdings in der Regel im Batchmodus, da interaktive Änderungsoperationen in Data Warehouse-Anwendungen eine eher untergeordnete Rolle spielen. Abbildung 1 skizziert die Architektur des Datawarehouse und das Zusammenspiel zwischen operationalen Datenbanken und dem Data Warehouse. OLTP Online Transaction Processing OLAP Online Analytical Processing operationale DB operationale DB Data Warehouse operationale DB operationale DB initiales Laden und periodische Auffrischung des Data Warehouse $EE=XVDPPHQVSLHO]ZLVFKHQRSHUDWLRQDOHQ'DWHQEDQNHQXQGGHP'DWD:DUHKRXVH 0HWDVXFKPDVFKLQHQ Bezüglich der Anfragen an unstrukturierte Quellen haben (Meta-)Suchmaschinen eine große Bedeutung gewonnen. Dies liegt hauptsächlich an der großen Popularität des WWW, das eine große, heterogene, verteilte Sammlung von Dokumenten, die über Hyperlinks verbunden sind darstellt. Die derzeit verbreitetste Technologie das Web zu durchsuchen sind sogenannte Indexserver, die mittels Robotiksoftware die Dokumente im Web indizieren. Diese können durch Suchanfragen abgefragt werden und stellen somit einen zentralen Zugangspunkt zu den indizierten Dokumenten dar [vergl. Domenig, Dittrich 2000 und Mendelzon 1997]. Das Ergebnis dieser Suchanfragen ist in der Regel eine Liste von Hyperlinks zu den entsprechenden Dokumenten. In den Anfängen der Suchmaschinen konnte man bei den indizierten Dokumenten von homogenen HTML-Daten ausgehen, da es sich in der Regel um den Text in HTML Dateien handelte [vergl. Domenig, Dittrich 2000]. Neue Entwicklungen machen es heutzutage möglich, Daten in Dateien zu suchen, die nicht im HTML-Format vorliegen. Beispiel hierzu 16

17 ist die Suchmaschine Google, die z.b. auch PDF-Dateien (Adobe Portable Document Format) oder PS-Dateien (Postscript Format) in den indizierten Dokumenten enthalten [vergl. Google 2002]. Um die Ergebniseffektivität zu erhöhen, wurden Metasuchmaschinen entwickelt, die Anfragen parallel an mehrere Suchmaschinen senden, die Ergebnisse sammeln und dem Benutzer präsentieren. Der Hauptaugenmerk der Metasuchmaschinen liegt in der Kombination und einheitlichen Darstellung der Ergebnisse. Da es zu Überschneidungen der Ergebnisse kommen kann, wenn mehrere Unteranfragen dieselben Treffer finden, besteht eine Aufgabe der Metasuchmaschinen darin, mehrfach vorkommende Ergebnisse entsprechend zu filtern und nur einmal darzustellen. Beispiele hierfür sind die Metasuchmaschinen Metacrawler ( oder die Freewaresoftware Webferret der Firma FerretSoft ( Abbildung 2 skizziert das Zusammenspiel von Suchmaschinen und Metasuchmaschinen im Web. Website 1 Website 2 Website 3 Suchmaschine A Metasuchmaschine Suchmaschine B Website 4 Website 5 $EE6XFKXQG0HWDVXFKPDVFKLQHQ 0XOWLGDWHQEDQNV\VWHPH Der Begriff Multidatenbank bzw. Multidatenbanksystem (MDBS) wird in der Literatur unterschiedlich verwendet. [Conrad 1997] versteht unter MDBS im weiteren Sinne einen Verbund von mehreren Datenbanksystemen, die im Gegensatz zu verteilten Datenbanksystemen VDBS oder zentralen Datenbanksystemen von verschiedenen Datenbankmanagementsystemen verwaltet werden. [Busse 1999] und auch [Saake 1999 S.627] hingegen verstehen unter Multidatenbanken im engeren Sinne einen Zusammenschluss von bestehenden Datenbanksystemen, auf die mittels einer sogenannten Multidatenbanksprache zugegriffen wird. Diese Multidatenbanksprache ist dadurch gekennzeichnet, dass sie erlaubt, innerhalb einer Anfrage auf mehrere verschiedene Datenbanken zuzugreifen. Zentrale Annahme der Multidatenbanksysteme ist also, dass der Benutzer auf verschiedene Datenbanken zugreift, ohne dass ein globales Schema vorhanden ist. Die Autonomie der Datenbanken führt zu typischen Problemen wie Redundanz gespeicherter Daten, strukturelle 17

18 Unterschiede zwischen den einzelnen Datenbanken sowie Unterschieden in der Bezeichnungsweise, die in Homonymen oder Synonymen resultieren. 7 Diese Probleme müssen zum Einen durch adäquate Konzepte der Multidatenbanksprache, durch entsprechende Behandlung in der darüber liegenden Applikation bzw. durch den Benutzer selbst gelöst werden. Abbildung 3 zeigt eine Referenzarchitektur, die im Folgenden in Anlehnung an [Conrad 1997] erläutert wird. Benutzer 1 Benutzer 2 Benutzer 3 Benutzer 4 Benutzer 5 ES 1 ES n1 ES n2 H[WHUQHÃ(EHQH KS 1 KS 2 KS n AS 1 AS j NRQ]HSWLRQHOOHÃ(EHQH ILS 2 PS 1 PS 2 ILS n PS n ES - externes Schema KS - konzeptionelles Schema AS - Abhängigkeitsschema ILS - internes logisches Schema PS - physisches Schema DB 1 DB 2 DB 3,QWHUQHÃÃ(EHQH $EE0XOWLGDWHQEDQN$UFKLWHNWXU>/LWWZLQ@ Jede an der Multidatenbank beteiligte lokale Datenbank hat ein SK\VLVFKHV6FKHPDPS), das die interne, physikalische Struktur der Daten beschreibt. Dieses Schema entspricht damit dem internen Schema in der klassischen Drei-Ebenen-Architektur nach ANSI/SPARC. Das LQWHUQH ORJLVFKH 6FKHPD (ILS) stellt die Gesamtheit der von dem jeweiligen Komponentensystem verwalteten Daten dar und entspricht somit dem konzeptionellen Schema der Drei-Ebenen-Schema-Architektur. Das NRQ]HSWLRQHOOH 6FKHPD (KS) ermöglicht es, nur einen Teil der Daten nach außen hin sichtbar zu machen oder die Daten in einer vom internen Schema abweichenden Struktur darzustellen. In diesem Fall entspricht es dem externen Schema der Drei-Ebenen-Architektur. Soll die Sicht auf die Daten weder eingeschränkt noch eine andere Struktur dargestellt werden, so ist das konzeptionelle Schema gleich dem internen logischen Schema. Dieses kann dann entfallen und das konzeptionelle Schema wird direkt über dem physischen Schema angeordnet. (siehe DB1 in der Abbildung 3) Jeder Benutzer kann sich sein eigenes H[WHUQHV 6FKHPD aus den auf Multidatenbankebene vorhandenen konzeptionellen Schemata der einzelnen Komponentensysteme zusammenstellen. In Abbildung 3 stellt sich z.b. Benutzer 1 ein eigenes externes Schema aus den konzeptionellen Schemata der Datenbanken DB 1 und DB 2 zusammen. Die hierfür nötige Zugriffsmöglichkeit direkt auf die konzeptionellen Schemata stellt eine Besonderheit der Multidatenbanksysteme dar. Normalerweise haben Benutzer keinen Zugriff auf konzeptioneller Ebene, sondern greifen auf das durch den Datenbankadministrator erstellte externe Schema zu. 7 vergl. Abschnitt 2.1.) 18

19 In manchen Fällen, wenn ein Benutzer z.b. eine einmalige Anfrage an das Multidatenbanksystem stellen möchte, lohnt sich der explizite Aufbau eines externen Schemas nicht. In diesem Fall kann eine Anfrage auch direkt an die konzeptionellen Schemata gerichtet werden. (siehe Benutzer 2 in Abbildung 3) Um sogenannte Interdatenbankabhängigkeiten zu beschreiben, werden $EKlQJLJNHLWVVFKHPDWD eingeführt. Solche Abhängigkeiten können beispielsweise auf der redundanten Speicherung von Daten in mehreren Komponentendatenbanken beruhen. In diesen Abhängigkeitsschemata können für (Teil-) Mengen der beteiligten Datenbanken durch Formulierung in einer gemeinsamen Datenbanksprache (die Multidatenbanksprache) solche Abhängigkeiten gespeichert und neue hinzugefügt werden. Hierdurch lassen sich datenbankübergreifende Integritätsbedingungen realisieren. Die vorgestellten Schemata lassen sich in drei Ebenen einordnen. Die verschiedenen von den Benutzern erstellten externen Schemata bilden die H[WHUQH (EHQH. Die konzeptionellen Schemata zusammen mit den Abhängigkeitsschemata bilden die NRQ]HSWLRQHOOH(EHQH. Der LQWHUQHQ(EHQH sind die physischen und die internen logischen Schemata zugeordnet. Ein Beispiel für die bereits angesprochene Multidatenbanksprache ist MSQL. Im wesentlichen handelt es sich dabei um eine Erweiterung von SQL um Funktionalitäten im Bereich der Datendefinition (für externe Schemata), der Anfrageformulierung, der schon angesprochenen Formulierung von Interdatenbankabhängigkeiten, sowie der Datenänderung [vergl. Conrad 1997 S. 228]. ) GHULHUWH'DWHQEDQNV\VWHPH)'%6 Unter föderierten Datenbanken versteht man eine in der Regel verteilte Datenhaltung mit zu integrierenden (teil-) autonomen und heterogenen Datenhaltungskomponenten. Diese Datenhaltungskomponenten werden als Komponenten-Datenbanksysteme, kurz KDBS, bezeichnet. [Saake 1999, S. 601] Ziel föderierter Datenbanken ist es, dem Benutzer den Eindruck zu verschaffen, nur mit einem DBMS zu arbeiten, während die Daten tatsächlich von mehreren individuellen DBMS verwaltet werden.[vergl. Domenig, Dittrich 2000] [Busse 1999 S.19] versteht unter FDBS eng gekoppelte Informationssysteme mit vollständiger Standort- und Schematransparenz und fasst damit den Begriff des FDBS enger als in den zuvor zitierten Quellen. In diese Arbeit soll unter dem Begriff des FDBS die Variante der eng föderierten Datenbanksysteme verstanden werden. Während in der Literatur für lose gekoppelte Systeme Beispiele wie die zuvor vorgestellten Multidatenbanksysteme oder mediatorbasierte Systeme 8 zu finden sind, lässt sich im Bereich der eng gekoppelten Systeme die 5-Ebenen-Architektur nach Sheth und Larson als Referenzarchitektur ausmachen, die das Konzept (eng) föderierter Datenbanksysteme erfüllen [vergl. Saake 1999 S.605]. Entsprechend der in Kapitel vorgestellten Merkmale eng gekoppelter Systeme zeichnen sich die 5-Ebenen-Architektur durch ein globales föderiertes Schema auf einer den Komponentensystemen übergeordneten Ebene aus. Dieses führt dazu, dass die 5-Ebenen- Architektur recht statisch in Bezug auf Erweiterbarkeit oder Änderungen des Systems ist 9. 8 siehe auch Abschnitt siehe auch Abschnitt

20 externes Schema 1 externes Schema j föderiertes Schema Exportschema 1 Exportschema 2 Exportschema n Komponentenschema 1 Komponentenschema 2 Komponentenschema n lokales Schema 1 lokales Schema 2 lokales Schema n Datenbank 1 Datenbank 2 Datenbank n $EE(EHQHQ6FKHPD$UFKLWHNWXUQDFK6KHWKXQG/DUVRQ Das ORNDOH6FKHPD in der 5-Ebenen-Architektur entspricht dem konzeptionellen Schema des jeweiligen Komponentendatenbanksystems und stellt die implementierungsunabhängige Beschreibung der Gesamtheit aller im Komponentensystem verwalteten Daten dar. Da föderierte Datenbanksysteme typischerweise aus bereits bestehenden und somit potenziell heterogenen und autonomen Datenbanksystemen zusammengesetzt sind, liegen diese lokalen Schemata häufig in unterschiedlichen Datenmodellen vor. Die Integration der Komponentensysteme erfordert eine Architektur jedes einzelnen Systems, die sich in die verschiedenen Schemaebenen der 5-Ebenen-Architektur abbilden lässt. In der dieser Arbeit zugrundeliegenden Literatur wird hierbei von einer Drei-Ebenen-Architektur der Komponenten ausgegangen. Eine Zuordnung der Schemaebenen zu den Schemaebenen in den Komponenten lässt sich nicht einwandfrei bewerkstelligen. Eine Diskussion dieses Problems in [Conrad 1997 S. 59 ff] kommt allerdings zu dem Schluss, dass hierfür eine Lösung möglich ist, indem nicht zuordenbare Transformationsschritte zwischen den Schichten auf einer der Ebenen zusammengefasst werden. Im Folgenden soll daher nicht versucht werden, Komponentenschemaebenen den Schemaebenen der 5-Ebenene-Architektur zuzuordnen. Die bereits angesprochene Datenmodellheterogenität der lokalen Schemata zu beseitigen ist Aufgabe des.rpsrqhqwhqvfkhpdv. Das Komponentenschema enthält alle Daten des lokalen Schemas, beschreibt diese allerdings in einem einheitlichen Datenmodell, in dem auch das föderierte Schema beschrieben ist. Die Aufgabe des ([SRUWVFKHPDV besteht darin, auf Basis des Komponentenschemas und unter Benutzung des dort verwendeten Datenmodells, den Ausschnitt der Daten zu definieren, welcher der Föderation zur Verfügung gestellt wird. Das I GHULHUWH 6FKHPD (in der Literatur auch häufig als globales Schema bezeichnet) beschreibt die Gesamtheit der durch die Exportschemata in die Föderation einfließenden Daten. Hierzu werden die Exportschemata aller an der Föderation teilnehmenden Komponenten global verfügbar zusammengefasst. Optional können speziell auf Anwendungen oder Benutzergruppen zugeschnittene externe Schemata definiert werden. Hierfür können je nach Anforderung auch Datenmodelle verwendet werden, die nicht mehr dem Datenmodell des föderierten Schemas entsprechen. 20