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.

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

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

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

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

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

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

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 2015 Kapitel 3: Datenbanksysteme Vorlesung:

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

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

4. Relationen. Beschreibung einer binären Relation

4. Relationen. Beschreibung einer binären Relation 4. Relationen Relationen spielen bei Datenbanken eine wichtige Rolle. Die meisten Datenbanksysteme sind relational. 4.1 Binäre Relationen Eine binäre Relation (Beziehung) R zwischen zwei Mengen A und B

Mehr

Informationsintegration

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

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

Teil XI Spalten-orientierte DBMSs

Teil XI Spalten-orientierte DBMSs Teil XI Spalten-orientierte DBMSs Spalten-orientierte Datenbankmanagementsysteme 1 Motivation 2 Funktionsweise 3 Erweiterungen 4 Literatur c Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte

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

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

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

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

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

Probabilistische Datenbanken

Probabilistische Datenbanken Probabilistische Datenbanken Seminar Intelligente Datenbanken AG Intelligente Datenbanken Prof. Dr. Rainer Manthey 26.04.05 Maarten van Hoek - 1 - Inhaltsverzeichnis 1.0 Einleitung...3 2.0 Modell probabilistischer

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

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

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

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion independit Integrative Technologies GmbH Bergstraße 6 D 86529 Schrobenhausen BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion Dieter Stubler Ronald Jeninga July 30,

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

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

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

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

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

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

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

Handbuch zum Mensurenprogramm

Handbuch zum Mensurenprogramm Handbuch zum Mensurenprogramm Von Reiner Janke March-Buchheim (bei Freiburg) Reiner Janke 1996 Was kann das Programm? Das Programm schreibt Mensurlisten (Weiten-, Längen-, Aufschnittmensuren etc.) von

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

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

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

"getiban.exe" wird als selbstentpackende Archivdatei "getiban.exe" ausgeliefert.

getiban.exe wird als selbstentpackende Archivdatei getiban.exe ausgeliefert. Allgemeine Beschreibung von GETIBAN.EXE "getiban.exe" ist ein Windows Kommandozeilen Programm zur Berechnung von IBANs aus vorhandenen Kontonummern und Bankleitzahlen für die derzeit in SEPA teilnehmenden

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

VDLUFA-Schriftenreihe 1

VDLUFA-Schriftenreihe 1 VDLUFA-Schriftenreihe 1 Wie viele Apps sind ein LIMS? J. Flekna Pragmatis GmbH, Neufahrn 1. Einleitung Seitdem mobile Endgeräte massentauglich sind, ist die Bezeichnung App fester Bestandteil unseres zeitgeistigen

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Wichtige Hinweise zu REFLEX 9

Wichtige Hinweise zu REFLEX 9 Wichtige Hinweise zu REFLEX 9 Mit der Version 9 beginnt für REFLEX ein neues Zeitalter: Es wird ein neuer Datenbank-Treiber eingeführt, der sich "ADO" nennt. Der bisherige Datenbank-Treiber "BDE" wird

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

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

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

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

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

Informatik 12 Datenbanken SQL-Einführung

Informatik 12 Datenbanken SQL-Einführung Informatik 12 Datenbanken SQL-Einführung Gierhardt Vorbemerkungen Bisher haben wir Datenbanken nur über einzelne Tabellen kennen gelernt. Stehen mehrere Tabellen in gewissen Beziehungen zur Beschreibung

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

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY Data Cube On-line Analytical Processing (OLAP). Einführung Ziel: Auffinden interessanter Muster in großen Datenmengen 2. Aggregation in SQL, GROUP BY 3. Probleme mit GROUP BY 4. Der Cube-Operator! Formulierung

Mehr

27 Transact-SQL-Erweiterungen in Bezug auf Analysis Services

27 Transact-SQL-Erweiterungen in Bezug auf Analysis Services 531 27 Transact-SQL-Erweiterungen in Bezug auf Analysis Services Im zweiten Teil dieses Buches haben wir die Eigenschaften der Transact-SQL- Sprache in Bezug auf die Bearbeitung von operativen Daten gezeigt.

Mehr

query flood DoS attacks in Gnutella

query flood DoS attacks in Gnutella query flood DoS attacks in Gnutella von Andreas Legrum basierend auf einem Dokument von Neil Daswani und Hector Garcia-Molina Für das Seminar "Peer-to-peer Information Systems" - 1 - Übersicht 1. Einführung

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Advanced Analytics mit EXAPowerlytics. Technisches Whitepaper

Advanced Analytics mit EXAPowerlytics. Technisches Whitepaper Advanced Analytics mit EXAPowerlytics Technisches Whitepaper Inhalt 1. Zusammenfassung... 3 2. Einführung... 4 3. Fachliche Einführung... 5 4. Beispiel: Zeichen zählen... 7 5. Fazit... 9 6. Anhang... 10-2

Mehr

Die allerwichtigsten Raid Systeme

Die allerwichtigsten Raid Systeme Die allerwichtigsten Raid Systeme Michael Dienert 4. Mai 2009 Vorbemerkung Dieser Artikel gibt eine knappe Übersicht über die wichtigsten RAID Systeme. Inhaltsverzeichnis 1 Die Abkürzung RAID 2 1.1 Fehlerraten

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

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

Datenbanksysteme I Anfragebearbeitung und -optimierung. 27.6.2011 Felix Naumann

Datenbanksysteme I Anfragebearbeitung und -optimierung. 27.6.2011 Felix Naumann Datenbanksysteme I Anfragebearbeitung und -optimierung 27.6.2011 Felix Naumann Anfragebearbeitung Grundproblem 2 Anfragen sind deklarativ. SQL, Relationale Algebra Anfragen müssen in ausführbare (prozedurale)

Mehr

Dezentrale Datenproduktion und -analyse bei DØ

Dezentrale Datenproduktion und -analyse bei DØ Dezentrale Datenproduktion und -analyse bei DØ Thomas Nunnemann LMU München nunne@fnal.gov DPG Mainz 31.3.04 Computing: Aufgaben/Anforderungen Datenaustausch verteilter Datenbankzugriff Prozessierung von

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Data Streams: Gegenüberstellung existierender Systeme und Architekturen. Marius Renn Betreuer: Jürgen Göres

Data Streams: Gegenüberstellung existierender Systeme und Architekturen. Marius Renn Betreuer: Jürgen Göres Data Streams: Gegenüberstellung existierender Systeme und Architekturen Marius Renn Betreuer: Jürgen Göres Inhalt Kriterien Existierende Systeme STREAM Aurora PIPES (SPEX) (MAIDS) Vergleich Fazit Einleitung

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

lassen Sie mich zunächst den Organisatoren dieser Konferenz für ihre Einladung danken. Es freut mich sehr, zu Ihren Diskussionen beitragen zu dürfen.

lassen Sie mich zunächst den Organisatoren dieser Konferenz für ihre Einladung danken. Es freut mich sehr, zu Ihren Diskussionen beitragen zu dürfen. Mobile Personal Clouds with Silver Linings Columbia Institute for Tele Information Columbia Business School New York, 8. Juni 2012 Giovanni Buttarelli, Stellvertretender Europäischer Datenschutzbeauftragter

Mehr

Auslegung eines Testaments bezüglich der Folgen bei Ableben der eingesetzten Miterben

Auslegung eines Testaments bezüglich der Folgen bei Ableben der eingesetzten Miterben DNotI Deutsches Notarinstitut letzte Aktualisierung: 28.10.2014 OLG Düsseldorf, 16.6.2014 I-3 Wx 256/13 BGB 133, 2069, 2084, 2093, 2094 Abs. 1 Auslegung eines Testaments bezüglich der Folgen bei Ableben

Mehr

MEC Hogast EDI SCHNITTSTELLE MEC EDI

MEC Hogast EDI SCHNITTSTELLE MEC EDI MEC Hogast EDI SCHNITTSTELLE EDI Schnittstelle MEC EDI Datenaustausch mit dem Hogast System Überschrift 1 Kurzbeschreibung Die MEC WINLine HOGAST Schnittstelle bietet einen schnellen und einfachen Weg

Mehr

Vergleich verschiedener Optimierungsansätze

Vergleich verschiedener Optimierungsansätze Vergleich verschiedener Optimierungsansätze Inhaltsverzeichnis 1 Einleitung... 2 2 Welchen Nutzen schafft munio?... 3 3 Analysen... 3 3.1 Schritt 1: Optimierung anhand von Indizes... 3 3.2 Schritt 2: Manuell

Mehr

Institut für Informatik

Institut für Informatik Technische Universität München Institut für Informatik Lehrstuhl für Computer Graphik & Visualisierung WS 2010 Praktikum: Grundlagen der Programmierung Lösungsblatt 7 Prof. R. Westermann, A. Lehmann, R.

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

ProCall 5 Enterprise

ProCall 5 Enterprise ProCall 5 Enterprise Installationsanleitung Upgradeverfahren von ProCall 4+ Enterprise auf ProCall 5 Enterprise ProCall 5 Enterprise Upgrade Seite 1 von 10 Rechtliche Hinweise / Impressum Die Angaben in

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Business Intelligence mit Microsoft SQL Server 2005

Business Intelligence mit Microsoft SQL Server 2005 Business Intelligence mit Microsoft SQL Server 2005 Holger Schrödl ISBN 3-446-40463-5 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40463-5 sowie im Buchhandel 4.6

Mehr

und von mehreren PCs nutzen Nr. 070101

und von mehreren PCs nutzen Nr. 070101 Was ist denn eigentlich dieser SComm-Treiber? Der Saia Communication Driver kurz SComm-Treiber dient verschiedenen Programmen der Saia PG5 (z.b. Online Configurator, Debugger, Fupla, SEdit, Watch Window

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde

Mehr

1. Download und Installation

1. Download und Installation Im ersten Teil möchte ich gerne die kostenlose Software Comodo Backup vorstellen, die ich schon seit einigen Jahren zum gezielten Backup von Ordnern und Dateien einsetze. Diese Anleitung soll auch Leuten,

Mehr

Implementierung der SQL Operatoren GROUP BY und CUBE

Implementierung der SQL Operatoren GROUP BY und CUBE Implementierung der SQL Operatoren GROUP BY und CUBE Seminararbeit von Christian Brandt Seminar Advanced Data Warehousing WS 2003/2004 Einführung Ein zentrales Element von OLAP - Anwendungen ist die Aggregation

Mehr

Lehrgebiet Informationssysteme

Lehrgebiet Informationssysteme Lehrgebiet AG Datenbanken und (Prof. Michel, Prof. Härder) AG Heterogene (Prof. Deßloch) http://wwwlgis.informatik.uni-kl.de/ Was sind? Computergestützte Programmsysteme, die Informationen erfassen, dauerhaft

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

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

Migrationsanleitung von 2.0 auf 2.1

Migrationsanleitung von 2.0 auf 2.1 Die wichtigste Neuerung von 2.0 auf 2.1 aus Sicht der Anwendungs- Migration ist die Verwendung von Maven. Mit Maven holt sich die Anwendung alle notwendigen Bibliotheken in den jeweils angegebenen Versionen

Mehr

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe.

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. Change Log: DBB/LX Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. 1. Version 4.5.0.1243 1. AF: Das Tool Datenbank neu aufbauen wurde ergänzt. Damit können Datenbanken,

Mehr

Select & Preprocessing Cluster. SPP Server #1. SPP Server #2. Cluster InterConnection. SPP Server #n

Select & Preprocessing Cluster. SPP Server #1. SPP Server #2. Cluster InterConnection. SPP Server #n C5000 High Performance Acquisition System Das C5000 System wurde für Messerfassungs- und Auswertungssystem mit sehr hohem Datenaufkommen konzipiert. Typische Applikationen für das C5000 sind große Prüfstände,

Mehr

17 Datenbank aufteilen

17 Datenbank aufteilen 17 Datenbank aufteilen Warum teilt man eine Datenbank auf und was bedeutet dies? Eine Access-Datenbankdatei ist ein Monolith. Sie enthält alle notwendigen Objekte wie Tabellen, Abfragen, Formulare, Berichte,

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

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

MySql Backup. Backup mit phpmyadmin. ITST Systemberatung MySql Backup

MySql Backup. Backup mit phpmyadmin. ITST Systemberatung MySql Backup Backups (Dumps)/Restores von MySql-Datenbanken lassen sich generell über zwei Wege bewerkstelligen. Zum einen mit Middleware wie phpmyadmin oder MySqlFront und ähnlichen graphischen Oberflächen. Grundsätzlich

Mehr

VHDL Verhaltensmodellierung

VHDL Verhaltensmodellierung VHDL Verhaltensmodellierung Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2008/2009 VHDL Verhaltensmodellierung 1/26 2008-10-20

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

Eine Abfrage (Query) ist in Begriffe und Operatoren unterteilt. Es gibt zwei verschiedene Arten von Begriffen: einzelne Begriffe und Phrasen.

Eine Abfrage (Query) ist in Begriffe und Operatoren unterteilt. Es gibt zwei verschiedene Arten von Begriffen: einzelne Begriffe und Phrasen. Lucene Hilfe Begriffe Eine Abfrage (Query) ist in Begriffe und Operatoren unterteilt. Es gibt zwei verschiedene Arten von Begriffen: einzelne Begriffe und Phrasen. Ein einzelner Begriff ist ein einzelnes

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

MapReduce in der Praxis

MapReduce in der Praxis MapReduce in der Praxis Rolf Daniel Seminar Multicore Programmierung 09.12.2010 1 / 53 Agenda Einleitung 1 Einleitung 2 3 Disco Hadoop BOOM 4 2 / 53 1 Einleitung 2 3 Disco Hadoop BOOM 4 3 / 53 Motivation

Mehr

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

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015 Migrationsstrategien Dr. Thorsten Arendt Marburg, 22. Januar 2015 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2014/2015 Überblick Probleme Wenn man ein bestehendes System re-engineered

Mehr

Übung Datenbanksysteme I Relationale Algebra. Thorsten Papenbrock

Übung Datenbanksysteme I Relationale Algebra. Thorsten Papenbrock Übung Datenbanksysteme I Relationale Algebra Thorsten Papenbrock Übersicht: Relationale Algebra 2 Unäre Operatoren Binäre Operatoren Operator Beschreibung Operator Beschreibung (pi) (erweiterte)projektion

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

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs Betrifft Art der Info Quelle WHERE Klausel Generierung mit.net und Oracle Technical Info Aus unserer Projekterfahrung und Architektur-Kurs Where ist the WHERE? Der Artikel untersucht die Möglichkeiten,

Mehr

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Dezember 007 Dipl.-Ing. Stefan Abu Salah Dipl.-Ing. Achim Marikar QoS (Quality of Service): Sicherstellung der Qualität Zeitkritische

Mehr