Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung

Größe: px
Ab Seite anzeigen:

Download "Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung"

Transkript

1 Seminar 1912 Sommersemester 2005 Lehrgebiet Datenbanksysteme für neue Anwendungen Prof. Dr. Ralf Hartmut Güting Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung 10. The Tukwila Data-Integration-System Jan Engelkamp

2 10. The Tukwila Data Integration System (Jan Engelkamp) 2 Inhaltsverzeichnis 1. Data-Integration-Systems 3 2. Die Ziele des Tukwila-Systems 4 3. Wichtige Komponenten des Tukwila-Systems 5 4. Adaptive Techniken im Tukwila-System Fragmente und Materialisierungspunkte Die Event-Condition-Action-Regeln Dynamische Datenkollektoren Der Double-Pipelined-Hash-Join Adaptive Data-Partitioning Arten des Adaptive Data-Partitioning Adaptive Data-Partitioning im Tukwila-System Zusammenfassung und Diskussion 14 Literaturverzeichnis 15

3 10. The Tukwila Data Integration System (Jan Engelkamp) 3 1. Data-Integration-Systems Der Begriff Data-Integration-System 1 bezeichnet solche Systeme, die es Anwendungsprogrammen und Benutzern ermöglichen, in einheitlicher Art und Weise Anfragen an eine Menge heterogener und über ein Netzwerk verteilter Datenquellen zu stellen [7]. Derartige Systeme bilden somit eine einheitliche Schnittstelle für den Zugriff auf Datenquellen unterschiedlicher Art und Strukturierung. Und gerade darin liegt ihr zentraler Nutzen: Anwendungsprogramme und Benutzer eines Data-Integration-System 2 brauchen die letztendlich verwendeten Datenquellen, ihre Speicherorte und Spezifika nicht zu kennen. Sie müssen sich in keiner Weise darum kümmern, wie Anfragen, die innerhalb ihrer spezifischen Benutzersicht an die Datenbasis gestellt werden, auf die tatsächlichen Strukturen der konkreten Datenquellen abgebildet werden, oder darum, wie umgekehrt die Abbildung von Anfrageergebnissen auf die jeweilige Benutzersicht erfolgt. Und sie können sich darauf verlassen, dass die verschiedenen Datenquellen gemeinsam ausgewertet und Zwischen-, sowie Endergebnisse geeignet miteinander verbunden und kombiniert werden [4, S. 299]. Insbesondere jedoch dann, wenn die Datenquellen über ein WAN (Wide-Area-Network, Weitverkehrsnetz) und nicht über vergleichsweise sichere und schnelle Datenleitungen eines lokalen Netzwerks erreichbar sind, schlägt sich dies in zahlreichen Aspekten nieder, die teils direkte, teils indirekte Auswirkungen auf den Datenzugriff und die Anfrageverarbeitung haben. Dies gilt speziell für Datenbanken, auf die über das Internet respektive das World-Wide-Web zugegriffen wird. Auf einzelne Aspekte wird im folgenden noch näher einzugehen sein, zentrale Lösungsansätze stehen im Zentrum der vorliegenden Arbeit. Doch zunächst werden in Form eines kurzen Überblicks einige wichtige Herausforderungen, die sich für ein Data-Integration- System ergeben, vorgestellt: Aus der Tatsache, dass die Datenbasis aus autonomen und heterogenen Datenquellen besteht, die in einem WAN verteilt sind bzw. zumindest sein können, folgt, dass ein Data-Integration-System mit großen und unvorhersehbaren Verzögerungen, die ggf. beim Datentransport auftreten, umgehen können muss. Grundsätzlich sind hohe I/O-Kosten (Kosten für den Input und Output von Daten, für das Lesen von Daten aus und das Schreiben in Datenquellen) anzunehmen [4, S. 299; 5, S. 20]. Des weiteren kann kein wahlfreier Zugriff auf einzelne Datensätze vorausgesetzt werden, da Daten über ein Netzwerk und ggf. zahlreiche Netzwerkknoten transportiert werden. Größere Datenmengen treffen als Datenstrom beim Data-Integration-System ein [5, S. 20]. Um die Systemeffizienz zu erhöhen, bietet es sich an, an unterschiedlichen Stellen im System Daten-Caches (temporäre Zwischenspeicher) vorzusehen, sowie einmal bereits berechnete Zwischenergebnisse mehrfach zu verwenden sei es innerhalb ein und derselben Anfrage, oder in anderen, nachfolgenden Anfragen. Caching-Strategien müssen stets jedoch berücksichtigen, dass die einzelnen Datenquellen einer verteilten Datenbasis autonom sind in dem Sinne, dass sie von Benutzern und Anwendungsprogrammen verwendet werden können, welche nicht mit Hilfe des Data-Integration-System, sondern unabhängig davon darauf zugreifen und die gespeicherten Daten ändern. Benutzer eines Data-Integration-System haben prinzipiell jedoch den Anspruch, 1 Fachbegriffe insbesondere englische werden bei ihrer erstmaligen Nennung in Anführungsstriche gesetzt. Im Weiteren werden sie dann ohne besondere Hervorhebungen verwandt. In Überschriften entfallen Anführungsstriche. 2 Da es sich bei Data-Integration-System um einen englischsprachigen Begriff handelt, wird hier wie im folgenden kein s im Genitiv Singular angehängt. Ebenso wird im Nominativ Plural anstelle des deutschen Suffixes en die englische Pluralendung s verwandt. Gleiches gilt für andere englischsprachige Begriffe wie z.b. Wrapper.

4 10. The Tukwila Data Integration System (Jan Engelkamp) 4 dass zur Beantwortung ihrer Anfragen stets möglichst aktuelle Daten ausgewertet werden und niemals veraltete [5, S. 20]. Die Ansprüche der Benutzer eines Systems an die Qualität, Korrektheit und Vollständigkeit von Anfrageergebnissen bzw. an die Systemperformance sind bei Data-Integration-Systems nicht geringer, als bei klassischen, homogen strukturierten und nicht-verteilten Datenbanksystemen. Die Systemperformance gewinnt insbesondere in solchen Anwendungszusammenhängen an Bedeutung, die einen hohen interaktiven Charakter haben, sowie dort, wo viele und ggf. heterogene Anfragen von unterschiedlichen Benutzern parallel gestellt und vom System ausgewertet werden. Häufig ist es aus Benutzersicht interessanter, sehr schnell eine erste, vorläufige und evtl. unvollständige Antwort zu erhalten, als lange auf das vollständige Anfrageergebnis warten zu müssen [4, S. 300; 5, S. 19, 21, 24, 25]. Man denke etwa an eine integrierte Suche nach freien Hotelzimmern in einer bestimmten Stadt und innerhalb eines bestimmten Zeitraums über eine Menge vernetzter, aber unabhängiger und insbesondere unterschiedlich schnell antwortender Buchungssysteme hinweg. Eine weitere Herausforderung an Data-Integration-Systems ergibt sich wiederum aus der Tatsache, dass die Datenbasis aus autonomen und heterogenen Datenquellen besteht: Ein solches System kann sich weniger als ein konventionelles Datenbankmanagementsystem auf selbst erstellte respektive zu einer Datenquelle gespeicherte Metadaten verlassen, wie etwa Selektivitäten von Joins, Kardinalitäten von Relationen und Zwischenergebnissen und die Werteverteilung innerhalb einer Relation. Zudem ist grundsätzlich davon auszugehen, dass sich einzelne Datenquellen inhaltlich überschneiden, Daten also redundant gespeichert werden [4, S ]. 2. Die Ziele des Tukwila-Systems Das Data-Integration-System Tukwila wurde an der Universität von Washington entworfen. Es wird kontinuierlich im Rahmen von Forschungsarbeiten und -projekten weiterentwickelt und ergänzt [5, S. 20]. Sein Name verweist auf eine nach Ansicht der Tukwila-Projektleiter malerische Kleinstadt in der Nähe von Seattle im Nordwesten der Vereinigten Staaten von Amerika [4, S. 300]. Ein aus Benutzersicht zentrales Element des Tukwila-Systems ist ein sogenanntes Mediated Schema, eine Tukwila-eigene relationale Zwischendarstellung der Datenbasis, in welcher Benutzeranfragen formuliert und auf die autonome Datenquellen und ihre Inhalte abgebildet werden. (In neueren Versionen wird statt einer relationalen Zwischendarstellung XML verwandt; darauf wird später noch kurz einzugehen sein.) Anfragen an die Datenbasis werden systemintern in Anfragen an die zur Datenbasis gehörigen, heterogenen Datenquellen überführt, ihre Rückmeldungen verarbeitet und zu einem Gesamtergebnis kombiniert [4, S. 301; 5, S. 20; 7]. Dabei kommen zahlreiche adaptive Techniken und Strategien zur Anwendung. Ein entscheidender Ansatz ist die Verzahnung von Auswertungsplanerzeugung und -ausführung. Es wird nicht wie in klassischen Datenbankmanagementsystemen in einem in sich abgeschlossenen Prozess ein vollständiger Auswertungsplan erzeugt und optimiert, welcher dann zur Ausführung gebracht, also auf die Datenbasis angewendet wird. Stattdessen wird zunächst nur ein Teil des Auswertungsplans ausgeführt, um später anhand eines bereits vorliegenden Teilergebnisses und eventuell zwischenzeitlich eingetretener Ereignisse zu entscheiden, wie weiter zu verfahren ist. Die Anfrageoptimierung wird somit zu einem mehrstufigen Prozess mit einer beständigen Reoptimierung und Anpassung nachfolgender Auswertungsschritte zur Ausführungszeit. Auf diesen Aspekt wird noch genauer einzugehen sein. Entscheidungen die

5 10. The Tukwila Data Integration System (Jan Engelkamp) 5 weitere Auswertungsplanausführung betreffend werden auf der Basis von ebenfalls noch eingehender zu diskutierenden Event-Condition-Action-Regeln getroffen (Ereignis- Bedingung-Handlung-Regeln), wobei mögliche Events (Ereignisse) z.b. ein Mangel an Speicher oder ein Ausbleiben von Daten aus einer bestimmten Datenquelle sein können [4, S. 300]. Adaptivität wird des weiteren realisiert in Form von adaptiven Operatoren: Im Folgenden werden der Double-Pipelined-Hash-Join sowie dynamische Datenkollektoren vorgestellt. Letztere dienen dazu, Ausführungsteilergebnisse aus einer großen Anzahl autonomer und sich inhaltlich zumindest potentiell überschneidender Datenquellen zusammenzufassen [4, S. 300]. Mit Hilfe der systemeigenen Zwischendarstellung der Datenquelleninhalte (Mediated Schema), sowie adaptiver Techniken und Strategien erreicht Tukwila es, eine effiziente Integration autonomer Datenquellen in eine gemeinsame Datenbasis zu realisieren, sowie eine effiziente Anfrageausführung auch in solchen Fällen, in denen nur wenige verlässliche Informationen (Metadaten) über die Datenquellen und ihre Inhalte vorliegen. Des weiteren wird die Geschwindigkeit der Anfrageausführung zumindest aus Benutzersicht dadurch erhöht, dass dann, und nur dann, wenn dies im Anwendungszusammenhang sinnvoll erscheint (siehe das o.g. Hotelzimmerbeispiel), Ergebnisse zunächst unvollständig angezeigt und später nach und nach ergänzt werden. So können etwa langsam antwortende Datenquellen zunächst ignoriert werden. Ein anderer Ansatz ist, erste Anfrageergebnisse ausschließlich mit Hilfe initialer, ggf. zentral zwischengespeicherter, aber potentiell veralteter Daten zu generieren, um sie später mit Hilfe aktueller Daten aus entfernten Datenquellen zu korrigieren. Man spricht in diesem Zusammenhang von Ergebnis-Updates [5, S. 21, 25]. 3. Wichtige Komponenten des Tukwila-Systems Wie oben bereits angesprochen, ist ein Element von Tukwila das sogenannte Mediated Schema, eine systemeigene Zwischendarstellung der Datenbasis, in der Anfragen an das System gestellt und Ergebnisse ausgegeben werden. Sämtliche zur Verfügung stehenden Informationen über die Datenquellen und ihre Inhalte, die für einen effizienten Datenzugriff relevant sind respektive sein können, sind in einem sogenannten Datenquellenkatalog verzeichnet. Dazu gehören statistische Informationen über das Antwortverhalten und insbesondere die Antwortgeschwindigkeit der einzelnen Datenquellen, aber auch, wie oben bereits angesprochen, Informationen zu den Kardinalitäten von Relationen und der Werteverteilung innerhalb von Relationen. Der Datenquellenkatalog enthält auch Informationen darüber, inwieweit sich die Inhalte von Datenquellen überschneiden (overlap-information). Beachtenswert ist, dass es auch dann sinnvoll ist, verschiedene Datenquellen in diesem Katalog zu verzeichnen, wenn sie exakte Kopien voneinander darstellen. Es könnte schließlich sein, dass sich Situationen ergeben, in denen eine oder mehrere Quellen nicht erreichbar sind [4, S. 301]. Eine Anfrage von einem Benutzer oder Anwendungsprogramm wird zunächst von einer Anfragen-Neuformulierungs-Komponente (query reformulation component) entgegengenommen und in eine Menge Einzelanfragen überführt, die sich jeweils auf eine im Datenquellenkatalog verzeichnete Datenquelle beziehen. Diese Einzelanfragen werden weitergereicht an den Anfragenoptimierer des Systems (query optimizer), welcher jede der Anfragen in je einen optimierten Auswertungsplan übersetzt, um mit diesem sodann die Ausführungskomponente (query execution engine) aufzurufen. Der Anfragenoptimierer erzeugt wie oben beschrieben nicht zwangsläufig vollständige Auswertungspläne, sondern dann, wenn dies aufgrund etwa fehlender Metadaten zu den Inhalten einer Datenquelle oder potentieller Unsicherheiten z.b. die Erreichbarkeit einer Datenquelle betreffend sinnvoll erscheint, lediglich Teile davon.

6 10. The Tukwila Data Integration System (Jan Engelkamp) 6 Gleichzeitig erzeugt er auch einen Satz von Regeln (Event-Condition-Action-Regeln), um festzulegen, wann und wie der Auswertungsplan ggf. zu modifizieren ist [4, S. 301; 7]. In der ursprünglichen Konzeption des Tukwila-Systems wurden der Kommunikation von Ausführungskomponente und tatsächlicher Datenquelle sogenannte Wrappers zwischengeschaltet. (Dieses englische Wort lässt sich wohl am ehesten übersetzen mit Schutzumschlag, Verpackung, Deckblatt oder Ummantelung.) Wrappers übertragen die im Tukwila-System verwendeten Datenformate in datenquellenspezifische Datenformate und umgekehrt. Dabei ist es konzeptionell unerheblich, ob man sie als Schnittstelle von Tukwila zu den Datenquellen oder als Schnittstelle der Datenquellen zu Tukwila begreift und an welcher Stelle in einem verteilten System sie letztendlich zur Ausführung gelangen [4, S. 301; 5, S. 23]. Mit der Verbreitung von XML (extensible Markup Language) und der damit einhergehenden Entwicklung, dass in den meisten modernen Datenbanken ein Export nach XML realisiert werden kann, verliert das Wrapper-Konzept an Bedeutung. Auch für andere (strukturierte) Datenquellen existieren Werkzeuge zur Überführung der Inhalte in XML, etwa solche, die HTML-Seiten in XML- Dokumente überführen [5, S. 23]. Nachdem Tukwila so ausgelegt wurde, dass von einer Datenbasis bestehend aus XML- Datenquellen ausgegangen wird, war der nächste (naheliegende) Schritt zur Optimierung des Systems der Verzicht auf eine Überführung der Datenquelleninhalte in ein Tukwila-internes relationales Schema. Stattdessen wurde Tukwila zu einem XML Data-Integration-System mit speziellen Operatoren für XML-strukturierte Daten. Inhalte relationaler Datenquellen werden nun nach XML überführt [5, S. 23; 7]. Bei der Tukwila-Implementierung wird soweit es möglicht ist auf verbreitete Standards und Programmiersprachen zurückgegriffen [4, S. 306]. Abbildung 1: wichtige Tukwila-Komponenten [vgl. 4, S. 302; 7]

7 10. The Tukwila Data Integration System (Jan Engelkamp) 7 4. Adaptive Techniken im Tukwila-System Ursprünglich verfolgte die Entwicklung von Tukwila das Ziel, vier Arten von Adaptivität zu realisieren, bei denen (a) die Reihenfolge von Operatoren innerhalb von Auswertungsplänen zur Ausführungszeit umgestellt wird (Scheduling-Based-Methods), (b) aus alternativen Auswertungsplänen zur Laufzeit ein bester ausgewählt wird (Redundant-Computation- Methods), (c) Auswertungspläne nicht ein geschlossenes Ganzes bilden, sondern zur Ausführungszeit modifizierbar sind (Plan-Partitioning-Methods), und (d) nicht alle Daten zwangsläufig über ein und denselben Auswertungsplan verarbeitet werden müssen, sondern zur Ausführungszeit entschieden wird, welche Daten wie verarbeitet werden (Data-Partitioning- Methods) [6, S. 396]. Neuere Entwicklungen hingegen versuchen, unterschiedliche Techniken und Strategien unter dem Begriff Adaptive Data-Partitioning zu einem einheitlichen Ansatz zu vereinen. Hierauf wird im folgenden noch einzugehen sein. Die adaptive Technik, aus mehreren alternativen Auswertungsplänen zur Laufzeit einen besten auszuwählen, stellt ein zumindest partiell redundantes Berechnungsverfahren dar, da nicht versucht wird, im Vorhinein zu ermitteln, welcher von mehreren alternativen Auswertungsplänen der effizienteste zu sein scheint. Stattdessen werden mehrere Auswertungspläne parallel gestartet und nach einer bestimmten Berechnungszeit oder zu einem festgelegten Zeitpunkt überprüft, die Abarbeitung welchen Planes am weitesten fortgeschritten ist. Dieser wird weiter ausgeführt, die Abarbeitung der übrigen abgebrochen [6, S. 396]. Wenn Auswertungspläne nicht als in sich geschlossenes Ganzes betrachtet, sondern in Abschnitte unterteilt werden, so kann nach einem jeden Abschnitt entschieden werden, wie weiter vorzugehen ist: So kann etwa einer von mehreren alternativen nachfolgenden Auswertungsplanabschnitten ausgewählt werden, oder zur Ausführungszeit wird der ursprünglich vollständig entworfene Auswertungsplan vom nachfolgenden Abschnitt an neu berechnet (re-optimiert) [6, S. 296]. Auf die Frage der Unterteilung von Auswertungsplänen in Abschnitte (Fragmente) wird im nachfolgenden Abschnitt genauer einzugehen sein Fragmente und Materialisierungspunkte Die einzelnen Abschnitte, in die ein Auswertungsplan aufgeteilt wird, heißen Fragmente. Jedes Mal, wenn ein Fragment eines Auswertungsplans vollständig abgearbeitet worden ist, wird die Ausführung unterbrochen und die bis dahin berechneten Zwischenergebnisse werden materialisiert, d.h. explizit erzeugt. Aus diesem Grunde spricht man auch von Materialisierungspunkten, die sich am Ende eines jeden Fragments befinden [4, S. 302]. Würde ein Auswertungsplan als in sich geschlossenes Ganzes optimiert, so würde in vielen Fällen auf eine Materialisierung, also eine tatsächliche Erzeugung von Zwischenergebnissen (das sind klassischerweise Relationen) verzichtet, da mehrere Operatoren ggf. effizient durch einen komplexen Operator mit identischer Funktionsweise ersetzt, d.h. mehrere Operatoren gruppiert werden könnten [10, S. 181], oder die Ausgabedaten eines Operators (klassischerweise Datensätze, Tupel) könnten direkt von einem anderen Operator als Eingabedaten gelesen werden; man spricht in diesem Falle davon, dass Ströme von zu verarbeitenden Objekten (Tupeln) einerseits produziert und andererseits eingelesen werden, also eine Stromverarbeitung stattfindet [10, S. 199]. Ein Auswertungsplan besteht aus Fragmenten plus einer Menge von Regeln, mit welchen festgelegt wird, wie nach Abarbeitung eines jeden Fragments entschieden wird, was weiter zu

8 10. The Tukwila Data Integration System (Jan Engelkamp) 8 tun ist [4, S. 302]. Auf die Regeln wird im folgenden Abschnitt genauer einzugehen sein. Ein jedes Fragment besteht aus einem Operatorbaum, in dessen inneren Knoten sich jeweils ein algebraischer Operator (wie etwa eine Selektion, ein Join, eine Projektion, eine Vereinigung o.ä.) befindet, inkl. einer in der konkreten Anwendung sinnvollen und im Idealfall optimalen Implementierung des Operators (z.b. Index-Nested-Loop-Join, Hash-Join, Double-Pipelined- Hash-Join etc.), sowie einige Zeiger und Metainformationen [4, S. 302; 10, S. 172]. Wenn Auswertungspläne in Fragmente unterteilt werden, dann stellt sich zwangsläufig die Frage, in wie viele und wie groß die Fragmente optimalerweise sein sollten, d.h. aus wie vielen Operatoren bzw. Knoten die entsprechenden Operatorbäume für die einzelnen Fragmente bestehen sollten. Sehr viele Fragmente ziehen sehr viele Materialisierungspunkte nach sich, was sich negativ auf die Effizienz und Performance der Anfrageausführung auswirken kann. Nur wenige Fragmente führen zu wenigen Materialisierungspunkten, woraus folgt, dass seltener in die Anfrageausführung korrigierend eingegriffen, der potentielle Nutzen dieses adaptiven Ansatzes somit herabgesetzt wird [5, S. 24]. Des weiteren ist entscheidend, wann ein Fragment endet und ein neues beginnt, an welcher Stelle des Auswertungsplans also eine Materialisierung von Zwischenergebnissen erfolgt. Oben wurde bereits die Stromverarbeitung angesprochen, sowie die Gruppierung von Operatoren. Es ist offensichtlich, dass es Operatoren gibt, bei denen sich eine Gruppierung anbietet (z.b. die Sortierung einer Relation und eine nachfolgende Projektion mit Duplikateliminierung, oder der Join zweier Relationen und eine nachfolgende Projektion). Zwischen solchen Operatoren sollte demnach grundsätzlich keine Materialisierung erfolgen [5, S. 24; 10, S. 181]. Im Tukwila-System werden Materialisierungspunke zudem auch adaptiv festgelegt, also während der Ausführungszeit. Insbesondere, wenn ein Mangel an Hauptspeicherplatz auftritt oder droht, ist es sinnvoll, Zwischenergebnisse zu materialisieren und auf Externspeicher auszulagern [5, S. 24] Die Event-Condition-Action-Regeln Die Regeln, die am Ende eines jeden Fragments zur Ausführung kommen, bilden einen Schlüsselmechanismus der adaptiven Ansätze im Tukwila-System. So wird etwa von der Ausführungskomponente überprüft, ob die zuvor vom Anfragenoptimierer geschätzten Kardinalitäten mit den tatsächlichen Kardinalitäten der materialisierten Zwischenergebnisse übereinstimmen oder ob signifikante Abweichungen festzustellen sind. Es wird auch überprüft, ob die Datenquellen, auf die im nachfolgenden Fragment zugegriffen werden soll, erreichbar sind und ein Zugriff darauf möglich ist [4, S. 302; 5, S. 22]. Von ihrer äußeren Form her sind die Regeln recht einfach; sie lauten: Wenn ein Ereignis stattgefunden hat und falls eine Bedingung erfüllt ist, dann sind bestimmte Handlungen auszuführen (when event if condition then actions). Aus dem strukturellen Aufbau dieser Regeln leitet sich auch ihre Bezeichnung ab: Event-Condition-Action-Regeln (Ereignis- Bedingung-Handlung-Regeln). Ein einfaches Beispiel ist: Wenn Fragment F i beendet wurde und die Kardinalität des Zwischenergebnisses K Z größer ist als ein Faktor c mal die geschätzte Kardinalität des Zwischenergebnisses K gz, dann ist der Auswertungsplan von der aktuellen Position an neu zu berechnen. [vgl. 4, S. 302] Das typische Ereignis, das zur Überprüfung einer Bedingung führt, ist die Beendigung eines Fragments. Ereignisse stellen aber auch Fehlersituationen dar, oder das Ausbleiben von Daten aus einer Datenquelle, ein Hauptspeichermangel oder die Tatsache, dass ein Operator mehr Ergebnistupel produziert hat als eine festgelegte maximale Anzahl. Bedingungen, die nach Eintreten eines Ereignisses überprüft werden, sind z.b. die Kardinalität eines bestimmten, soeben

9 10. The Tukwila Data Integration System (Jan Engelkamp) 9 erzeugten Zwischenergebnisses, die seit einem festgelegten Zeitpunkt verstrichene Zeit, die Menge an noch verfügbarem Speicherplatz, die Geschwindigkeit, mit der eine Datenquelle Daten liefert o.ä. Von den Ereignissen und den Ergebnissen der Bedingungsüberprüfung hängt es ab, welche Handlungen nunmehr ausgeführt werden: Der gesamte Auswertungsplan von der aktuellen Position an wird ggf. neu berechnet; ein zum eigentlich vorgesehen nachfolgenden Fragment alternatives Fragment wird ausgeführt; parallel ausführbare Operatoren werden in einer anderen Reihenfolge als ursprünglich vorgesehen ausgeführt; statt einer ursprünglich vorgesehenen Implementierung eines Operators kommt eine andere Implementierung zur Ausführung; eine andere Datenquelle als zunächst vorgesehen wird verwendet etc. Es kann sogar sein, dass die Entscheidung getroffen wird, die aktuelle Berechnung mit einer Fehlermeldung abzubrechen [4, S 302; 5, S. 22]. Wie oben bereits angesprochen, besteht bei Tukwila ein Auswertungsplan aus zweierlei, aus den Fragmenten, die der Anfragenoptimierer der Ausführungskomponente zuführt, einerseits und aus Event-Condition-Action-Regeln andererseits. Diese Regeln übergibt der Anfragenoptimierer einer bislang noch nicht vorgestellten Systemkomponente: dem Event-Handler. Falls während der Anfrageausführung ein Ereignis (Event) eintritt, ruft die Ausführungskomponente dann unmittelbar diesen Event-Handler auf, welcher die Regeln ausführt und somit wie oben beschrieben die Entscheidung darüber trifft, welche Handlungen nunmehr auszuführen sind [4, S. 303] Dynamische Datenkollektoren Ein anderer als die bisher vorgestellten Ansätze zur Realisierung von Adaptivität im Tukwila- System ist die Verwendung spezieller adaptiver Operatoren. Der Double-Pipelined-Hash-Join, welcher im folgenden Abschnitt vorgestellt wird, und dynamische Datenkollektoren stellen solche adaptiven Operatoren dar. Sie reagieren auf Veränderungen in den Eigenschaften des Netzwerks, über welches Daten aus entfernten Datenquellen zwangsläufig transportiert werden müssen [5, S. 22]. Dynamische Datenkollektoren sind in solchen Fällen verwendbar, in denen sich die Datenquellen der Datenbasis teilweise inhaltlich überlappen oder einige Datenquellen vollständige Replikate anderer darstellen. Zusätzlich muss der Anfragenoptimierer Zugriff auf zumindest geschätzte Informationen darüber haben, inwieweit sich die Inhalte der Datenquellen überschneiden (overlap-information). Wie oben beschrieben, greift er dazu auf den Datenquellenkatalog des Tukwila-Systems zurück. Eine weitere Voraussetzung, die erfüllt sein muss, ist, dass der Anfragenoptimierer eine Reihenfolge festlegen kann, in der redundante Datenquellen angesprochen werden. Diese Reihenfolge kann aufgrund des Antwortverhaltens einer jeden Datenquelle festgelegt werden, oder aufgrund für den konkreten Fall speziell zu definierenden Kosten, die jede der in Frage kommenden Datenquellen verursacht. Zunächst muss also jede Datenquelle mindestens einmal kontaktiert und ihr Antwortverhalten beobachtet und protokolliert werden. Letztendlich führen die so ermittelten Informationen zur Aufstellung einer Menge von Event-Condition-Action-Regeln, wie sie im vorangegangenen Kapitel beschrieben wurden. Dynamische Datenkollektoren ergeben sich somit als Zusammenfassung von Methoden zum Zugriff auf in Frage kommende Datenquellen und einer Menge von Event- Condition-Action-Regeln [4, S. 303].

10 10. The Tukwila Data Integration System (Jan Engelkamp) Der Double-Pipelined-Hash-Join Der Join ist eine der am häufigsten benutzten relationalen Operationen, gleichzeitig aber auch eine der teuersten. Aus diesem Grunde existieren zahlreiche Implementierungen (wie der Nested-Loop-Join, der Sort-Merge-Join, der Hash-Join uvm.), und die Entscheidung darüber, welche der Implementierungen konkret zu verwenden ist, kann i.d.r. nur für die jeweilige Situation und abhängig von mehreren Faktoren getroffen werden. Einer der wichtigsten dieser Faktoren ist die Frage, in welcher Form die im Rahmen eines Join zu verknüpfenden Relationen vorliegen (sortiert, unsortiert; mit Index, ohne Index etc.). So ist etwa der einfache Hash-Join besonders für solche Fälle geeignet, in denen zwei zu verknüpfende Relationen unterschiedlich groß sind und die kleinere von beiden in einem ersten Arbeitsschritt effizient und vollständig in den Hauptspeicher eingelesen werden kann [10, S. 190ff]. Es ist unmittelbar ersichtlich, dass dieser einfache Hash-Join keine gute Join-Implementierung für ein Data-Integration-System wie Tukwila darstellt. Denn erstens muss eine sichere Entscheidung darüber getroffen werden können, welche von zwei Relationen die kleinere ist. Tukwila müsste sich also in jedem Falle vollständig auf die Größenangaben der Datenquellen verlassen können; dies wird umso wichtiger, wenn entschieden werden muss, ob die kleinere Relation tatsächlich in den Hauptspeicher passt und also die Standardimplementierung des Hash-Join verwandt werden kann, oder ob die Relation vielleicht gerade eben nicht mehr in den Hauptspeicher passt; dann müsste nämlich zunächst eine Partitionierung erfolgen. Zweitens wäre der einfache Hash-Join in dem Moment keine gute Implementierung, in dem sich herausstellt, dass die Datenquelle, die die kleinere Relation liefert, die schlechteren Antwortzeiten hat. Und drittens müssen die zu verknüpfenden Relationen nacheinander eingelesen werden, und die kleinere zunächst vollständig. Dies aber ist in Hinblick auf die Verzögerungen, die beim Transport der Daten über ein Netzwerk entstehen können, nicht sinnvoll; besser wäre es, wenn Verzögerungen beim Zugriff auf Datenquelle A dadurch überdeckt werden könnten, dass unmittelbar auf Datenquelle B umgeschaltet wird. Ein paralleles Einlesen aus beiden Datenquellen ist also wünschenswert. Daraus leitet sich ein vierter Punkt ab: Der einfache Hash- Join liefert erst mit einer gewissen Verzögerung erste Ergebnisse (verknüpfte Tupel), in vielen Anwendungen wird jedoch gewünscht, dass möglichst schnell ein erster Ergebnisoutput erfolgt [4, S. 304; 10, S. 192f]. Eine speziell für Data-Integration-Systems entwickelte und in Tukwila verwandte Join- Implementierung stellt der Double-Pipelined-Hash-Join dar. Auf seine Implementierung soll an dieser Stelle nicht genauer eingegangen werden (vgl. dazu 4, S. 304f), stattdessen werden einige besondere Eigenschaften dieses adaptiven Operators kurz aufgezählt: Die Zeit, die das System benötigt, um erste Ergebnisse (verknüpfte Tupel) zu liefern, ist minimal. Zu jedem Zeitpunkt t werden alle Ergebnistupel, die mit Hilfe der bis dahin eingelesenen Daten berechnet werden können, unmittelbar berechnet und auch ausgegeben. Es muss des weiteren keine Entscheidung darüber getroffen werden, welche Relation kleiner ist als die andere respektive zuerst eingelesen werden soll o.ä. Die zu verknüpfenden Relationen werden symmetrisch verarbeitet. Sobald sich das Antwortverhalten einer Datenquelle verschlechtert, wird dies dadurch kompensiert, dass mehr Daten respektive schneller aus der jeweils anderen gelesen wird (sofern man davon ausgeht, dass zwei Relationen miteinander verknüpft werden, die je aus einer anderen Datenquelle stammen) [4, S. 304; 5, S. 22]. Bei experimentellen Messungen am Tukwila-System hat sich bestätigt, dass der Double- Pipelined-Hash-Join eine der besten Implementierungen im gegebenen Zusammenhang darstellt [4, S. 306].

11 10. The Tukwila Data Integration System (Jan Engelkamp) Adaptive Data-Partitioning Nach Ansicht der Entwickler des Tukwila-Systems stellen die zahlreichen adaptiven Techniken und Strategien, die in Data-Integration-Systems und auch im Tukwila-System zur Anwendung kommen, in ihrer Gesamtheit betrachtet ein unverbundenes Sammelsurium von Lösungsansätzen dar, die jeweils an einem konkreten Problem ansetzen (z.b. Verzögerungen beim Datentransport oder unsicheren Kardinalitätsschätzungen). Ein einheitlicher theoretischer Überbau, eine methodologische Zusammenfassung dieser Techniken fehlte lange Zeit. Aus diesem Grunde wird ein solcher umfassender Ansatz unter dem Begriff Adaptive Data-Partitioning von den Entwicklern des Tukwila-Systems entworfen, das Gesamtproblem der adaptiven Anfrageausführung in Data-Integration-Systems formalisiert sowie in Problemklassen unterteilt und eine Umsetzung dieses Ansatzes in eine konkrete Implementierung im Rahmen des Tukwila-Systems vorgenommen [6, S. 395]. Kerngedanke des Adaptive Data-Partitioning ist es, bei der Anfrageausführung dynamisch auf mehrere unterschiedliche Auswertungspläne zurückzugreifen, welche sowohl parallel als auch sequentiell nacheinander ausgeführt werden können [6, S. 396]. Einschränkend muss angemerkt werden, dass sich das Adaptive Data-Partitioning ausschließlich auf eine anfrageninterne Adaptivität (Intra-Query-Adaptivity) respektive Optimierung konzentriert und anfragenübergreifende Ansätze (Inter-Query-Adaptivity) weitgehend außen vor gelassen werden [6, S. 396]. Anfragenübergreifende Ansätze sind seit jeher auch in klassischen Datenbankmanagementsystemen zu finden. So werden etwa einmal erzeugte Auswertungspläne gemeinsam mit den ursprünglich formulierten Anfragen und dem letztendlich erzeugten Programmcode im Systemkatalog eines Datenbankmanagementsystems abgelegt, um bei einer erneuten äquivalenten (oder ähnlichen) Anfrage auf einmal bereits geleistete Arbeit zurückgreifen zu können [10, S. 199f; vgl. auch 3, S. 4] Arten des Adaptive Data-Partitioning Wurden z.b. die Kardinalitäten der im Rahmen einer Datenbankoperation zu verarbeitenden Relationen falsch abgeschätzt bzw. lieferte eine Datenquelle falsche Angaben zur Größe einer Relation, so kann dies dazu führen, dass eine Implementierung dieser Datenbankoperation für den auszuführenden Auswertungsplan gewählt wurde, die hinter der Effizienz einer alternativen Implementierung zurückbleibt. Es ist auch vorstellbar, dass ein ganz anderer Auswertungsplan aufgestellt worden wäre, hätten die korrekten Kardinalitäten zur Verfügung gestanden. Es erscheint somit u.u. sinnvoll, einen bereits zur Ausführung gebrachten Auswertungsplan abzubrechen, sobald die ihm zugrundeliegende Fehleinschätzung bemerkt wird, und im Weiteren einen alternativen Auswertungsplan zu verwenden. Jedoch sollten bereits berechnete Ergebnisse nicht verworfen und neu berechnet werden müssen, schließlich wäre dies ineffizient, sondern sie sollten einen Teil des insgesamt zu berechnenden Ergebnisses bilden [6, S. 396f]. Das eben beschriebene Vorgehen ist nicht nur einsetzbar, um die Anfrageausführung ein einziges Mal zu korrigieren, sondern es ist durchaus möglich, dies mehrfach zu tun, d.h. mehrfach die Ausführung eines Auswertungsplans abzubrechen und auf einen neuen, aufgrund der zur Verfügung stehenden Informationen effizienter erscheinenden Auswertungsplan umzuschalten. Dies führt dazu, dass die Anfrageausführung in mehreren Phasen erfolgt, in welcher je ein anderer Auswertungsplan zum Einsatz kommt. Zu beachten ist, dass das Endergebnis jedoch nicht durch eine einfache Vereinigung der in jeder Phase erzeugten Teilergebnisse gebildet werden kann, sondern es muss im Rahmen einer speziellen

12 10. The Tukwila Data Integration System (Jan Engelkamp) 12 abschließenden Vereinigungsphase, der sogenannten Stitch-up-Phase (to stitch up = nähen, zunähen, zusammennähen) korrigiert und ergänzt werden [6, S. 397]. Die obige Darstellung soll an einem konkreten Beispiel verdeutlicht werden [vgl. 6, S. 396f]. Angenommen, drei Relationen sollen folgendermaßen miteinander verknüpft werden: Personen [Personen.PersonenID = PKW.HalterID] PKW [PKW.LackID = Lacke.LackID] Lacke Eine derartige Verknüpfung (die Darstellung des Joins folgt 8, S. 2.15) kann etwa im Rahmen einer Anfrage verwandt werden, die alle Fahrzeughalter liefert, deren PKW eine bestimmte Lackierung aufweist. Je nach Kardinalität der Relationen Personen, PKW und Lacke bietet es sich an, aus Effizienzüberlegungen zuerst die Relationen PKW und Lacke anstelle der Relationen Personen und PKW zu verknüpfen, also den obigen Ausdruck umzuformen in : Lacke [PKW.LackID = Lacke.LackID] PKW [Personen.PersonenID = PKW.HalterID] Personen Wird jedoch erst nach einer gewissen Zeit entdeckt, dass die zunächst gewählte Reihenfolge weniger effizient ist als die letztere, wird also die Auswertung erst nach einer gewissen Zeit auf einen neuen Auswertungsplan umgestellt, so wurden zahlreiche Tupel der drei Relationen bereits vor der Umstellung erfolgreich miteinander zu Ergebnistupeln verknüpft. Angenommen, aus der Relation Personen wurden die ersten n Tupel und aus der Relation Lacke die ersten m Tupel vor der Umstellung auf einen neuen Auswertungsplan verarbeitet; danach werden die Tupel ab der Position n+1 der Relation Personen respektive ab der Position m+1 der Relation Lacke verarbeitet. Würden nun die derart produzierten Ergebnistupel einfach zu einem Endergebnis vereinigt werden, so würde dieses Endergebnis unvollständig sein, da keine Ergebnistupel gebildet wurden, in denen Tupel aus der Relation Personen mit den Positionen 1 bis n mit Tupeln aus der Relation Lacke mit den Positionen m+1 bis maximal verknüpft wurden, sowie Tupel aus der Relation Personen mit den Positionen n+1 bis maximal mit Tupeln aus der Relation Lacke mit den Positionen 1 bis m. Es müssen also ergänzend zu den beschriebenen Auswertungsphasen in der oben bereits genannten Stitch-up-Phase noch phasenübergreifende Relationen- Verknüpfungen erfolgen. Abbildung 2: Die Verarbeitung von unterschiedlichen Tupeln einer Relation durch verschiedene Auswertungspläne erfordert eine nachfolgende Stitch-Up-Phase [vgl. 6, S. 397]. Das eben beschriebene Beispiel verdeutlich den grundsätzlichen Ablauf des Adaptive Data- Partitioning sehr gut: Die Anfrageausführung erfolgt in mehreren Phasen, wobei jede Phase beendet wird, falls sich herausstellt, dass die Anfrageausführung mit einem anderen Auswertungsplan, als dem bislang verwandten, effizienter als bisher erfolgen kann. Den Abschluss der Ergebnisberechnung bildet eine spezielle abschließende Vereinigungsphase, die Stitch-up-Phase [6, S. 397]. Zu ermitteln, welche Berechnungen in der Stitch-up-Phase im Einzelnen auszuführen sind, stellt sicherlich eine der komplexesten Aufgaben des Adaptive Data-Partitioning dar, müssen doch Daten miteinander verknüpft werden, die im Rahmen u.u. ganz unterschiedlicher Auswertungspläne bereits zum Teil verarbeitet wurden. Zu beachten ist

13 10. The Tukwila Data Integration System (Jan Engelkamp) 13 auch, dass eine erneute Übertragung von Daten aus den verschiedenen Datenquellen des Data- Integration-System zur Ausführungskomponente im Rahmen der Stitch-up-Phase unbedingt zu vermeiden ist, da sich dies im Allgemeinen deutlich negativ auf die Effizienz der Anfrageausführung auswirkt; stattdessen müssen die in den verschiedenen Phasen verarbeiteten Daten für einen ggf. notwendigen erneuten Zugriff darauf im Rahmen der Stitch-up-Phase so zwischengespeichert werden, dass der erneute Zugriff möglichst effizient erfolgen kann [6, S. 399]. Auf detaillierte Implementierungen von Operationen der Stitch-up-Phase, wie etwa den Stitch-up-Join soll im Rahmen der vorliegenden Arbeit nicht weiter eingegangen werden (vgl. dazu 6, S. 399f). In der bisherigen Darstellung wurden die Phasen des Adaptive Data-Partitioning sequentiell nacheinander ausgeführt. Ein anderer Ansatz ist es, sie zu parallelisieren: Die zu verarbeitenden Daten werden überschneidungsfrei (disjunkt) partitioniert und jede Partition von einem anderen, alternativen Auswertungsplan verarbeitet. Nach einiger Zeit wird die Effizienz der Auswertungspläne verglichen und sodann alle bis dahin noch nicht verarbeiteten Daten ausschließlich durch den effizientesten verarbeitet. Am Ende erfolgt wiederum die notwendige Stitch-up-Phase [6, S. 397]. Dieser Ansatz ist nicht zu verwechseln mit den weiter oben vorgestellten Redundant-Computation-Methods. Dort wurden dieselben Daten parallel im Rahmen unterschiedlicher Auswertungspläne verarbeitet und nach einiger Zeit evaluiert, welcher Auswertungsplan dabei bislang am effizientesten war; dieser wird weiter ausgeführt, die übrigen werden abgebrochen und die von ihnen erzeugten (redundanten) Ergebnisse verworfen. Beim vorliegenden Ansatz des Adaptive Data-Partitioning bearbeiten verschiedene Auswertungspläne unterschiedliche (!) Daten, so dass keine redundanten Ergebnisse produziert werden und auch die in letztendlich abgebrochenen Auswertungsplänen erzeugten Ergebnisdaten verwandt werden. Redundante Berechnungen werden so vermieden. Eine weitere Art des Adaptive Data-Partitioning ergibt sich aus der Beobachtung, dass es häufig von den Eigenschaften der zu verarbeitenden Daten abhängig ist, welche mehrerer alternativer Implementierungen für eine Datenbankoperation die effizienteste ist. Es ist also u.u. sinnvoll, Datensätze, die unterschiedliche Eigenschaften besitzen, auch durch unterschiedliche Auswertungspläne verarbeiten zu lassen. Unmittelbar ersichtlich dürfte sein, dass auch in solch einem Fall eine Stitch-up-Phase obligatorisch ist [6, S. 397]. Ein Beispiel soll das Gesagte verdeutlichen: Angenommen, zwei Relationen sollen miteinander durch einen Join verknüpft werden, welche weitgehend, aber nicht vollständig sortiert sind. Dies kann etwa der Fall sein, wenn die Relationen vor einiger Zeit sortiert wurden, seitdem aber neue Datensätze bereits in der Form zugefügt wurden, dass sie entweder einfach an das Ende der zugrundeliegenden Datenstruktur angehängt oder in durch vorangegangene Datensatzlöschungen frei gewordene Speicherplätze geschrieben worden sind. Für die sortiert vorliegenden Datensätze kann eine diese Eigenschaft speziell ausnutzende Join-Implementierung wie etwa der Sort-Merge-Join [vgl. 10, S. 191ff] gewählt werden. Alle Datensätze, die die Sortierung der Relation verletzen, werden einem anderen Auswertungsplan zugeführt. In der Stitch-up-Phase schließlich werden die sortiert bei der Ausführungskomponente eingetroffenen mit den die Sortierung verletzenden Datensätzen Join-verknüpft. Da der eben genannte Sort-Merge-Join effizienter ist als der weiter oben vorgestellte Double- Pipelined-Hash-Join, wenn die beteiligten Relationen sortiert sind, bietet es sich an, auf die zuletzt angesprochene Art des Adaptive Data-Partition immer dann zurückzugreifen, wenn Anhaltspunkte dafür sprechen, dass die zu verknüpfenden Relationen sortiert vorliegen, sobald dies also vermutet wird [6, S. 403]. Die Join-Implementierungen Double-Pipelined-Hash-Join und Sort-Merge-Join können also dauerhaft zu einer gemeinsamen, quasi übergeordneten Join- Implementierung zusammengefasst werden, zum sogenannten Complementary-Join-Pair : Datensätze werden entgegengenommen, mit einer der beiden Implementierungsvarianten verarbeitet, eine quasi interne Stitch-up-Phase wird durchgeführt und ein vollständiges Ergebnis

14 10. The Tukwila Data Integration System (Jan Engelkamp) 14 des Joins ausgegeben. Da das Complementary-Join-Pair als spezielle Join-Implementierung in Auswertungsplänen verwandt werden kann, wurde das Adaptive Data-Partitioning quasi von der Ebene der Auswertungspläne in die Implementierung von Datenbankoperatoren verlagert. Man benötigt nun keine alternativen Auswertungspläne mehr [6, S. 404]. Abbildung 3: Beispiel eines Complementary-Join-Pair [vgl. 6, S. 404] 5.2. Adaptive Data-Partitioning im Tukwila-System Alle bisher angesprochenen adaptiven Techniken und Methoden sind im Tukwila-System realisiert. Dies sind insbesondere die im Kapitel 4 genannten Ansätze, die Reihenfolge von Operatoren innerhalb von Auswertungsplänen zur Ausführungszeit umzustellen (Scheduling- Based-Methods), aus alternativen Auswertungsplänen zur Laufzeit einen besten auszuwählen (Redundant-Computation-Methods), Auswertungspläne zur Ausführungszeit zu modifizieren (Plan-Partitioning-Methods), sowie zur Ausführungszeit zu entscheiden, welche Daten wie verarbeitet werden (Data-Partitioning-Methods). Des weiteren sind spezielle adaptive Operatoren, wie dynamische Datenkollektoren und der Double-Pipelined-Hash-Join, aber auch das beschriebene Complementary-Join-Pair in Tukwila realisiert [6, S. 398]. Neuere Entwicklungen konzentrieren sich auf eine Umsetzung der verschiedenen Arten des Adaptive Data-Partitioning: Zum einen werden Daten parallel in alternativen Auswertungsplan- Fragmenten verarbeitet, wenn die Datenmenge gemäß einer Eigenschaft, die erfüllt oder nicht erfüllt ist, disjunkt partitioniert werden kann; die Fragmente werden in je eigenen Threads abgearbeitet. Zum anderen wird die Abarbeitung eines Auswertungsplans abgebrochen, wenn sich herausstellt, dass seine Effizienz mangelhaft ist, ohne jedoch die bereits berechneten Ergebnisse zu verwerfen [6, S. 398f]. Um die Aufteilung der Datenmenge auf mehrere Auswertungspläne vorzunehmen, wird in Tukwila ein spezieller Operator verwendet, ebenso, um aus Einzelergebnissen ein Gesamtergebnis zu konstruierten. Bedeutender jedoch ist die Implementierung der Operationen, die in Stitch-up-Phasen verwandt werden, sowie der Aufbau von Datenstrukturen, die es ermöglichen, in Stitch-up-Phasen auf ein Neulesen bereits verarbeiteter Daten zu verzichten. Darauf genauer einzugehen, würde jedoch den Rahmen der vorliegenden Arbeit sprengen. (Daher sei verwiesen auf 6, S. 398f.)

15 10. The Tukwila Data Integration System (Jan Engelkamp) Zusammenfassung und Diskussion Nachdem zu Beginn dieser Arbeit grundsätzliche Anforderungen beschrieben wurden, die an ein Data-Integration-System gestellt werden, wurden die Architektur und die Systemkomponenten das Data-Integration-System Tukwila eingehender vorgestellt. Dabei wurden bewusst die neuesten Entwicklungen zur Realisierung eines Adaptive Data-Partitioning zunächst ausgeblendet. Darauf wurde erst in Kapitel 5 eingegangen, nachdem zuvor einige zentrale adaptive Techniken detailliert diskutiert wurden. Es dürfte deutlich geworden sein, dass eine zunehmende Adaptivität bei der Anfrageausführung zu einer Zunahme der Komplexität sowohl einzelner Berechnungen, als auch des Gesamtsystems führt. Ein wichtiges und immer wieder genanntes Argument für die Entwicklung und Implementierung adaptiver Techniken ist die Feststellung, dass Data-Integration-Systems nur wenige, ungenaue und unzuverlässige Informationen über die Inhalte von Datenquellen wie etwa Relationen- Kardinalitäten oder Werteverteilungen in Relationen zur Verfügung stehen und dass deren Abschätzungen häufig fehlerhaft sind. Tukwila ist ein experimentelles System, das im Rahmen von Forschungsarbeiten entstanden ist und kontinuierlich weiterentwickelt wird. Tukwila ist nicht für einen konkreten Anwendungszusammenhang entworfen und enthält Implementierungen für allerlei adaptive Techniken. Intensive Messungen der Systemperformance sind Bestandteil der Veröffentlichungen über Tukwila [vgl. 4; 5; 6]. Fraglich scheint, inwieweit adaptive Techniken in konkreten Anwendungszusammenhängen angewandt werden und in welchen Bereichen ihnen welche (potentielle) Bedeutung zukommt. Fraglich scheint des weiteren, in welchen Anwendungszusammenhängen eine Verbesserung der Datenquellen hinsichtlich der Verlässlichkeit der von ihnen zur Verfügung gestellten Metadaten möglich ist und grob gesagt mit wie viel Aufwand dies verbunden wäre. Dies könnte u.u. eine kostengünstige und die Systemperformance geringer belastende Alternative zur Implementierung von Adaptivität in Data-Integration-Systems sein. Nach Ansicht des Autors stellen diese Überlegungen interessante Fragen an eine anwendungsnahe Wirtschaftsinformatik dar.

16 10. The Tukwila Data Integration System (Jan Engelkamp) 16 Literaturverzeichnis [1] Brian Babcock, Shivnath Babu, Mayur Datar, Rajeev Motwani, and Jennifer Widom. Models and Issues in Data Stream Systems. Proceedings of the 2002 ACM Symposium on Principles of Database Systems, ACM Press, [2] Volker Claus, Andreas Schwill. Duden Informatik. Ein Fachlexikon für Studium und Praxis. Dudenverlag, [3] Joseph M. Hellerstein, Michael J. Franklin. Sirish Chandrasekaran, Amol Deshpande, Kris Hildrum, Sam Madden, Vijayshankar Raman, and Mehul A. Schah. Adaptive Query Processing: Technology in Evolution. Bulletin of the IEEE Computer Society Technical Commitee on Data Engineering, 23(2): 7-18, [4] Zachary G. Ives, Daniela Florescu, Marc Friedmann, Alon Levy, and Daniel S. Weld. An adaptive query execution system for data integration. Proceedings of the 1999 ACM SIGMOD international conference on Management of data, ACM Press, [5] Zachary G. Ives, Alon Y. Levy, Daniel S. Weld, Daniela Florescu, and Marc Friedmann. Adaptive query processing for internet applications. Bulletin of the IEEE Computer Society Technical Commitee on Data Engineering, 23(2): 19-26, ftp://ftp.research-microsoft.com/pub/debull/a00jun-cd.pdf [6] Zachary G. Ives, Alon Y Halevy, and Daniel S. Weld. Adapting to source properties in processing data integration queries. Proceedings of the 2004 ACM SIGMOD international conference on Management of data, ACM Press, [7] Zachary G. Ives, Alon Y Halevy, and Daniel S. Weld. The Tukwila Data Integration System. [8] Gunter Schlageter. Datenbanken I. Grundlagen, Anwendungen und Konzepte. Studienmaterial der FernUniversität, Gesamthochschule Hagen, [9] Gunter Schlageter, Friedrich Kemper, Thomas Berkel, Wolfgang Wilkes und Michael Balzer. Datenbanken II. Fortgeschrittene Konzepte und Realisierungsaspekte. Studienmaterial der FernUniversität, Gesamthochschule Hagen, [10] Markus Schneider. Implementierungskonzepte für Datenbanksysteme. Studienmaterial der FernUniversität, Gesamthochschule Hagen, 1999.

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

4. Datenabfrage mit QBE 11

4. Datenabfrage mit QBE 11 Informationsbestände analysieren Datenabfrage mit QBE 4. Datenabfrage mit QBE 11 4.1. QBE vs. SQL Relationale Datenbanken haben schon früh den Anspruch gestellt, auch für Nicht- Informatiker nutzbar zu

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

Mehr

Sortierverfahren für Felder (Listen)

Sortierverfahren für Felder (Listen) Sortierverfahren für Felder (Listen) Generell geht es um die Sortierung von Daten nach einem bestimmten Sortierschlüssel. Es ist auch möglich, daß verschiedene Daten denselben Sortierschlüssel haben. Es

Mehr

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Paradigmen im Algorithmenentwurf

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Paradigmen im Algorithmenentwurf Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005 Paradigmen im Algorithmenentwurf Problemlösen Problem definieren Algorithmus entwerfen

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Oracle-Statistiken im Data Warehouse effizient nutzen

Oracle-Statistiken im Data Warehouse effizient nutzen Oracle-Statistiken im Data Warehouse effizient nutzen Reinhard Mense ARETO Consulting Köln Schlüsselworte: DWH, Data Warehouse, Statistiken, Optimizer, Performance, Laufzeiten Einleitung Für die performante

Mehr

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo.

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo. Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten

Mehr

HOCHSCHULE KONSTANZ TECHNIK, WIRTSCHAFT UND GESTALTUNG. Das Luzifer-Rätsel. Prof. Dr. Hartmut Plesske Wintersemester 2008/09. von.

HOCHSCHULE KONSTANZ TECHNIK, WIRTSCHAFT UND GESTALTUNG. Das Luzifer-Rätsel. Prof. Dr. Hartmut Plesske Wintersemester 2008/09. von. HOCHSCHULE KONSTANZ TECHNIK, WIRTSCHAFT UND GESTALTUNG Fakultät Informatik Das Luzifer-Rätsel Prof. Dr. Hartmut Plesske Wintersemester 2008/09 von Max Nagl nagl@fh-konstanz.de Inhaltsverzeichnis Inhaltsverzeichnis

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Dieser Fragenkatalog wurde aufgrund das Basistextes und zum Teil aus den Prüfungsprotokollen erstellt, um sich auf mögliche

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

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

Kapitel 14 Verteilte DBMS

Kapitel 14 Verteilte DBMS Kapitel 14 Verteilte DBMS 14 Verteilte DBMS 14 Verteilte DBMS...1 14.1 Begriff, Architektur und Ziele verteilter Datenbanksysteme...2 14.2 Verteilungsarten...5 14.2.1 Verteilung der Daten...5 14.2.2 Verteilung

Mehr

Übungen zur Vorlesung. Mobile und Verteilte Datenbanken. WS 2008/2009 Übung 2 Anfrageoptimierung in zentralisierten Datenbanksystemen LÖSUNG

Übungen zur Vorlesung. Mobile und Verteilte Datenbanken. WS 2008/2009 Übung 2 Anfrageoptimierung in zentralisierten Datenbanksystemen LÖSUNG Dr. rer. nat. Sven Groppe Übungen zur Voresung Mobie und Verteite Datenbanken WS 28/29 Übung 2 Anfrageoptimierung in zentraisierten Datenbanksystemen Aufgabe 1: Fogende Reationen seien gegeben: LÖSUNG

Mehr

Performance by Design Wie werden performante ETL-Prozesse erstellt?

Performance by Design Wie werden performante ETL-Prozesse erstellt? Performance by Design Wie werden performante ETL-Prozesse erstellt? Reinhard Mense ARETO Consulting Bergisch Gladbach Schlüsselworte: DWH, Data Warehouse, ETL-Prozesse, Performance, Laufzeiten, Partitionierung,

Mehr

Histogramme in der Datenbankoptimierung. Marian Marx 26.06.2008

Histogramme in der Datenbankoptimierung. Marian Marx 26.06.2008 Histogramme in der Datenbankoptimierung Marian Marx 26.06.2008 Inhaltsverzeichnis 1. Histogramme im Allgemeinen 1.1 Definition Histogramm 1.2 Beispiel Histogramm 2. Histogramme in der Datenbankoptimierung

Mehr

PHP 5.4 ISBN 978-3-86249-327-2. Stephan Heller, Andreas Dittfurth 1. Ausgabe, September 2012. Grundlagen zur Erstellung dynamischer Webseiten GPHP54

PHP 5.4 ISBN 978-3-86249-327-2. Stephan Heller, Andreas Dittfurth 1. Ausgabe, September 2012. Grundlagen zur Erstellung dynamischer Webseiten GPHP54 PHP 5.4 Stephan Heller, Andreas Dittfurth 1. Ausgabe, September 2012 Grundlagen zur Erstellung dynamischer Webseiten ISBN 978-3-86249-327-2 GPHP54 5 PHP 5.4 - Grundlagen zur Erstellung dynamischer Webseiten

Mehr

Online Analytical Processing

Online Analytical Processing Online Analytical Processing Online Analytical Processing Online Analytical Processing (OLAP) ermöglicht die multidimensionale Betrachtung von Daten zwecks E rmittlung eines entscheidungsunterstützenden

Mehr

Operator-Kostenmodelle für Fortschrittsschätzung und Opt. Datenbanksystemen

Operator-Kostenmodelle für Fortschrittsschätzung und Opt. Datenbanksystemen Operator-Kostenmodelle für und Optimierung in Datenbanksystemen 23. Oktober 2012 Übersicht 1 Grundlagen Ziele der Arbeit Grundlagen Kostenmodelle Neues Framework Entwickelte Hilfsmittel 2 3 Ziele der Arbeit

Mehr

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt:

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: Datenbanksysteme Entwicklung der Datenbanksysteme Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: 1. Generation: In den fünfziger

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

Mehr

Whitebox-Tests: Allgemeines

Whitebox-Tests: Allgemeines -Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

Expose zur Studienarbeit Indizierung von XML-Daten mittels GRIPP

Expose zur Studienarbeit Indizierung von XML-Daten mittels GRIPP Expose zur Studienarbeit Indizierung von XML-Daten mittels GRIPP Betreuer: Silke Trissl Autor: email: Florian Zipser zipser@informatik.hu-berlin.de 1 1 Motivation Auf dem Gebiet der relationalen Datenbanken

Mehr

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder Programmieren in PASCAL Bäume 1 1. Baumstrukturen Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder 1. die leere Struktur oder 2. ein Knoten vom Typ Element

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

Mehr

Online Analytical Processing

Online Analytical Processing Online Analytical Processing Online Analytical Processing Online Analytical Processing (OLAP) ermöglicht die mu l- tidimensionale Betrachtung von Daten zwecks Ermit t- lung eines entscheidungsunterstützenden

Mehr

Vorbemerkungen. Von der Version 5.0.0 unterscheidet sich die Version 5.1.5-W u.a. durch folgende Merkmale:

Vorbemerkungen. Von der Version 5.0.0 unterscheidet sich die Version 5.1.5-W u.a. durch folgende Merkmale: Vorbemerkungen Sie erhalten hiermit die Multi-User-Version CUBUS 5.1.5-W, die Mehrplatz-Version des Dialogprogramms zur Erstellung von ärztlichen Berichten an Versicherungsgesellschaften. Sollten Sie bereits

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

Vielen Dank an Dennis Riehle für die Bereitstellung dieser Folien

Vielen Dank an Dennis Riehle für die Bereitstellung dieser Folien Vielen Dank an Dennis Riehle für die Bereitstellung dieser Folien 1.1 Definition Datenbank Ein Datenbanksystem (DBS) ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS

Mehr

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

Ausgewählte Kapitel eingebetteter Systeme

Ausgewählte Kapitel eingebetteter Systeme Ausgewählte Kapitel eingebetteter Systeme Verfahren zur Bestimmung der WCET Andreas Kaiser Friedrich-Alexander University Erlangen-Nuremberg Übersicht Wieso WCET Berechnung? Methoden zur Bestimmung der

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Hinweise zum Schreiben einer Ausarbeitung

Hinweise zum Schreiben einer Ausarbeitung Seite 1 Hinweise zum Schreiben einer (Physikalisches Praktikum für Physiker) Autor: M. Saß Fakultät für Physik Technische Universität München 24.11.14 Inhaltsverzeichnis 1 Struktur einer 2 1.1 Die Einleitung..............................

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

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt r. 2 Hausaufgabe Übung zur Vorlesung Grundlagen: Datenbanken im WS3/4 Henrik Mühe (muehe@in.tum.de)

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

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

Seminar Informationsintegration und Informationsqualität. Dragan Sunjka. 30. Juni 2006

Seminar Informationsintegration und Informationsqualität. Dragan Sunjka. 30. Juni 2006 Seminar Informationsintegration und Informationsqualität TU Kaiserslautern 30. Juni 2006 Gliederung Autonomie Verteilung führt zu Autonomie... Intra-Organisation: historisch Inter-Organisation: Internet

Mehr

Raumbezogene Datenbanken (Spatial Databases)

Raumbezogene Datenbanken (Spatial Databases) Raumbezogene Datenbanken (Spatial Databases) Ein Vortrag von Dominik Trinter Alexander Christian 1 Inhalte Was ist ein raumbezogenes DBMS? Modellierung Abfragen Werkzeuge zur Implementierung Systemarchitektur

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

Informationen zum Kopierschutz

Informationen zum Kopierschutz Analyser AutoSPy Informationen zum Kopierschutz Der Analyser AutoSPy verfügt über einen Kopierschutz, der unerlaubtes Erzeugen und Vervielfältigen von Lizenzen verhindert. Dieses Dokument soll Ihnen den

Mehr

TIKOS Leitfaden. TIKOS Update

TIKOS Leitfaden. TIKOS Update TIKOS Leitfaden TIKOS Update Copyright 2015, Alle Rechte vorbehalten support@socom.de 06.05.2015 Inhalt 1. Allgemeine Hinweise... 3 2. Ausführen des Updates... 3 3. Mögliche Meldungen beim Update... 9

Mehr

Form Designer. Leitfaden

Form Designer. Leitfaden Leitfaden Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den Beispielen verwendeten Namen und Daten sind frei erfunden, soweit nichts anderes

Mehr

Integration verteilter Datenquellen in GIS-Datenbanken

Integration verteilter Datenquellen in GIS-Datenbanken Integration verteilter Datenquellen in GIS-Datenbanken Seminar Verteilung und Integration von Verkehrsdaten Am IPD Lehrstuhl für Systeme der Informationsverwaltung Sommersemester 2004 Christian Hennings

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL)

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL) Inhalt der Vorlesung 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen und

Mehr

Null-Werte in Relationalen Datenbanken

Null-Werte in Relationalen Datenbanken Seminar: Imperfektion in Datenbanken WS03/04 Null-Werte in Relationalen Datenbanken Thomas Bierhance Einführung Null-Werte in DBen sind notwendiges Übel, da... (1) das Wissen über die tatsächliche Welt

Mehr

Entwurf von Algorithmen - Kontrollstrukturen

Entwurf von Algorithmen - Kontrollstrukturen Entwurf von Algorithmen - Kontrollstrukturen Eine wichtige Phase in der Entwicklung von Computerprogrammen ist der Entwurf von Algorithmen. Dieser Arbeitsschritt vor dem Schreiben des Programmes in einer

Mehr

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12 Grundlagen: Folge 19 - Bäume 19.1 Binärbäume - Allgemeines Unter Bäumen versteht man in der Informatik Datenstrukturen, bei denen jedes Element mindestens zwei Nachfolger hat. Bereits in der Folge 17 haben

Mehr

Betragsgleichungen und die Methode der Fallunterscheidungen

Betragsgleichungen und die Methode der Fallunterscheidungen mathe online Skripten http://www.mathe-online.at/skripten/ Betragsgleichungen und die Methode der Fallunterscheidungen Franz Embacher Fakultät für Mathematik der Universität Wien E-mail: franz.embacher@univie.ac.at

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Neue Ansätze der Softwarequalitätssicherung

Neue Ansätze der Softwarequalitätssicherung Neue Ansätze der Softwarequalitätssicherung Googles MapReduce-Framework für verteilte Berechnungen am Beispiel von Apache Hadoop Universität Paderborn Fakultät für Elektrotechnik, Informatik und Mathematik

Mehr

Leitprogramm Bubblesort

Leitprogramm Bubblesort Leitprogramm Bubblesort Dr. Rainer Hauser Inhalt 1 Übersicht...1 2 Input-Block I: Der Sortieralgorithmus Bubblesort...2 3 Input-Block II: Die Effizienz von Bubblesort...6 4 Zusammenfassung...8 5 Lernkontrolle...9

Mehr

Vorbemerkungen. Von den Versionen 4.0.0 und 4.0.1 unterscheidet sich die Version 4.1.6 u.a. durch folgende Merkmale:

Vorbemerkungen. Von den Versionen 4.0.0 und 4.0.1 unterscheidet sich die Version 4.1.6 u.a. durch folgende Merkmale: Vorbemerkungen Sie erhalten hiermit die Single-User-Version CUBUS 4.1.6, die neue Version des Dialog- Programms zur Erstellung von ärztlichen Berichten an Versicherungsgesellschaften. Sollten Sie bereits

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

Mehr

Aufgabe 1: [Logische Modellierung]

Aufgabe 1: [Logische Modellierung] Aufgabe 1: [Logische Modellierung] a) Entwerfen Sie für das von Ihnen entworfene Modell aus Aufgabe 2 des 1. Übungsblattes ein Star-Schema. b) Entwerfen Sie für das vorangegangene Modell einen Teil eines

Mehr

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

Mehr

Data Mining als Arbeitsprozess

Data Mining als Arbeitsprozess Data Mining als Arbeitsprozess Hagen Knaf Studiengang Angewandte Mathematik Hochschule RheinMain 31. Dezember 2015 In Unternehmen werden umfangreichere Aktivitäten oder Projekte im Bereich des Data Mining

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Kurzanleitung. Einstieg in die TripleCard Profi-Software. Zeiterfassungs- Software für. TripleCard Terminal

Kurzanleitung. Einstieg in die TripleCard Profi-Software. Zeiterfassungs- Software für. TripleCard Terminal Kurzanleitung Einstieg in die TripleCard Profi-Software Zeiterfassungs- Software für TripleCard Terminal 2000 Towitoko AG Windows 3.11 Windows 95/98 Windows NT Windows 2000 So installieren Sie die TripleCard

Mehr

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join Parsen der Anfrage (SQL) Transformation in eine Standardform (Relationenalgebra) Logische Optimierung Transformation in alternative Zugriffspläne, Physische Optimierung Ausführung des gewählten Zugriffsplans

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

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Ausgangspunkt. Datenintegration. Ziel. Konflikte. Architekturen. Transparenz

Ausgangspunkt. Datenintegration. Ziel. Konflikte. Architekturen. Transparenz Ausgangspunkt Datenintegration Web Informationssysteme Wintersemester 2002/2003 Donald Kossmann Daten liegen in verschiedenen Datenquellen (Extremfall: jede URL eigene Datenquelle) Mietautos bei www.hertz.com

Mehr

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce MapReduce Jan Kristof Nidzwetzki MapReduce 1 / 17 Übersicht 1 Begriffe 2 Verschiedene Arbeiten 3 Ziele 4 DEDUCE: at the intersection of MapReduce and stream processing Beispiel 5 Beyond online aggregation:

Mehr

DB2 Kurzeinführung (Windows)

DB2 Kurzeinführung (Windows) DB2 Kurzeinführung (Windows) Michaelsen c 25. Mai 2010 1 1 Komponenten von DB2 DB2 bietet zahlreiche graphische Oberflächen für die Verwaltung der verschiedenen Komponenten und Anwendungen. Die wichtigsten

Mehr

SplineGen. Modellierung

SplineGen. Modellierung SplineGen SplineGen ist ein im Rahmen des generischen Modells entstandenes Programmpaket, das bei der Festigkeitsanalyse von Laufrädern eingesetzt werden kann. Modellierung Die hier vorgestellte Software

Mehr

4 Greedy-Algorithmen (gierige Algorithmen)

4 Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen werden oft für die exakte oder approximative Lösung von Optimierungsproblemen verwendet. Typischerweise konstruiert ein Greedy-Algorithmus eine

Mehr

PHP Kurs Online Kurs Analysten Programmierer Web PHP

PHP Kurs Online Kurs Analysten Programmierer Web PHP PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione

Mehr

Multidimensionale Datenbanksysteme

Multidimensionale Datenbanksysteme Multidimensionale Datenbanksysteme Modellierung und Verarbeitung Von Dr.-Ing. Wolfgang Lehner IBM Almaden Research Center, San Jose, USA Technische Universität Darrr:ctadi FACHBEREICH INFORMATIK BIBLIOTHEK

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Transaction Validation for XML Documents based on XPath

Transaction Validation for XML Documents based on XPath Transaction Validation for XML Documents based on XPath @ Informatik 2002, m-dbis Stefan Böttcher Adelhard Türling Universität Paderborn Überblick Transaktionen für XML - Daten & mobile Clients Motivation

Mehr

Cayuga. A General Purpose Event Monotoring System. David Pfeiffer. 19. Juli 2007

Cayuga. A General Purpose Event Monotoring System. David Pfeiffer. 19. Juli 2007 Cayuga A General Purpose Event Monotoring System David Pfeiffer 19. Juli 2007 1 / 24 Themen 1 2 Aufbau Operatoren 3 Das Modell der Zustandsübergang Zustandstypen 4 Beispiel Kritik & Fragen 2 / 24 Was ist

Mehr

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer Speicherung von XML in (objekt-)relationalen Datenbanken Burkhard Schäfer Übersicht Motivation Anforderungen Ansätze modellorientiert strukturorientiert Zusammenfassung Motivation Warum XML in Datenbanken

Mehr

2 Grundkonzepte im Überblick

2 Grundkonzepte im Überblick 7 In diesem Kapitel führen wir die wichtigsten Begriffe und Charakteristika aktiver Datenbanksysteme ein und stellen die Teilaufgaben vor, die bei ihrem Aufbau zu bewältigen sind. All dies geschieht hier

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten 6.3 Metadaten (2) Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT

Mehr

One of the few resources increasing faster than the speed of computer hardware is the amount of data to be processed. Bin Hu

One of the few resources increasing faster than the speed of computer hardware is the amount of data to be processed. Bin Hu Bin Hu Algorithmen und Datenstrukturen 2 Arbeitsbereich fr Algorithmen und Datenstrukturen Institut fr Computergraphik und Algorithmen Technische Universität Wien One of the few resources increasing faster

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

P.A. Bernstein, V. Hadzilacos, N. Goodman

P.A. Bernstein, V. Hadzilacos, N. Goodman TRANSAKTIONEN UND DATENINTEGRITÄT Concurrency Control and Recovery in Database Systems P.A. Bernstein, V. Hadzilacos, N. Goodman Addison Wesley, 1987. Kapitel 1. und 6. Grundlagen der Datenbanksysteme

Mehr

Star Join & Kostenbasierte Optimierung. Architektur von Datenbanksystemen II

Star Join & Kostenbasierte Optimierung. Architektur von Datenbanksystemen II Star Join & Kostenbasierte Optimierung Architektur von Datenbanksystemen II Star Join Übungsaufgabe zum 09.06.2015 JOIN-ALGORITHMUS für folgendes Scenario Große Faktentabelle F mit sehr vielen Einträgen

Mehr

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS BIETEN EFFIZIENTE, SKALIERBARE UND LEICHT ZU VERWALTENDE SNAPSHOTS OHNE KOMPROMISSE

Mehr

20. Algorithmus der Woche Online-Algorithmen: Was ist es wert, die Zukunft zu kennen? Das Ski-Problem

20. Algorithmus der Woche Online-Algorithmen: Was ist es wert, die Zukunft zu kennen? Das Ski-Problem 20. Algorithmus der Woche Online-Algorithmen: Was ist es wert, die Zukunft zu kennen? Das Ski-Problem Autor Susanne Albers, Universität Freiburg Swen Schmelzer, Universität Freiburg In diesem Jahr möchte

Mehr

TO P I C S E R V I C E & W I S S E N

TO P I C S E R V I C E & W I S S E N TO P I C 108 SERVICE & WISSEN WISSENSDATENBANKEN IM CALL CENTER ANFORDERUNGEN UND MÖGLICHKEITEN Kurz & bündig Wissensdatenbanken ein Trendthema? Im Kontext des zunehmenden Interesses am Thema Wissensmanagement

Mehr

Einführung in Datenbanksysteme. H. Wünsch 01.2001

Einführung in Datenbanksysteme. H. Wünsch 01.2001 Einführung in Datenbanksysteme H. Wünsch 01.2001 H. Wünsch 01/2001 Einführung Datenbanken 2 Was sind Datenbanken? Datenbanken sind Systeme zur Beschreibung, Speicherung und Wiedergewinnung von Datenmengen.

Mehr

MEC EDI Schnittstelle MEC EDI SCHNITTSTELLE MEC EDI. Datenaustausch via EDI - EDIFACT. Überschrift 1

MEC EDI Schnittstelle MEC EDI SCHNITTSTELLE MEC EDI. Datenaustausch via EDI - EDIFACT. Überschrift 1 MEC EDI Schnittstelle Datenaustausch via EDI - EDIFACT MEC EDI SCHNITTSTELLE MEC EDI Überschrift 1 Kurzbeschreibung Die MEC WinLine EDI Schnittstelle bietet einen schnellen und einfachen Weg Lieferscheine

Mehr

SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen

SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen Mit SAP PLM 7 und anderen Web UI Anwendungen hat SAP neue Oberflächen für bestehende und neue Funktionalität geschaffen. Diese Anwendungen

Mehr

Protokollbuch. Friedrich-Schiller-Universität Jena. Physikalisch-Astronomische Fakultät SS 2008. Messtechnikpraktikum

Protokollbuch. Friedrich-Schiller-Universität Jena. Physikalisch-Astronomische Fakultät SS 2008. Messtechnikpraktikum Friedrich-Schiller-Universität Jena Physikalisch-Astronomische Fakultät SS 2008 Protokollbuch Messtechnikpraktikum Erstellt von: Christian Vetter (89114) Helena Kämmer (92376) Christian.Vetter@Uni-Jena.de

Mehr

Kommunikations-Management

Kommunikations-Management Tutorial: Wie importiere und exportiere ich Daten zwischen myfactory und Outlook? Im vorliegenden Tutorial lernen Sie, wie Sie in myfactory Daten aus Outlook importieren Daten aus myfactory nach Outlook

Mehr

Kapitel 8: Physischer Datenbankentwurf

Kapitel 8: Physischer Datenbankentwurf 8. Physischer Datenbankentwurf Seite 1 Kapitel 8: Physischer Datenbankentwurf Speicherung und Verwaltung der Relationen einer relationalen Datenbank so, dass eine möglichst große Effizienz der einzelnen

Mehr

Indextest bietet klare und schnelle Antworten auf immer wiederkehrende Fragen

Indextest bietet klare und schnelle Antworten auf immer wiederkehrende Fragen 06. August 2013 ForschungsWerk mit Innovation auf dem Markt: Indextest bietet klare und schnelle Antworten auf immer wiederkehrende Fragen NÜRNBERG - ForschungsWerk hat mit Indextest ein Tool entwickelt,

Mehr

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr