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

Größe: px
Ab Seite anzeigen:

Download "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 (www.metacrawler.com) oder die Freewaresoftware Webferret der Firma FerretSoft (www.ferretsoft.com). 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 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

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

Mehr

Datenintegration & Datenherkunft Architekturen

Datenintegration & Datenherkunft Architekturen Datenintegration & Datenherkunft Architekturen Wintersemester 2010/11 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen 1 Kapitel 4 Architekturen Überblick

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 17 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining opera- tionale DB opera- tionale DB opera- tionale DB Data Warehouse

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen (Folien von A. Kemper zum Buch 'Datenbanksysteme') Online Transaction Processing Betriebswirtschaftliche Standard- Software (SAP

Mehr

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 16 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining operationale DB operationale DB operationale DB Data Warehouse operationale

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

Kommunikationsübersicht XIMA FORMCYCLE Inhaltsverzeichnis

Kommunikationsübersicht XIMA FORMCYCLE Inhaltsverzeichnis Kommunikationsübersicht Inhaltsverzeichnis Kommunikation bei Einsatz eines MasterServer... 2 Installation im... 2 Installation in der... 3 Kommunikation bei Einsatz eines MasterServer und FrontendServer...

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

Kapitel 4: Data Warehouse Architektur

Kapitel 4: Data Warehouse Architektur Data Warehousing, Motivation Zugriff auf und Kombination von Daten aus mehreren unterschiedlichen Quellen, Kapitel 4: Data Warehousing und Mining 1 komplexe Datenanalyse über mehrere Quellen, multidimensionale

Mehr

Data Warehouse. für den Microsoft SQL SERVER 2000/2005

Data Warehouse. für den Microsoft SQL SERVER 2000/2005 Warehouse für den Microsoft SQL SERVER 2000/2005 Begriffe 1 DWH ( Warehouse) ist eine fachübergreifende Zusammenfassung von Datentabellen. Mart ist die Gesamtheit aller Datentabellen für einen fachlich

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Das Redaktionssystem UCMS. Beschreibung Technisches Profil

Das Redaktionssystem UCMS. Beschreibung Technisches Profil 1/6 CONTENTMANAGEMENTSYSTEM UCMS 03.12.08 Das Redaktionssystem UCMS Beschreibung Technisches Profil Das vorliegende Dokument gibt einen Überblick über das System und geht auf die Ankopplung oder Integration

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Technische Prozesse der Archivierung am Beispiel SAP R/3. Teil III: Dokumentenverarbeitung in SAP R/3

Technische Prozesse der Archivierung am Beispiel SAP R/3. Teil III: Dokumentenverarbeitung in SAP R/3 Elektronische Archivsysteme im kommerziellen Einsatz Institut für Publizistik und Kommunikationswissenschaften Dozent: R. Weißbach WS 00/01 Technische Prozesse der Archivierung am Beispiel SAP R/3 Teil

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II.

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II. II. bereitstellung Kapitel II bereitstellung 1 2 II. bereitstellung II.1 Grundlagen Collect Initial Data identify relevant attributes identify inconsistencies between sources Describe Data characterize

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

5 Schemadefinition in objektrelationalen Datenbanksystemen

5 Schemadefinition in objektrelationalen Datenbanksystemen 75 5 Schemadefinition in objektrelationalen Datenbanksystemen In diesem Kapitel wird die Definition objektrelationaler Schemata am Beispiel von DB2 konkretisiert. Zu diesem Zweck wird zunächst das DBMS

Mehr

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery Kapitel II Datenbereitstellung 2004 AIFB / FZI 1 II. Datenbereitstellung 2004 AIFB / FZI 2 II. Datenbereitstellung Collect Initial Data identify relevant attributes identify inconsistencies between sources

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement 1 Übersicht - Datenmanagement 1 Übersicht - Datenmanagement...1 2 Übersicht: Datenbanken - Datawarehouse...2 3 Übersicht: Data Mining...11

Mehr

Informa(onssysteme Übersicht Sommersemester 2015

Informa(onssysteme Übersicht Sommersemester 2015 Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Zi. 36/329, Tel.: 0631-205-3275 E-Mail: dessloch@cs.uni-kl.de Informa(onssysteme Übersicht Sommersemester 2015 h8p://wwwlgis.informa(k.uni-

Mehr

Suchmaschinen und ihre Architektur. Seminar: Angewandtes Information Retrieval Referat von Michael Wirz

Suchmaschinen und ihre Architektur. Seminar: Angewandtes Information Retrieval Referat von Michael Wirz Suchmaschinen und ihre Architektur Seminar: Angewandtes Information Retrieval Referat von Michael Wirz Ziel Rudimentäre Grundkenntnisse über die Funktionsweise von Suchmaschinen und Trends Einführung in

Mehr

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1)

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Herbstsemester 2013/14 Prof. S. Keller Informatik HSR Januar 2014, HS13/14 Dbs1 - Prüfungsvorbereitung 1 Dbs1 Ziele Grundlagenwissen in folgenden Gebieten

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Gliederung und Einordnung

Gliederung und Einordnung Gliederung und Einordnung 1. Objektorientierte Programmierung mit Object Pascal (5. Studienbrief, Kapitel 5) 9.4. + 16.4. 2. Software-Bausteine am Beispiel der Delphi-Komponenten (5. Studienbrief, Kapitel

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

MultiProvider. Logische Reporting- Schicht. Abb. 9 21 Einsatz von MultiProvidern als logische Reporting- Schicht

MultiProvider. Logische Reporting- Schicht. Abb. 9 21 Einsatz von MultiProvidern als logische Reporting- Schicht MultiProvider 243 MultiProvider MultiProvider sind virtuelle InfoProvider ohne eigene Datenhaltung, deren Hauptaufgabe die Grundlage für die Datenanalyse und -planung ist. Dabei nimmt der MultiProvider

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Datenintegration. Kapitel 1: Einführung. Michael Hartung in Vertretung von Dr. Andreas Thor Wintersemester 2010/11

Datenintegration. Kapitel 1: Einführung. Michael Hartung in Vertretung von Dr. Andreas Thor Wintersemester 2010/11 Datenintegration Datenintegration Kapitel 1: Einführung Michael Hartung in Vertretung von Dr. Andreas Thor Wintersemester 2010/11 Universität Leipzig Institut für Informatik http://dbs.uni-leipzig.de 1

Mehr

Umsetzung der Anforderungen - analytisch

Umsetzung der Anforderungen - analytisch Umsetzung der Anforderungen - analytisch Titel des Lernmoduls: Umsetzung der Anforderungen - analytisch Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.5.5 Zum Inhalt: In diesem Modul wird

Mehr

imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen

imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen imc SEARCH auf einen Blick Zentrale Ablage und Verwaltung von Mess- und

Mehr

ISA 2004 Netzwerkerstellung von Marc Grote

ISA 2004 Netzwerkerstellung von Marc Grote Seite 1 von 7 ISA Server 2004 Mehrfachnetzwerke - Besonderheiten - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung In meinem ersten Artikel habe

Mehr

imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen

imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen imc SEARCH gezielt suchen intelligent filtern schnell auswerten Zentrale Messdatenverwaltung und -organisation imc produktiv messen www.imc-berlin.de/search imc SEARCH auf einen Blick Zentrale Ablage und

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. Einleitung / Entity-Relationship

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

Professionelles CMS mit ZOPE und ZMS. Niels Dettenbach - www.syndicat.com. Content Management mit ZMS

Professionelles CMS mit ZOPE und ZMS. Niels Dettenbach - www.syndicat.com. Content Management mit ZMS Professionelles CMS mit ZOPE und ZMS Niels Dettenbach - www.syndicat.com Content Management mit ZMS Was ist professionelles CMS? (1/2) strikte Trennung von Inhalt (Content) und Layout / Design hält sich

Mehr

Kapitel 1 Überblick Content Management und Digitale Bibliotheken

Kapitel 1 Überblick Content Management und Digitale Bibliotheken Kapitel 1 Überblick Content Management und Digitale Bibliotheken Prof. Dr.-Ing. Stefan Deßloch Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de 1 Überblick Was ist Content? Daten, Dokumente,

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-2 Bioinformatik:

Mehr

Web Data Management Systeme

Web Data Management Systeme Web Data Management Systeme Seminar: Web-Qualitätsmanagement Arne Frenkel Agenda Einführung Suchsysteme Suchmaschinen & Meta-Suchmaschinen W3QS WebSQL WebLog Information Integration Systems Ariadne TSIMMIS

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

Vorwort. Zu dieser Reihe. Autoren. Vorwort

Vorwort. Zu dieser Reihe. Autoren. Vorwort Vorwort 9 10 Vorwort Vorwort Herzlich Willkommen zu einem Fachbuch von Comelio Medien, ein Bereich der Comelio GmbH. Dieses Buch aus unserer Reihe zur.net-entwicklung ist das Ergebnis einer Forschungsarbeit,

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

Realisierung eines föderierten Datenbanksystems auf Basis der Standards CORBA und ODMG-93

Realisierung eines föderierten Datenbanksystems auf Basis der Standards CORBA und ODMG-93 Realisierung eines föderierten Datenbanksystems auf Basis der Standards CORBA und ODMG-93 S. Sander und W. Hasselbring Universität Dortmund, Informatik 10 (Software-Technologie), D-44221 Dortmund E-mail:

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Kapitel 3: Datenbanksysteme

Kapitel 3: Datenbanksysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2009 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH Einführung in OLAP und Business Analysis Gunther Popp dc soft GmbH Überblick Wozu Business Analysis mit OLAP? OLAP Grundlagen Endlich... Technischer Background Microsoft SQL 7 & OLAP Services Folie 2 -

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Servicebasierte Datenintegration

Servicebasierte Datenintegration Präsentation zur Seminararbeit Christoph Aßmann Aßmann, Christoph Leipzig, 26.01.2010 Folie 1 Inhalt Begriffe Motivation Abgrenzung Grid Cloud OGSA: Architektur servicebasierter Grids Standardisierung

Mehr

Themen. M. Duffner: Datenbanksysteme

Themen. M. Duffner: Datenbanksysteme Datenbanksysteme Themen Theorie Einführung Datenbank, Datenbankmanagementsystem (DBMS), Aufgaben eines DBMS Relationale Datenbanken Daten als Tabellen Datenbankentwurf im Entity-Relationship-Modell Abfragesprache

Mehr

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 MIS Glossar by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 Aggregat Data Cube Data Marts Data Mining Data Warehouse (DWH) Daten Decision Support Systeme (DSS)

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Inhaltsverzeichnis Überblick... 3 Die QlikView Applikation im Kontext... 4 Technische Rahmenbedinungen... 5 Funktionelle

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008 Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Andreas Glaser, 23. September 2008 Teufenerstrasse 19 CH 9001 St.Gallen t [+41] 71 228 67 77 f [+41] 71 228 67 88 info@namics.com

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Kapitel 3: Datenbanksysteme

Kapitel 3: Datenbanksysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2013 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

e-procurement ein Trend wird erwachsen

e-procurement ein Trend wird erwachsen e-procurement ein Trend wird erwachsen Prof. Dr. Thomas Allweyer Folge 3: Auswahl von e-procurement-anbietern & Handlungsempfehlungen Inhalt e-procurement: Erwartungen und Erfahrungen... 02 Potenzial des

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Vorlesung Datenbankmanagementsysteme

Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme Grundlagen Vorlesung Datenbankmanagementsysteme Grundlagen M. Lange, S. Weise Folie #1-1 Ausgangspunkt Informationen in vielen Bereichen nicht elektronisch erfasst

Mehr

Objektrelationale, erweiterbare Datenbanken

Objektrelationale, erweiterbare Datenbanken Objektrelationale, erweiterbare Datenbanken Wintersemester 2003/2004 Vorlesung: Mittwoch, 15:15-17:00 Uhr IFW A32 Übung: Mittwoch, 17:15-18:00 Uhr IFW A32 Dozent: Dr. Can Türker IFW C47.2 Email: WWW: tuerker@inf.ethz.ch

Mehr

Einführung Datenbank

Einführung Datenbank Einführung Datenbank Einführung Datenbank Seite 2 Einführung in die Arbeit mit einer Datenbank Grundbegriffe: Datenbank - Datenbankmanagementsystem Eine Datenbank ist eine systematische strukturierte Sammlung

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence SS 2014 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 07.05.2014 Business Intelligence Praktikum

Mehr

Information Workbench Linked Data-Anwendungen im Unternehmen. Leipziger Semantic Web Tag, 5.5.2011 Peter Haase, fluid Operations

Information Workbench Linked Data-Anwendungen im Unternehmen. Leipziger Semantic Web Tag, 5.5.2011 Peter Haase, fluid Operations Information Workbench Linked Data-Anwendungen im Unternehmen Leipziger Semantic Web Tag, 5.5.2011 Peter Haase, fluid Operations Agenda Linked Data im Unternehmen Herausforderungen Die Information Workbench

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr