TInTo - Ein datenbankgestütztes Werkzeug zur regelbasierten Wertpapieranalyse

Transkript

1 Rheinische Friedrich-Wilhelms-Universität Bonn Institut für Informatik III Diplomarbeit TInTo - Ein datenbankgestütztes Werkzeug zur regelbasierten Wertpapieranalyse Christian Hübel Januar 2007 Erstgutachter: Prof. Dr. Rainer Manthey

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Datenbanksysteme Relationale Datenbanksysteme Grundlagen relationaler Datenbanken Normalformen Regelkonzepte in Datenbanken SQL - Structured Query Language Einführung und Überblick DDL - Data Denition Language DML - Data Manipulation Language DCL - Data Control Language Wertpapiere und Indikatoren Wertpapiere Börse Aktien Grundlagen der Wertpapieranalyse Fundamentale Analyse Technische Analyse Chartanalyse Technische Indikatoren Trendfolgeindikatoren Momentum-Oszillatoren Trendbestimmungsindikatoren Volatilitätsindikatoren Handelssysteme Entwurf von TInTo Idee und Zielsetzung TInTo als Bestandteil eines Handelssystems Problemklasse der Data Streams Anforderungsprol und Use-Cases Entwurf des Datenbankschemas i

4 Inhaltsverzeichnis 4.4 Architektur von TInTo TInTo-Benutzerschnittstelle Implementierung Verwendete Software Microsoft Access ChartDirector Umsetzung des Schemaentwurfs in Microsoft Access Programmstruktur und Visual Basic Module Umsetzung der Indikatorklassen in TInTo Aggregatfreie Indikatoren Indikatoren mit einfachen Aggregaten Indikatoren mit mehrstugen Aggregaten Rekursive Indikatoren Leistungsbewertung und Ezienz Optimierungen und Anpassungen Beispielszenario für TInTo 91 7 Zusammenfassung 99 A Module und Funktionen 103 B Literaturverzeichnis 111 ii

5 1 Einleitung Das Ziel dieser Arbeit ist der Entwurf und die Implementierung eines datenbankgestützten Werkzeuges zur regelbasierten Analyse von Wertpapierkursen. Dazu müssen Finanzdaten kontinuierlich beschat, gespeichert und zur Berechnung von technischen Indikatoren bereitgestellt werden. Die Arbeit reiht sich in eine Folge von Vorgängerarbeiten ein ([KR04], [GE05]), die sich theoretisch mit diesem Thema befasst haben. Im Rahmen dieser Arbeit soll jedoch erstmals ein konkretes, auf einem kommerziellen Datenbanksystem (DBS) lauähiges Werkzeug implementiert werden. Gleichzeitig wird mit diesem Werkzeug der Grundstein für ein umfassendes Handelssystem gelegt, dessen Hauptaufgabe es sein soll, dem Anwender Hinweise für möglichst gewinnbringende Kauf- oder Verkaufsentscheidungen zu liefern. Unter technischer Analyse von Wertpapieren versteht man das Beobachten, Aufzeichnen und Analysieren von Börsenkursen. Dabei werden üblicherweise nur die zur Verfügung stehenden Daten wie Erönungs-, Höchst-, Tiefst- und Schlusskurs sowie das Umsatzvolumen für einen bestimmten Zeitraum untersucht. Die Grundannahme der technischen Analyse ist relativ einfach. Es wird angenommen, dass sich vergangene Kursverläufe wiederholen, was wiederum auf das menschliche Verhalten beim Kaufund Verkauf von Aktien zurückgeführt wird. Dies steht im Gegensatz zur fundamentalen Analyse, bei der sich Kursentwicklungen aufgrund allgemeiner wirtschaftlicher Zusammenhänge und der Betrachtung von Gewinnaussichten des Unternehmens erklären und prognostizieren lassen sollen. Die technische Analyse lässt sich in zwei Bereiche aufteilen. Zum einen in die Chartanalyse, deren Ziel es ist, Regelmässigkeiten im Kursverlauf von Aktien zu erkennen und daraus Handelssignale abzuleiten. Zum anderen in die Indikatorenanalyse, einer mathematischen Analyseform, die aufgrund historischer Kurs- und Umsatzdaten Informationen zur Qualität eines Trends und daraus abgeleitet Prognosen liefern soll. In dieser Arbeit wird die Berechnung von technischen Indikatoren behandelt. Diese sind ein Instrument der technischen Aktienanalyse zur Identikation und Anzeige von Richtung und Kraft einer gerade laufenden Kursbewegung. Ziel ist es, Hilfestellung für konkrete Kauf- oder Verkaufsentscheidungen zu geben. Auch wenn es wissenschaftlich nicht erwiesen, ja sogar umstritten ist, ob sich mit der technischen Analyse tatsächlich Aussagen über den zukünftigen Kursverlauf eines Wertpapieres machen lassen, wird sie dennoch in der Praxis äuÿerst häug angewandt. Hier dient sie als representatives Anwendungsszenario für die Verarbeitung und Analyse von Datenströmen. Dabei 1

6 1 Einleitung werden konstante Abfragen auf einer kontinuierlichen Abfolge von sich verändernden Daten ausgeführt (siehe auch [AG06]). Beinahe jede Bank und jedes Wertpapierhaus stellt den Kunden im Internet umfassende Möglichkeiten der Online-Analyse zur Verfügung. Deren Flexibilität ist jedoch durch die meist starre Implementierung der Schnittstelle zu den Daten sowie der fehlenden Parametrierung der Analysewerkzeuge sehr eingeschränkt. Der Anwender ist dabei nicht in der Lage, Anfragen zu stellen, deren Berechnung im System nicht implementiert ist. Lediglich eine begrenzte Zahl von Anfragen sind in vorkompilierter Form vorgesehen. Zusätzlich lassen sich die vorhandenen Analysewerkzeuge oft gar nicht oder nur sehr eingeschränkt parametrieren und den Bedürfnissen des Analysten anpassen, da die Regeln zur Gewinnung der Analysedaten und die Methoden der Auswertung fest miteinander verknüpft sind. Kommerzielle Analyseprogramme bieten hier oft exiblere Möglichkeiten als die Online-Analyse. Zur Erweiterung des Funktionsumfanges können hier vom Anwender Berechnungsvorschriften in Skriptsprachen eingegeben werden, die jedoch fast immer eine proprietäre Syntax besitzen. Gemäss dieser Vorschriften berechnet dann das Programm den gewünschten Indikator auf der Grundlage der vorhandenen Datenbasis. Die vermeintliche Flexibilität dieser Lösung bringt jedoch auch Nachteile mit sich. Zum einen sind nur Berechnungen möglich, die sich in der Skriptsprache formulieren lassen. Zum anderen sind oft sehr viele Kurs- und Umsatzdaten zur Berechnung der Indikatoren notwendig, die beim Abarbeiten des Skripts über den Interpreter der Analysesoftware zunächst geladen werden müssen. Bei diesen mengenorientierten Operationen erscheint diese Vorgehensweise, sogar bei optimierten Interpretern mit geeigneter Zwischenpuerung, auf Massendaten ebenfalls nicht optimal zu sein. Da sich die bei der Analyse verwendeten technischen Indikatoren ausschlieÿlich aus den in der Datenbank verwalteten Kurs- und Umsatzdaten berechnen, scheint es daher sinnvoll, die Berechnung der Indikatoren ebenfalls innerhalb des verwendeten Datenbanksystems zu implementieren. Die so berechneten Indikatorwerte werden dann, gemeinsam mit den Kurs- und Umsatzdaten, dem Analysewerkzeug zur Darstellung übergeben. Dieser Vorteil würde sich insbesonders in einer Client-Server-Umgebung bemerkbar machen, da in diesem Fall keine überüssigen Daten zusätzlich über ein Netzwerk übertragen werden müssen. Die besondere Schwierigkeit dieses Ansatzes besteht jedoch darin, dass einige Indikatordenitionen, beispielsweise solche mit Rekursionen, sich in den meisten SQL-Dialekten nicht ausdrücken lassen. Für die Berechnung dieser Indikatoren muss daher eine geeignete Lösung gefunden werden, um sie ebenfalls abbilden zu können. Weiterhin müssen die Berechnungen möglichst schnell und ezient auszuführen sein, da die auf Basis der Indikatoren abgeleiteten Kaufoder Verkaufsentscheidungen zeitnah zur Verfügung stehen sollten. Die Ezienz der Berechnungen spielt daher ebenfalls eine wichtige Rolle. Sind diese Probleme aber zu lösen, steht ein äuÿerst exibler Ansatz zur Berechnung der technischen Indikatoren zur Verfügung. Damit lässt sich langfristig ein umfassendes Handelssystem aufbauen. 2

7 Bei dem im Rahmen dieser Arbeit implementierten Werkzeug TInTo, Technical Indicator Tool, dessen Hauptformular in Abbildung 1.1 zu sehen ist, soll das oben skizzierte Verfahren der Indikatorberechnung auf der Datenbank zur Anwendung kommen. Die Berechnung der Indikatoren soll direkt in der standardisierten Datenbanksprache Structured Query Language (SQL) in Form von Abfragen (oder Sichten 1 ) formuliert werden. Das System soll dabei in der Lage sein, verschiedenste Indikatorsichten zu verwalten und auszuführen. Die berechneten Werte sollen gemeinsam mit dem Kursverlauf des Wertpapieres in geeigneter Form als Tabelle oder Diagramm dargestellt werden. Gleichzeitig soll es so exibel sein, dass die gängigsten Indikatoren, einschlieÿlich der oben bereits angesprochenen schwer zu formulierenden, ohne weiteres mit dem Werkzeug berechenbar sind. Die zugrunde liegenden Kurs- und Umsatzdaten sollen dabei, für den Anwender vollkommen transparent, über eine geeignete Schnittstelle aus dem Internet geladen und in einer relationalen Datenbank abgelegt werden. Abbildung 1.1: TInTo Hauptformular Es liegt in der Natur der behandelten Themen, das sowohl im Bereich der Datenbanken als auch im Bereich der Wertpapiere viele englische Fachbegrie verwendet werden. Wo es möglich ist, werden diese gemeinsam mit ihren deutschen Begrien eingeführt. Oft sind sowohl die englischen Originale als auch die verwendeten Anglizismen jedoch griger und meist sogar im verwendeten Umfeld im Sprachgebrauch durchaus üblich. Daher werden diese auch bevorzugt in der vorliegenden Arbeit verwendet. 1 Die Begrie Abfrage und Sicht werden in dieser Arbeit oft synonym verwendet. Eine Sicht ist genau genommen nichts weiter als eine gespeicherte Abfrage. 3

8 1 Einleitung Die Arbeit ist folgendermaÿen gegliedert. In Kapitel 2 werden die Grundlagen der dieser Arbeit zugrunde liegenden relationalen Datenbanken sowie die Datenbanksprache SQL, in der die TInTo-Indikatorsichten deniert werden, in Grundzügen vorgestellt. Kapitel 3 führt in grundlegende Kenntnisse über Wertpapiere, speziell über Aktien, ein. Ausserdem werden die Grundlagen der Wertpapieranalyse im Allgemeinen sowie die technische Analyse im Speziellen behandelt. In Kapitel 4 wird die Konzeption des Werkzeuges TInTo einschlieÿlich seiner funktionalen und abstrakten Einordnung vorgestellt, gefolgt von dem Softwareentwurf des Systems. Die anschliessende Implementierung von TInTo behandelt Kapitel 5. Es wird gezeigt, dass sich Indikatoren verschiedenen Komplexitätsklassen zuordnen lassen, zu denen jeweils eine Formulierung in TInTo als Lösung vorgestellt wird. Abschliessend wird die Leistungsfähigkeit des Systems behandelt. Kapitel 6 führt in das Bedienungskonzept von TInTo ein. Eine Zusammenfassung folgt in Kapitel 7. Im Anhang ndet sich neben dem Literaturverzeichnis auch eine Kurzübersicht über die implementierten Module und deren Funktionen als Hilfe für eine mögliche spätere Weiterentwicklung des TInTo-Systems. 4

9 2 Datenbanksysteme Da bei der Realisierung von TInTo beide Konzepte Anwendung nden, soll in diesem Abschnitt sowohl eine kurze Einführung zu relationalen Datenbanken als auch zur Datenbanksprache Structured Query Language (SQL) gegeben werden. Die Einführung zu SQL beruht im wesentlichen auf Informationen aus [DD96], ergänzt um einige Details aus [MSACC03] sowie [WIKI06]. 2.1 Relationale Datenbanksysteme Relationale Datenbanken basieren auf dem im Jahre 1970 von Edgar F. Codd im Rahmen seiner Forschungsarbeit am IBM Almaden Research Center in San Jose veröentlichten Artikel A Relational Model of Data for Large Shared Data Banks [CO70]. Codd schuf damals mit seinem Vorschlag des Relationalen Modells die Grundlagen für den gesamten Bereich der relationalen Datenbanken Grundlagen relationaler Datenbanken In einer relationalen Datenbank werden Daten in Form von zweidimensionalen Tabellen (oder Relationen) gespeichert. Jede Relation besteht dabei aus einer Menge von Zeilen, welche ein Tupel des durch die Tabelle dargestellten Relationstyps beschreibt. Daher werden die Zeilen einer Relation auch Tupel genannt. Weiterhin besteht die Relation aus einer Menge von Spalten (oder Attributen des Relationstyps). Der Grad einer Relation entspricht der Anzahl der Attribute (oder Spalten), die Kardinalität entspricht der Anzahl der Tupel (oder Zeilen). Die Tabellen können anhand von Schlüsseln miteinander verknüpft werden. Weiterhin dienen die Schlüssel dazu, die Tupel in einer Tabelle eindeutig zu identizieren, d.h. der Schlüssel besteht aus einer Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile in dieser Gruppe eine eindeutige Kombination von Werten hat. Unterschieden werden die Begrit Superschlüssel, Schlüsselkandidat, Primär- und Sekundärschlüssel sowie Fremdschlüssel. Ein Superschlüssel ist dabei eine beliebige Menge von Attributen, welche die Tupel einer Relation eindeutig identiziert, wohingegen ein Schlüsselkandidat eine minimale Menge von entsprechenden Attributen bezeichnet. Ein Primärschlüssel wird aus der Menge der Schlüsselkandidaten in der Form 5

10 2 Datenbanksysteme ausgewählt, dass er möglichst klein ist und die realen Gegebenheiten möglichst genau widerspiegelt. Durch die Festlegung eines Primärschlüssels werden die anderen Schlüsselkandidaten automatisch zu Sekundärschlüsseln. Ein Fremdschlüssel dient als Verweis zwischen zwei Relationen, er zeigt also, welche Tupel miteinander in Beziehung stehen. Die meisten der heute eingesetzten Datenbanksysteme (DBS) verwalten relationale Datenbanken (DB) mit Hilfe eines Datenbankmanagementsystems (DBMS) - sie werden daher auch als Relationale Datenbankmanagementsysteme bezeichnet (RDBMS). Die Verwaltungssoftware, das DBMS, hat dabei die Aufgabe, die Daten in der Datenbank zu speichern, zu organisieren, zu modizieren oder über eine Abfragesprache, üblicherweise SQL, entsprechende Daten zur Verfügung zu stellen. Zum Entwurf einer relationalen Datenbank wird meist das Entity-Relationship- Modell angewendet. Es dient dazu, einen Ausschnitt aus der realen Welt zu beschreiben und besteht meist aus einer oder mehreren Graken sowie der Beschreibung der darin verwendeten Elemente (ER-Diagramme). Der Begri Entity beschreibt dabei konkrete Dinge oder Objekte der realen Welt (also z.b. Autor, Bücher, Verlage, etc.), wohingegen Relationship den Zusammenhang zwischen den Entities beschreibt (so z.b. verfasst als mögliche Beziehung zwischen Autor und Buch). Dieser Phase des logischen Entwurfs (oder auch Datenmodellabbildung) folgt dann ein Datenbankschema im Implementierungsdatenmodell des DBMS. Neben den mengenorientierten relationalen Datenbanken, existieren eine Vielzahl von weiteren Modellen, welche die Grundlage für die Strukturierung der Daten sowie die Art ihrer Beziehungen zueinander festlegen [MA98]: Hierarchisches Datenbankmodell Dieses (älteste) satzorientierte Datenbankmodell reicht in die 50er und 60er Jahre zurück und bildet die Daten in Form von Baumstrukturen ab. Jeder Satz hat also genau einen Vorgänger und es gibt genau eine Wurzel. Netzwerkdatenbankmodell Das ebenfalls satzorientierte Netzwerkmodell fordert keine strenge Hierarchie der Sätze. Die Objekte werden in Netzen miteinander verdrahtet. Objektorientiertes Datenbankmodell Im objektorientierten Datenbankmodell werden Objekte gespeichert. Dabei werden reale Gegenstände durch Datenbankobjekte realisiert, daher spricht man bei diesen Datenbanken auch oft von Objektdatenbanken. Diese können neben den normalen (alpha)numerischen Attributen auch Bestandteile enthalten, die selber wiederum Objekte sind. 6

11 2.1 Relationale Datenbanksysteme Oft existieren auch Mischformen dieser Modelle, so z.b. das objektrelationale Modell. Es kommt dort zum Einsatz, wo Mengen von Objekten in Beziehung zu anderen Objekten gesetzt werden sollen. Im Rahmen dieser Arbeit sollen Berechnungen auf Kurs- und Umsatzdaten von Wertpapieren vorgenommen werden, also auf groÿen Datenmengen. Dabei sind die Einzelsätze von einfacher Struktur, welche keine Verarbeitung als Objekt rechtfertigen würde. Daher bietet sich von den hier vorgestellten Modellen das relationale Modell bei der Implementierung von TInTo an, welches die benötigten mengenorientierten Operationen zur Berechnung der Indikatoren zur Verfügung stellt Normalformen Zur Verringerung von in der Datenbank möglicherweise vorkommenden Redundanzen (d.h. identische, mehrmals vorkommende Daten) sowie zur Vermeidung von Inkonsistenzen (sich widersprechende Daten) wird oft das Konzept der Normalisierung angewendet. Dabei versteht man unter Normalisierung die schrittweise Überführung des Relationenschemas in verschiedene sogenannte Normalformen durch Anwendung von Normalisierungsalgorithmen. So werden beispielsweise Spalten einer Tabelle in mehrere Spalten einer anderen Tabelle überführt (Zerlegung von Wertpapier in Name, ISIN, WKN, etc), und diese Spalten werden dann verknüpft (beispielsweise von Kurs zu Wertpapier über eine Wertpapier-ID). Diese Trennung (in unserem Beispiel die Trennung von Kursen, den Bewegungsdaten, und Wertpapieren, den Stammdaten) verhindert Redundanzen, spart Speicherplatz und wahrt die Konsistenz der Daten. Es gibt mehrere zur Zeit gebräuchliche Normalformen [KE98]: Erste Normalform (1NF) Die erste Normalform liegt vor, wenn jedes Attribut der Relation atomare Wertebereiche hat, d.h. kein Attributwertbereich kann in andere sinnvolle Wertebereiche aufgespaltet werden (nicht also eine ganzes Wertpapier als einzelnes Attribut, sondern Aufspaltung in die relevanten Attribute wie Wertpapiername, ISIN, etc.) Zweite Normalform (2NF) Eine Relation liegt in der zweiten Normalform vor, wenn die erste Normalform vorliegt und zusätzlich alle Nichtschlüsselattribute (d.h. alle Spalten, die nicht in einem Schlüssel vorkommen) von jedem Schlüsselkandidaten voll funktional (also vom ganzen Schlüssel) abhängig sind. Probleme bei Nichterfüllung sind beispielsweise Dateninkonsistenzen. Dritte Normalform (3NF) Zusätzlich zu den Bedingungen der 1NF und 2NF liegt die dritte Normalform 7

12 2 Datenbanksysteme vor, wenn keine transitiven Abhängigkeiten vorliegen. Hängt also Attribut P2 von Attribut P1, sowie Attribut P3 von P2 ab, dann darf P3 nicht von P1 abhängig sein. Kein Nichtprimärattribut darf von einem anderen Nichtprimärattribut abhängen. Probleme bei Nichterfüllung sind z.b. Datenredundanzen. Boyce-Codd-Normalform (BCNF) In der BCNF dürfen Teile zweier aus mehreren Feldern zusammengesetzte Schlüsselkandidaten nicht voneinander abhängig sein. Der Schlüssel darf kein Nicht- Schlüssel-Attribut beinhalten. In anderen Worten: Eine Relation ist in BCNF, wenn sie die Voraussetzungen der 3NF erfüllt und gleichzeitig jede Determinante (Menge von Attributen, von denen andere voll funktional abhängen) Schlüsselkandidat ist. Vierte Normalform (4NF) und Fünfte Normalform (5F) Die 4NF fordert, dass nur triviale mehrwertige Abhängigkeiten vorhanden sind, d.h. es darf nicht mehrere voneinander unabhängige 1:n-Beziehungen in einer Relation geben. Eine Relation ist in 5NF, wenn sie sich ohne Informationsverlust nicht weiter in Relationen aufspalten lässt. Meist wird in der Praxis die Einhaltung der dritten Normalform angestrebt, wobei die erste, zweite und dritte Normalform bei einem guten Entwurf meist schon intuitiv eingehalten werden. Die vierte und fünfte Normalform werden in der Praxis seltener eingehalten und sind eher theoretischer Natur Regelkonzepte in Datenbanken Zur Erweiterung der Datenbankfunktionalität existieren drei Regelkonzepte: deduktive, aktive und normative Regeln [MT04]. Deduktive Regeln werden zur Spezikation von Datenmengen verwendet, aktive Regeln denieren Systemreaktionen und normative Regeln dienen der Konsistenzsicherung in gespeicherten und abgeleiteten Daten. Prinzipiell kann jedes Datenmodell basierend auf der entsprechenden Abfragesprache um diese Regeln erweitert werden. Die drei unterschiedlichen Regelformen sollen im Folgenden näher erläutert werden: Deduktive Regeln Deduktive Regeln dienen der deklarativen Ableitung von Datenmengen. Eine Ableitungsregel ist dabei eine allgemeine Denition, die es ermöglicht, implizite Daten aus einer Menge von expliziten Daten intensional zu spezizieren. Dies geschieht anhand von Sichtdenitionen, die jeweils entweder virtuell oder materialisiert deklariert werden können. Mit dem Aufrufen der Sicht werden bei virtuellen Sichten die resultierenden (oder abgeleiteten) Daten nicht dauerhaft 8

13 2.1 Relationale Datenbanksysteme gespeichert und müssen bei einem erneuten Aufruf neu abgeleitet werden, wohingegen bei materialisierten Sichten die abgeleiteten Daten dauerhaft in der Datenbank gespeichert werden. Dabei muss die materialisierte Sicht bei Änderung der Basisdaten natürlich angepasst werden. Zur Auswertung der deduktiven Regeln muss ein DBMS über eine sogenannte Inferenzkomponente verfügen. Es werden zwei mögliche Ereignisse unterschieden: zum einen eine Anfrage nach regeldenierten Daten (anfragegetriebene Inferenz ), zum anderen eine Änderung der zugrundeliegenden Basisdaten (änderungsgetriebene Inferenz ). Aktive Regeln Systemreaktionen in den gängigen Datenbanksystemen werden über Trigger realisiert. Dabei stellen Trigger eine imperative Spezikation von Integritätsprüfungen dar und werden beim Eintreten eines zugehörigen Ereignisses ausgelöst. Zur Verarbeitung von Triggern muss das DBMS in der Lage sein, die in den Triggern beschriebenen Situationen zu erkennen und die dafür festgelegten Reaktionen auszulösen. Dies lässt sich auch über sogenannte ECA-Regeln darstellen. Die ECA-Regeln sind durch drei Komponenten gekennzeichnet: ein regelauslösendes Ereignis (E, Event), eine optionale Bedingung (C, Condition) sowie eine auszuführende Aktion (A, Action). Wenn also das spezizierte Ereignis eintrit, wird die spezizierte Bedingung überprüft und gegebenenfalls die angegebene Aktion ausgeführt. Zwischen Ereignis, Bedingung und Aktion werden weiterhin verschiedene Kopplungsmodi vorgeschlagen, d.h. die Bedingungsauswertung und die Ausführung von Aktionen kann vom auslösenden Ereignis entkoppelt werden und zum Beispiel am Ende einer Transaktion oder gar in einer eigenen Transaktion ausgeführt werden. Die Datenbanksprache Structured Query Language (SQL) unterstützt das Triggerkonzept. Normative Regeln Normative Regeln dienen der Konsistenzsicherung in gespeicherten und abgeleiteten Daten. Sie werden durch Integritätsbedingungen realisiert und sollen unsinnige Zustände oder Zustandsübergänge verhindern. Integritätsbedingungen lassen sich hinsichtlich mehrerer Kategorien klassizieren. Aus der Strukturbeschreibung des Datenmodells folgen die modellinhärenten Bedingungen. Dies sind bei relationalen Datenbanken z.b. die Primärschlüsseleigenschaft sowie die referentielle Integrität für Fremdschlüssel. Weiter gibt es Attributwert-Bedingungen (z. B. Geburtsjahr > 1900), Satzbedingungen (z.b. Geburtsdatum < Einstellungsdatum), Satztyp-Bedingungen (z.b. Eindeutigkeit von Attributwerten) sowie satztypübergreifende Bedingungen (z.b. referentielle Integrität zwischen verschiedenen Tabellen). Ausserdem unterscheidet man zusätzlich zwischen statischen (z.b. Gehalt < ) und dynamischen (z.b. Gehalt darf nicht kleiner werden) Integritätsbedingungen. Statische Bedingungen beschreiben zulässige Zustände der Datenbank, während dynamische Integritätsbedingungen die zu- 9

14 2 Datenbanksysteme lässigen Zustandsübergänge beschreiben (Übergangsbedingungen). SQL erlaubt die Formulierung all dieser Typen mit Ausnahme der dynamischen Integritätsbedingungen. In dieser Arbeit wird die Berechnung von technischen Indikatoren in der Datenbanksprache SQL auf einem relationalen Datenbanksystem durchgeführt. Dabei werden überwiegend deduktive Regeln benötigt, denn es geht vorrangig um die Berechnung von technischen Indikatoren basierend auf Wertpapierkursen. Dennoch werden beim Datenbankentwurf auch normative Regeln in Form von Integritätsbedingungen benötigt. Alle Tabellen enthalten Primärschlüssel, die Kurstabelle wird ausserdem einen Fremdschlüssel auf die Wertpapiertabelle erhalten (mehr dazu in Kapitel 4.3). Ein kurzer Überblick über SQL und deren Möglichkeit, die obigen Regelkonzepte zu realisieren, folgt im nächsten Kapitel. 2.2 SQL - Structured Query Language Zur Berechnung von technischen Indikatoren wird im Rahmen dieser Arbeit ein Werkzeug basierend auf einer relationalen Datenbank entworfen. Zur Formulierung der Abfragesichten wird die Datenbanksprache SQL verwendet. Der folgende kurze Überblick zu SQL wird zeigen, dass die zur Berechnung der Indikatoren notwendigen Möglichkeiten, wie beispielsweise Rekursionen, in den meisten SQL-Dialekten nicht vorhanden sind und daher Workarounds zur Realisierung der Indikatorsichten notwendig sind. Dennoch rechtfertigt die breitächige kommerzielle Verbreitung solcher Systeme sowie deren exible Abfragemöglichkeiten die Wahl von SQL auf einem relationalen DBMS zur Realisierung des TInTo-Projektes Einführung und Überblick Die deklarative Datenbanksprache Structured Query Language, kurz SQL, für relationale Datenbanken hat sich als Standard für viele heutige Datenbankprodukte etabliert. Ihre Geschichte reicht bis in das Jahr 1970 zurück. Basierend auf der bereits in vorhergehenden Abschnitt erwähnten Arbeit von Edgar F. Codd A Relational Model of Data for Large Shared Data Banks [CO70] aus dem Jahre 1970 wurde eine Vielzahl verschiedener Datenbanksprachen entwickelt. SEQUEL (Structured English Query Language) als die, zumindest von einem kommerziellen Standpunkt aus gesehene Bedeutenste, entstand im Jahre 1974 bei IBM. Im Jahr 1976/77 wurde sie durch SEQUEL/2 abgelöst, welche aus rechtlichen Gründen später in SQL umbenannt wurde. In dem ersten verfügbaren relationalen Datenbanksystem von IBM namens System R wurde dann eine Untermenge von SEQUEL/2 (bzw. SQL) 10

15 2.2 SQL - Structured Query Language implementiert. Dieses System wurde sowohl bei IBM selber als auch bei einer Reihe von IBM-Kunden installiert. Der Erfolg von System R führte sowohl bei IBM als auch bei anderen Herstellern zu Anstrengungen, ein kommerzielles System basierend auf der Sprache SQL zu entwickeln. Im Jahre 1979 verkaufte die Relational Software Inc. (später Oracle Corporation) ihre erste kommerzielle Datenbank Oracle V2. Im Jahr 1981 kündigt IBM mit SQL/DS ein eigenes SQL-Produkt für die VSE-Umgebung an, gefolgt von weiteren Herstellern wie etwa Sybase Inc mit SYBASE. Aufgrund der Vielzahl von Produkten, die inzwischen SQL unterstützen, hat sich SQL damit als der de-facto-standard in der Welt der Datenbanken etabliert. SQL ist inzwischen ein ozieller Standard. In den Jahren 1982 bis 1986 wurde SQL vom American National Standards Institute (ANSI) genormt und als erster SQL- Standard verabschiedet (SQL-86), der daraufhin auch von der International Organisation for Standardization (ISO) ratiziert wurde (SQL-89). Im Jahre 1992 wurde der Standard erstmalig überarbeitet und als SQL-92 (SQL2) veröentlicht. Im Jahre 1999 wurde SQL3 (bzw. SQL:1999) verabschiedet, gefolgt von SQL:2003, welches in Jahre 2003 von der ISO verabschiedet wurde. Die dieser Arbeit zugrunde liegende Jet-Engine von Microsoft Access unterstützt SQL-92. SQL besitzt eine einfache, an die englische Sprache angelehnte Syntax und stellt Befehle zur Datendenition, Datenmanipulation (Einfügen, Aktualisieren bzw. Löschen von Datensätzen) sowie zur Datenabfrage zur Verfügung. Durch die Standardisierung wird eine möglichst weitgehende Unabhängigkeit von der benutzen Software erzielt, allerdings implementieren die meisten Hersteller zusätzliche spezische Erweiterungen. Der SQL Sprachstandard, oder zumindest Teile davon, werden von den meisten bekannten Datenbanksystemen unterstützt. SQL-Befehle werden in drei verschiedene Sprachbereiche unterteilt: DDL - Data Denition Language Die DDL enthält Befehle zur Denition des Datenbankschemas und wird als Sprache verwendet, um Datenstrukturen zu beschreiben, zu ändern oder zu löschen. Sie stellt die Datenbeschreibungssprache einer Datenbank dar. Befehle sind z.b. CREATE, ALTER oder DROP. DML - Data Manipulation Language Die DML enthält die Befehle, die zum Lesen, Schreiben, Ändern und Löschen von Daten benötigt werden. Die DML ist somit die Datenverarbeitungssprache einer Datenbank. Befehle sind z.b. SELECT, INSERT, UPDATE oder DELETE. DCL - Data Control Language Die DCL enthält die Komponenten der Datenbanksprache, die benötigt werden, um Berechtigungen zu vergeben oder zu entziehen. DCL ist die Datenüberwachungssprache einer Datenbank. Befehle sind z.b. GRANT oder REVOKE. 11

16 2 Datenbanksysteme In dieser Arbeit werden nur Befehle der DDL sowie der DML benötigt. DCL-Befehle werden nicht eingesetzt, dennoch wäre deren Verwendung grundsätzlich denkbar. So ist es beispielsweise möglich, dass bestimmte Abfragen (und damit Indikatorberechnungen) nur bestimmten Anwendern zugänglich sein sollen. Aus diesem Grunde werden in den nächsten Abschnitten die wesentlichen Anweisungen der jeweiligen Sprachbereiche kurz vorgestellt, wobei der Schwerpunkt auf den von TInTo zur Denition der Indikatorsichten unterstützten Anweisungen liegt. Eine vollständigte Einführung ndet der interessierte Leser in der in groÿer Anzahl zur Verfügung stehenden Literatur (u.a. [DD96]) DDL - Data Denition Language Die Befehle der DDL, also der Datenbeschreibungssprache, dienen der Denition des Datenbankschemas. Es können Datenstrukturen angelegt, modiziert oder gelöscht werden. Mit Hilfe der Anweisungen CREATE, ALTER bzw. DROP können Domänen und Basistabellen erzeugt, modiziert oder gelöscht werden. Dabei ist das Domänenkonzept in SQL im wesentlichen eine Art Datentypspezikation von Spalten, welche beliebig oft vorkommen können. Die Befehle der DDL sollen hier jedoch nicht anhand von Domänen, sondern vielmehr bei der Anwendung auf Basistabellen erläutert werden. Basistabellen sind autonome, benannte Tabellen, d.h. sie sind eigenständig und basieren nicht, wie bei (Sicht)Tabellen (oder Abfragen), auf mehreren abgeleiteten Basistabellen. Sie werden durch eine entsprechende CREATE-Anweisung mit einem Namen versehen. Die Anweisung CREATE TABLE erzeugt Basistabellen. Das folgende Beispiel erzeugt die Tabelle TWertpapier in der TInTo-Datenbank: CREATE TABLE TWertpapier ( Symbol VARCHAR(10), ID COUNTER, Typ TINYINT, Name CHAR(200), ISIN CHAR(15), WKN CHAR(8) CONSTRAINT Symbol PRIMARY KEY); Die Attributliste in Klammern hinter dem Tabellennamen enthält dabei den Namen des Attributes, den Datentyp (ggf. inklusive der Datentypgröÿe bei Feldern vom Typ Text oder Binary) sowie ergänzende Attribute wie z.b. NOT NULL. Die CONSTRAINT Klausel deniert zusätzlich verschiedene Einschränkungen für ein Feld und kann weiterhin zum Einrichten von (Primär)Schlüsseln verwendet werden. 12

17 2.2 SQL - Structured Query Language Die im vorherigen Kapitel beschriebenen Integritätsbedingungen als mögliche Realisierung der normativen Regeln können dabei in SQL direkt bei der Erzeugung von Tabellen berücksichtigt werden. Dabei können relationale Invarianten durch Spezikation von Primary-Key und Foreign-Key Klauseln bei der Tabellendenition abgebildet werden. Für Fremdschlüssel kann dabei die Reaktion auf das Wegfallen eines referenzierten Satzes bzw. Primärschlüssels festgelegt werden. Wertebereiche für Attribute können durch Angabe des Datentyps festgelegt werden. Dabei besteht die Möglichkeit, einen Default-Wert zu spezizieren, Eindeutigkeit von Attributwerten zu verlangen (UNIQUE), Nullwerte auszuschlieÿen (NOT NULL) sowie über eine CHECK-Klausel allgemeine Wertebereichsbeschränkungen festzulegen. Eine bestehende Basistabelle kann mittels der ALTER TABLE-Anweisung auf verschiedene Weise geändert werden. Die folgende Anweisung ergänzt beispielsweise die zusätzlichen Felder v1, v2 und v3 in der Tabelle TKurs der TInTo-Datenbank: ALTER TABLE TKurs ADD COLUMN( v1 DOUBLE, v2 DOUBLE, v3 DOUBLE); Alternativ ist es möglich, durch DROP COLUMN Spalten zu löschen. Ausserdem können mit ADD CONSTRAINT Indizes hinzugefügt oder diese durch DROP CONSTRAINT wieder gelöscht werden. Mit Hilfe des Befehls DROP TABLE können schliesslich Tabellen einschlieÿlich Ihrer Daten aus der Datenbank entfernt werden: DROP TABLE TKurs; Die obige Anweisung löscht beispielsweise die Tabelle TKurs aus der TInTo-Datenbank. Ist dabei das zusätzliche Schlüsselwort RESTRICT angegeben, schlägt das Löschen fehl, wenn die Tabelle in Integritätsbedingungen oder Sichtdenitionen verwendet wird. Das Schlüsselwort CASCADE hingegen löscht zusätzlich zur angegebenen Basistabelle alle referenzierenden Sichten und Integritätsbedingungen DML - Data Manipulation Language Die Datenverarbeitungssprache DML enthält die Befehle, die zum Lesen, Schreiben, Ändern und Löschen von Daten benötigt werden, also den Teil von SQL zur Anzeige und Veränderung von Daten. Zur Selektion bzw. Abfrage von Daten stellt SQL die SELECT-Anweisung zur Verfügung. Aufgrund seiner Syntax kann eine SELECT-Anweisung auch als SFW-Block gesehen werden. Dabei steht SFW für die Komponenten SELECT (welche Spalten 13

18 2 Datenbanksysteme werden als Ergebnis zurückgeliefert), FROM (was sind die zugrundeliegenden Basistabellen) und WHERE (die Bedingungen, welche die Ergebnismenge erfüllen muss). Die folgende Anweisung berechnet beispielweise in der TInTo-Anwendung den technischen Indikator Accumulation/Distribution Oscillator ADO (siehe Kapitel 5.4.1): SELECT ID, n, Date, High, Low, Open, Close, Vol, (High-Open)+( Close-Low)/(2*(High-Low)) AS Ind1 FROM Tkurs WHERE ID=spGetID() AND n>spgetn() ORDER BY ID DESC, Date DESC; Dabei wird in dem SELECT-Teil bestimmt, welche Ergebnisspalten zurückgegeben werden sollen (hier die Felder der Tabelle TKurs sowie der errechnete Indikator Ind1), der FROM-Teil enthält die der Abfrage zugrundeliegenden Basistabellen bzw. Sichten (hier als einzige die Tabelle TKurs) und der WHERE-Teil legt die Bedingungen fest, welche die Ergebnismenge erfüllen muss (hier die Einschränkung der ID auf ein bestimmtes Wertpapier sowie die Einschränkung der Satzanzahl). Ergänzt wird die Abfrage durch eine Sortierung im ORDER BY-Teil (hier absteigend sortiert nach ID und Datum). Die UPDATE-Anweisung wird zur Änderung von Zeilen in einer Tabelle verwendet. Beispielsweise setzt die folgende Aktionsabfrage der MACD-Berechnung in TInTo die freien Attribute v1 und v2 der Tabelle TKurs auf den jeweiligen Schlusskurs des gleichen Satzes: UPDATE Tkurs SET v1=close, v2=close WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()-2; Analog zur SELECT-Anweisung besteht auch hier die Möglichkeit, über eine (optionale) WHERE-Klausel eine Einschränkung der zu ändernden Daten vorzunehmen. In dem obigen Beispiel besteht die Einschränkung darin, dass auf ein bestimmtes Wertpapier über dessen ID sowie auf einen bestimmten Zeitraum über n eingeschränkt wird. Die beiden Anweisungen INSERT sowie DELETE seien hier der Vollständigkeit halber noch kurz erwähnt, auch wenn sie in der aktuellen TInTo-Version noch keine Anwendung nden. Mit INSERT können explizit konstruierte Tupel oder die Ergebnisse eines SFW-Blocks in eine Relation eingefügt werden. Die folgende Anweisung fügt in die TWertpapier-Tabelle der TInTo-Datenbank die Aktie Microsoft als neues Wertpapier ein: INSERT INTO TWertpapier(Symbol, ID, Typ, Name, ISIN, WKN) VALUES ( MSF.FSE, 1, 0, Microsoft Corp., NULL, ); In diesem Beispiel werden die einzelnen Werte der Werteliste in die Tabelle eingefügt. Jedes Element ist dabei entweder ein Skalarausdruck oder eines der selbsterklärenden 14

19 2.2 SQL - Structured Query Language Schlüsselwörter DEFAULT oder NULL. Die Anweisung resultiert in einer einzelnen, in die Tabelle eingefügte, Zeile. Der i-te Ausdruck der Werteliste wird dabei in die Spalte eingefügt, die in der INTO-Klausel durch den i-ten Eintrag bezeichnet ist. Alternativ zur festen Werteliste dieses Beispiels kann auch ein eigener SFW-Block (zumindest potentiell) mehrere Zeilen zum Einfügen liefern. Der Tabellenausdruck ergibt dann bei der Auswertung ein Zwischenergebnis, welches so behandelt wird, als ob die Skalarwerte jeder einzelnen Zeile dieses Zwischenergebnisses als Werteliste in der einwertigen INSERT-Anweisung angegeben worden wären. Die DELETE-Anweisung wird zum Löschen von Zeilen in einer Tabelle verwendet. Diese Operation geht im allgemeinen über mehrere Zeilen. In einer Operation können also keine, eine oder mehrere Zeilen gelöscht werden, welche wiederum die (optionale) WHERE-Klausel erfüllen. Folgendes Beispiel verdeutlicht dies: DELETE FROM Tkurs WHERE Tkurs.ID=spGetID(); Alle Kursdaten des Wertpapieres, auf das die Einschränkung der WHERE-Klausel zutrit, werden mit dieser Anweisung gelöscht DCL - Data Control Language Obwohl in TInTo selber nicht verwendet, sollen die Anweisungen der DCL hier dennoch der Vollständigkeit halber in aller Kürze erwähnt werden, insbesondere da die Erweiterung des TInTo-Projektes um entsprechende Einschränkungen auf bestimmte Wertpapiere oder Indikatoren für ausgewählte Benutzer durchaus denkbar ist (beispielsweise bei der Aufteilung der Wertpapiere auf verschiedene Analysten zur Beobachtung). Die Anweisungen GRANT und REVOKE der DCL steuern dabei die Zugrisrechte auf Datenbankobjekte. Die Rechtevergabe erfolgt mittels der Anweisung GRANT. Der Eigentümer eines Objektes kann dabei einem anderen Benutzer sowohl spezische Rechte an einem Objekt als auch das Recht zur Weitergabe dieser Rechte gewähren. Zulässige Objekte sind hierbei Domänen, Tabellen, Zeichenmengen, Zeichenordnungen sowie Zeichenübersetzungen. Die Anweisung REVOKE dient umgekehrt zum Entzug von Rechten auf Objekten der Datenbank. Der Benutzer, der die REVOKE-Operation auslöst, muss dabei der Benutzer sein, der zuvor die Rechte per GRANT erteilt hat. 15

20 2 Datenbanksysteme 16

21 3 Wertpapiere und Indikatoren In diesem Kapitel werden in kompakter Form die Grundlagen zu Börsen und Wertpapieren, sowie der dazugehörigen Indikatoren erläutert. Die Informationen beruhen im wesentlichen auf [CD06], [TSIG06] sowie [WIKI06]. Der Bereich der technischen Analyse beruht zusätzlich auf Informationen aus [DA06] und [KA01]. 3.1 Wertpapiere Ein Wertpapier ist im weitesten Sinne eine Urkunde, welche ein privates Recht verbrieft. Dies können Forderungsrechte (z.b. Geldforderung aus Sparbüchern oder Anleihen), Beteiligungsrechte (z.b. Miteigentum an oder Stimmrechte in einem Unternehmen bei Aktien), Sachenrechte (z.b. Eigentumsrecht an einem Grundstück) oder Optionsrechte (Optionsscheine) sein. Um das Recht geltend zu machen, ist der Besitz der Urkunde notwendig. Sie dient als Sichtbarmachung und Nachweis eines Rechtes. Eine wichtige Eigenschaft des Wertpapieres ist dessen Übertragbarkeit. 3.2 Börse Eine Börse ist ein organisierter Markt für Wertpapiere wie Aktien, Anleihen oder Devisen sowie für bestimmte Waren, wo vereidigte Makler aufgrund der ihnen vorliegenden Kauf- und Verkaufsaufträge (Orders) aktuelle Kurse feststellen und so einen reibungslosen und funktionierenden Handel gewährleisten. Sie dient also der Konzentration des Handels und soll eine gesteigerte Markttranzparenz, eine höhere Ezienz, eine Verringerung der Transaktionskosten sowie Schutz vor Manipulationen gewährleisten. Der börsliche Handel in Deutschland wird durch die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) sowie durch die Handelsüberwachungsstellen der Börsen kontrolliert. Die klassische Form der Börse ist die sogenannte Präsenzbörse (Parketthandel, elektronisch gestützter Skontroführer 1 -Handel). Hier sind die Makler in Person anwesend und wickeln die Geschäfte durch Gespräche ab. Die wichtigste deutsche Präsenzbörse 1 Skontroführer: Börsenmakler 17

22 3 Wertpapiere und Indikatoren ist die Frankfurter Wertpapierbörse. Der Präsenzhandel wird in den letzten Jahren allerdings mehr und mehr von den computergestützten Systemen, den sogenannten Computerbörsen, abgelöst (vollelektronischer Handel). Das wichtigste deutsche elektronische Handelssystem ist Xetra, welches zur Zeit etwa 96% des gesamten Aktienhandels an deutschen Börsen abwickelt [XETRA06]. Um ein Wertpapier handeln zu können, bedarf es einer eindeutigen Kennzeichnung. Im deutschen Wertpapierhandel wurden Wertpapiere bisher über die sechsstellige Wertpapierkennummer, oder WKN, identiziert. Diese wurde im April 2003 durch die ISIN (International Securities Identication Number) ersetzt. Sie ist eine 12-stellige Buchstaben-Zahlenkombination, welche aus einer zweistelligen Länderkennung, einer nationalen Kennummer sowie einer Prüfzier gebildet wird. Die neue ISIN wurde aus den alten Wertpapierkennnummern abgeleitet, d.h. sofern eine deutsche WKN existierte und das Unternehmen in Deutschland seinen Sitz hatte, wurde die 6-stellige Ziernfolge um weitere 3 Ziern ergänzt. Vorangestellt ndet sich das Länderkürzel, als letzte Zier wurde eine 1-stellige Prüfzier eingefügt. Aus der WKN für die Bayer AG ergibt sich so also die ISIN DE (Präx DE, NSIN sowie Prüfzier 0). Aus praktischen Gründen wird nebenher auch weiterhin die WKN verwendet. Vor allem bei nicht in Deutschland ansässigen Fonds gab es jedoch durch dieses Verfahren Abweichungen von der alten WKN. Im internationalen Handel werden Wertpapiere meist anhand eines eindeutigen Wertpapiersymbols identiziert. Da diese Wertpapiersymbole ihren Ursprung in den USA haben, wird bei abweichenden Handelsplätzen das Symbol oft um ein Kürzel für den Handelsplatz ergänzt. Für die Aktie der Microsoft Corp. ergibt sich beispielsweise für den Handel an der New York Stock Exchange das Symbol MSFT, für den Handel in Franfurt ergibt sich aber das Symbol MSF.F. 3.3 Aktien Die in dieser Arbeit vorrangig betrachteten Wertpapiere sind Aktien. Eine Aktie ist ein Anteilspapier, welches wirtschaftliches Miteigentum an einer Aktiengesellschaft verbrieft. Die Höhe des Anteils am Grundkapital und somit am Gesamtvermögen der Gesellschaft wird durch den Nennwert der Aktie festgelegt. Es gibt allerdings auch nennwertlose Aktien, bei denen sich der Anteil am Grundkapital aus dem Anteil der Gesamtaktien ergibt. Der tatsächliche Marktwert entspricht jedoch dem börsentäglich festgelegten Kurswert der Aktie, sofern die Aktie börsennotiert ist. Der Name Wertpapier stammt daher, dass die Aktie früher meistens als Urkunde mit Angabe von Nennwert oder Stückzahl ausgegeben wurde. Eine solche Aktie ist körperlich unterteilt in Mantel, Dividendenscheinbogen und Erneuerungsschein (zum Bezug neuer Dividendenscheinbögen). Heute werden Aktien meist von Banken in Depots als 18

23 3.3 Aktien Sammel- oder Globalurkunde verwahrt. Man spricht dann von Girosammelverwahrung. Als Anonyme Gesellschaft der Dillinger Hüttenwerke entstand im Jahre 1828 die Dillinger Hütte als erste Aktiengesellschaft Deutschlands, dessen Aktie in Abbildung 3.1 zu sehen ist. Abbildung 3.1: 1906: Erste Aktie Deutschlands der Dillinger Hütte Die Aktie bietet dem Anleger zwei mögliche Ertragsquellen. Zum einen kann das Unternehmen über Dividenden den Aktionär am Gewinn des Unternehmens beteiligen. Die Dividende ist dabei eine pro Aktie geleistete Zahlung an den Besitzer und wird auf der Hauptversammlung festgelegt. Zum anderen kann sich jedoch aus möglichen Kurssteigerungen die weitaus gröÿere Ertragsquelle ergeben, zumindest wenn das Unternehmen protabel arbeitet und die Aktie für einen breiten Anlegerkreis an Attraktivität gewinnt. Innerhalb der Aktien werden unterschiedliche Aktiengattungen unterschieden. Zum einen können Unternehmen alle Aktionäre gleich behandeln und sogenannte Einheitsaktien ausgeben, zum anderen können sie an unterschiedliche Aktionäre unterschiedliche Aktientypen ausgeben. Hier werden vorrangig Stammaktien und Vorzugsaktien unterschieden. Die Dividendenvorzugsaktie, als häugste Art der Vorzugsaktie, hat dabei kein Stimmrecht wie die Stammaktie, als Vorzug jedoch meist eine höhere Dividende. Weiterhin werden Aktien bezüglich ihrer Übertragbarkeit in Inhaberaktien und Namensaktien unterschieden. Inhaberaktien laufen auf deren jeweiligen Inhaber, d.h. der Besitzer der Aktie kann deren Rechte geltend machen. Namensaktien hingegen laufen auf den Namen des jeweils Berechtigten, der im Aktienregister verzeichnet ist. Nur dieser kann die Rechte geltend machen. Zusätzlich wird noch zwischen jungen Aktien und alten Aktien unterschieden. Durch eine Kapitalerhöhung einer Aktienge- 19

24 3 Wertpapiere und Indikatoren sellschaft werden junge Aktien ausgegeben, die nicht im vollem Umfang Dividendenberechtigt sein können. Erst bei voller Dividendenberechtigung gelten die Aktien als gleichgestellt. Als Aktienemission bezeichnet man die Ausgabe von Aktien durch ein ausgebendes Unternehmen, dem sogenannten Emittenten. Ziel ist die Unterbringung der Aktie bei einer möglichst groÿen Gruppe von interessierten Anlegern. Die Schaung neuer Aktien ist nur in drei Situationen möglich: der Neugründung einer Aktiengesellschaft, der Umwandlung einer Gesellschaft einer anderen Rechtsform in eine Aktiengesellschaft oder der Ausgabe von jungen Aktien im Rahmen einer Kapitalerhöhung. Bei der Neugründung einer Aktiengesellschaft, einer Neuemission, können die Interessenten den Neuemissions-Kandidaten zunächst in einer gewünschten Anzahl zu einem sich in einer festgelegten Preisspanne bewegenden Emissionspreis zeichnen. Diese Preisspanne ergibt sich im sogenannten Bookbuilding, das auf standardisierten mathematischen Verfahren beruht. Der tatsächliche Ausgabepreis bewegt sich dann bei einer hohen Nachfrage im oberen Bereich dieser Bandbreite, bei geringen Nachfrage eher im unteren Bereich. Bei einer Kapitalerhöhung können die Unternehmen durch Ausgabe von jungen Aktien ihr Grundkapital aufstocken. Das Unternehmen gibt dazu zu einem festen Emissionskurs neue Aktien aus, deren Kurs, um die Attraktivität zu erhöhen, meist unter dem aktuellen Börsenkurs der alten Aktien liegt. Bei dieser sogenannten ordentlichen Kapitalerhöhung haben Aktionäre das Recht, entsprechend ihrer bisherigen Beteiligung am Unternehmen, neue Aktien zu erwerben. Dies nennt man Bezugsrecht. Wird die Kapitalerhöhung beispielsweise im Verhältnis 5:1 durchgeführt, heiÿt das: Für je fünf alte Aktien wird eine neue ausgegeben und somit das Grundkapital um 20 Prozent erhöht. Auf diese Weise können Altaktionäre für je fünf alte Aktien eine neue erwerben. Zur Ausgabe von Gratisaktien, sogenannten Berechtigungsaktien, kommt es, wenn das Unternehmen oene Rücklagen in Grundkapital umwandelt. Die Altaktionäre müssen in diesem Fall für die neuen Aktien nichts entrichten, da die Kapitalerhöhung aus Gesellschaftsmitteln durchgeführt wurde. Die Gratisaktien werden ausgegeben, um den Aktienkurs für Neuanleger optisch attraktiver zu gestalten. So sorgt eine Ausgabe von Gratisaktien im Verhältnis 1:1 theoretisch für eine Halbierung des Aktienkurses. Die Ausgabe von Gratisaktien ist aber nicht mit dem Aktiensplit zu verwechseln, auch wenn der resultierende Eekt der gleiche ist. Beim Aktiensplit werden existierende Aktien in mehrere neue Aktien umgewandelt. Dies geschieht meist dann, wenn der Kurs einer einzelnen Aktie so hoch ist, dass bereits der Erwerb einer einzelnen Aktie für bestimmte Anleger unmöglich oder unattraktiv wird. Als Resultat des Splits verbilligt sich also die Aktie im Börsenpreis, sie wird leichter. 20

25 3.4 Grundlagen der Wertpapieranalyse 3.4 Grundlagen der Wertpapieranalyse Grundsätzlich lässt sich die Analyse von Wertpapieren in zwei Kategorien unterteilen, zum einen in die fundamentale Analyse, bei der sich Kursentwicklungen aufgrund wirtschaftlicher Zusammenhänge erklären und prognostizieren lassen, zum anderen die technische Analyse, bei der Börsenkurse beobachtet, aufgezeichnet und analysiert werden. Bevor jedoch die dieser Arbeit zugrundeliegende technische Analyse weiter ausgeführt wird, soll in einem kurzen Abschnitt auf die fundamentale Analyse eingegangen werden Fundamentale Analyse Die fundamentale Analyse ist eine traditionelle Analysemethode, um die Werthaltigkeit von Aktien zu erstellen und darauf aufbauend Prognosen für zukünftige Aktienkurse zu erstellen. Die Fundamentalanalyse geht dabei nicht von aktuellen oder historischen Kursen aus, sondern betrachtet vielmehr den Wert einer Aktie aufgrund von wirtschaftlichen Analysen. Hierzu werden zum einen wichtige Kennzahlen des Unternehmens betrachtet, zum anderen werden die Zukunftsaussichten (speziell ein mögliches Gewinnpotenzial) des Unternehmens aufgrund von gegenwärtigen oder zu prognostizierenden wirtschaftlichen Situationen abgeschätzt. Die so errechneten inneren Werte werden dann in Bezug zu dem tatsächlichen Aktienwert des Unternehmens gesetzt, um eine mögliche Über- oder Unterbewertung des Unternehmes zu erkennen und entsprechende Aktienkäufe bzw. -verkäufe zu tätigen. Einige wichtige betriebswirtschaftliche Kennzahlen, welche unter anderem Grundlage der fundamentalen Analyse sind, sollen im folgenden beispielhaft erläutert werden: Bilanzkurs Der Bilanzkurs zeigt, wieviel Eigenkapital auf eine Aktie entfällt. Er ergibt sich aus Eigenkapital geteilt durch Anzahl der ausgegebenen Aktien. Gewinn bzw. Dividende pro Aktie Der Gewinn pro Aktie (Unternehmensgewinn geteilt durch Anzahl ausgegebener Aktien) dient hauptsächlich zum Vergleich verschiedener Unternehmen einer Branche. Kurs-Gewinn-Verhältnis (KGV) Je niedriger das KGV (errechnet aus Aktienkurs geteilt durch Gewinn pro Aktie), desto preiswerter ist die Aktie im Bezug auf mögliche Ertragsaussichten. Ein geringer KGV-Wert kann daher für eine Unterbewertung des Unternehmens und damit für eine Kaufempfehlung sprechen. Weitere Kennzahlen sind z.b. das Kurs-Buchwert-Verhältnis (KBV), der Cashow, die Dividende, der Verschuldungsgrad, die Eigenkapitalquote oder der Return on Investment (ROI). Hierzu ndet sich in der in einer Vielzahl zur Verfügung stehenden Fachliteratur weitere Information. 21

26 3 Wertpapiere und Indikatoren Diese Kennzahlen ergeben sich meist aus der Unternehmensbilanz oder der Gewinnund Verlustrechnung. Sie sind üblicherweise im Geschäftsbericht eines Unternehmens zu nden Technische Analyse Die technische Analyse unterscheidet sich grundlegend von der Fundamentalanalyse. Sie hinterfragt weder die Kursbildung an sich, noch die hinter der Kursbildung stehenden Bestimmungsfaktoren. Lediglich die zur Verfügung stehenden Börsendaten wie Erönungs-, Höchst-, Tiefst- und Schlusskurs sowie das Umsatzvolumen für einen bestimmten Zeitraum werden untersucht. Dabei ist die Grundannahme der technischen Analyse, dass sich vergangene Kursverläufe wiederholen, was wiederum auf das menschliche Verhalten beim Kauf- und Verkauf von Aktien zurückgeführt wird. Der Vater der technischen Analyse ist Charles Dow, der Begründer des gleichnamigen Aktienindex der dreiÿig gröÿten amerikanischen Unternehmen. Er sah in ihr allerdings eher eine Art Handwerkzeug für Analysten als eine wissenschaftliche Theorie. Die technische Analyse von Wertpapieren lässt sich in die folgenden zwei Bereiche aufteilen: Chartanalyse Ziel der Chartanalyse ist es, Regelmässigkeiten im Kursverlauf von Aktien zu erkennen und daraus Handelssignale zu gewinnen. Dazu werden auf den unterschiedlichen Darstellungsformen für Aktienkurse wie Balken-, Linien- oder Kerzencharts entsprechende Analysemethoden wie z.b. Trend, Unterstützungsund Widerstandslinien oder Durchschnitte angewandt. Indikatorenanalyse Die Indikatorenanalyse ist eine mathematische Analyseform, die aufgrund historischer Kurs- und Umsatzdaten Informationen zur Qualität eines Trends liefern soll. Neben diesen klassischen Analyseformen gibt es noch eine Vielzahl anderer Formen der technischen Analyse, wie z.b. Elliott-Wave-Analyse, Zeitzyklen-Analyse und Sentiment-Analyse. Alle Kauf- und Verkaufentscheidungen an der Börse werden von Menschen aus rationalen oder emotionalen Motiven heraus getroen, wobei es oft auch eine Mischung von beidem ist. Selbst die Entscheidungen der computergesteuerten Handelssysteme sind durch menschliche Entscheidungsmuster geprägt, da diese von Menschen programmiert wurden. Der technischen Analyse liegt also die Annahme zugrunde, dass 22

27 3.5 Chartanalyse sich Menschen (in diesem Fall die Anleger) in vergleichbaren Situationen gleich verhalten. Ziel der Analyse ist es, diese sich wiederholenden Muster als entsprechenden Trend zu erkennen und möglichst gewinnbringend darauf zu reagieren. Dabei ist es wissenschaftlich nicht erwiesen und sogar umstritten, ob sich mit der technischen Analyse tatsächlich Aussagen über den zukünftigen Kursverlauf eines Wertpapieres machen lassen [FTC06]. Während die Verteidiger der klassischen Finanzmarkttheorie die Deutungsversuche aus graschen Darstellungen der Kursverläufe als reine Kaeesatz-Leserei verurteilen, beharren gefestigte Chartisten darauf, dass bestimmte technische Eigenschaften eines Kursverlaufes häuger brauchbare Ergebnisse produziere, als es die reine Zufallsverteilung erwarten lieÿe. Die Anzahl der wissenschaftlichen Arbeiten zu diesem Thema nimmt dabei seit Jahren zu, wie eine im Oktober 2004 veröentlichte Studie der beiden Ökonomen Cheol-Ho Park und Scott H. Irwin der Universität Illinois belegt [PI04]. Immerhin kommen 58 von 92 untersuchten Arbeiten seit 1980 zu einem positiven Ergebnis im Bezug auf technische Handelsstrategien, 24 Studien zu einem negativen und weitere 10 Studien sind unentschlossen. Dennoch ist dies kein Beweis für die Überlegenheit der technischen Ansätze, denn die Autoren fanden zum einen starke Schwankungen in den Zeiträumen, in denen die Verfahren gut oder schlecht funktionierten, zum anderen gab es Zweifel an der Qualität der untersuchten Daten. Die Studien lieferten meist in den Fällen gute Ergebnisse, in denen die untersuchten Methoden noch nicht zum Zuge kamen. Die Frage bleibt also, ob die Ansätze auch bei einer breiten Anwendung durch damalige Investoren erfolgreich wären, oder ob tatsächlich eine selbstzerstörerische Natur von technischen Trading-Strategien existiert, die massenhafte Anwendung der Strategien ihren eigentlichen Nutzen also zunichte macht. Dem interessierten Leser seien hier die bereits oben erwähnten Arbeiten [PI04] bzw. [PI05] empfohlen. 3.5 Chartanalyse Unter dem klassischen Charting wird die grasche Marktanalyse auf Grundlage des historischen Kursverlaufes des zu analysierenden Wertes verstanden. Es wird dabei versucht, aufgrund des Kursverlaufs Schlussfolgerungen über die Wechselwirkung von Angebot und Nachfrage zu ziehen und daraus Prognosen über die zukünftige Kursentwicklung zu erstellen. Es existiert eine Vielzahl von Erkennungslinien und Chartformationen zur Chartanalyse ([DA06], [KA01]), von denen im Folgenden einige kurz näher dargestellt werden sollen: Widerstandslinien Die Wiederstands- und Unterstützungslinien gelten als aussagefähige Indikatoren. Man erhält sie durch Einzeichnen der zueinander parallel verlaufenden 23

28 3 Wertpapiere und Indikatoren Trendbegrenzungslinien (obere Linie als Wiederstandslinie und untere als Unterstützungslinie) in einen Chart. Trendbestätigungsformationen Bei den Trendbestätigungsformationen geht es um die Vorhersage, ob der Trend, entweder Aufwärts- oder Abwärtstrend, weiter fortgesetzt wird oder nicht. Zu den Trendbestätigungsformationen gehören (steigendes, fallendes, symmetrisches) Dreieck, Wimpel oder (bull/bear) Flagge. Trendwendeformationen Trendwendeformationen kündigen einen Trendwechsel an. Zur Erkennung eines Aufwärtstrends betrachtet man folgende Formationen: SKS (Kopf-Schulter- Formation), fallendes Dreieck, inverse V-Formationen, Double/Triple-Top oder Rounding Top. Zur Erkennung eines Abwärtstrends werden unter anderem V- Formation,Double/Triple-Bottom, steigendes Dreieck, inverse SKS, Rounding- Bottom oder Untertasse betrachtet. Aufgrund der Vielzahl der möglichen Formationen ist eine genaue Vorstellung im Rahmen dieser Arbeit nicht möglich. Dem Leser sei die zu diesem Thema vorliegende Literatur empfohlen. Dennoch ist hier Vorsicht geboten: Eine oensichtliche Schwäche des Charting liegt in der hohen Subjektivität beim Erkennen der Kursmuster und der bis heute fast unmöglichen exakten mathematischen Testbarkeit dieser Formationen. Die Erkennung gewisser Formationen liegt dabei meist in der persönlichen Einschätzung des Analysten und lässt sich mit Programmen nicht exakt nachvollziehen - der Mensch sieht hier mehr als die Maschine. Zudem werden bei der Erkennung solcher Formationen häug Fehler gemacht. Insbesondere (aber nicht nur) Laien erkennen oft fälschlicherweise eine Vielzahl dieser Muster in einem Kursverlauf und glauben, dass daraus klare Kursziele abzuleiten seien. Wie zuverlässig diese Verlaufsprognosen allerdings sind, lässt sich bisher statistisch nicht belegen. 3.6 Technische Indikatoren Technische Indikatoren sind ein Instrument bzw. Hilfsmittel der technischen Aktienanalyse zur Identikation und Anzeige von Richtung und Kraft einer gerade laufenden Kursbewegung mit dem Ziel, Hilfestellung für konkrete Kauf- und Verkaufsentscheidungen zu geben. Unter dem Begri Technische Indikatoren als Oberbegri versammeln sich eine Vielzahl von Indikatoren. Diese lassen sich zum einen nach ihrer inhaltlichen Aussage, zum anderen nach der Art ihrer Ermittlung bzw. Berechnung unterscheiden. In Bezug auf die inhaltliche Aussage werden die markttechnischen Indikatoren, die sich direkt aus den Kursdaten und dem Umsatzvolumen eines Wertes ermitteln lassen, 24

29 3.6 Technische Indikatoren von den Stimmungsindikatoren, welche sich mit dem Stimmungsbild der Marktteilnehmer bezüglich ihrer Erwartungen zur künftigen Marktentwicklung befassen, unterschieden. In Bezug auf die Art der Berechnung lassen sich die Indikatoren auf absoluter Berechnungsbasis in absolute Indikatoren (Trendfolger) von denen auf relativer Berechnungsbasis in relative Indikatoren (Oszillatoren) unterscheiden: absoluteindikatoren = W ert1 + W ert1 relativeindikatoren = W ert1 W ert1 Der Schwerpunkt dieser Arbeit liegt jedoch auf den markttechnischen Indikatoren, da diese Kategorie die direkteste Kursbewertung darstellt und auf den frei verfügbaren Kurs- und Umsatzinformationen beruht. Die gängigste Gliederung der markttechnischen Indikatoren ist in Trendfolgeindikatoren, Oszillatoren, Trendbestimmungsindikatoren (auch richtungs- und dynamikbestimmende Indikatoren) und Volatilitätsindikatoren. Dabei können die einzelnen Indikatoren nicht immer eindeutig abgegrenzt werden, d.h. ein Indikator kann ebenso als Trendfolger, wie auch als Oszillator ausgerichtet sein. In den folgenden Abschnitten werden diese unterschiedlichen Indikatorenklassen näher vorgestellt. Die jeweilige Interpretation und Berechnung der beispielhaft dargestellten Indikatoren beruht dabei auf Informationen aus [TSIG06] und [CTEC06], die dazugehörigen Bildschirmausdrucke zeigen die jeweilige Indikatorberechnung in TIn- To Trendfolgeindikatoren Trendfolgende Indikatoren sind darauf ausgelegt, die jeweils vorliegende Trendrichtung (aufwärts, seitwärts, abwärts) zu bestimmen. Der bekannteste Vertreter dieser Gruppe ist der gleitende Durchschnitt, ein Indikator der älteren Generation, der jedoch mit seinen aktuelleren, mathematisch aufwändiger berechneten Nachfahren eines gemeinsam hat: alle sind relativ träge und folgen dem Trend mit einer gewissen Verzögerung. Ein weiterer Schwachpunkt ist die fehlende Aussagefähigkeit in sich seitlich bewegenden Märkten. Beispiel: SMA Simple Moving Average Beschreibung: Die einfachste Variante einen Durchschnitt zu berechnen ist das arithmetische Mittel. In der technischen Analyse nennt man diese Berechnungsmethode Simple Moving Average oder aber auch gleitender Durchschnitt (siehe Abbildung 25

30 3 Wertpapiere und Indikatoren Abbildung 3.2: TInTo-Darstellung des SMA Simple Moving Average, Berechnungsperiode n=10, im unteren Diagrammbereich. Zugrundeliegende Kursund Umsatzdaten im oberen Diagrammbereich. 3.2). Der SMA wird als Bestandteil von Handelssystemen verwendet, als Signallinie in Indikatoren und zur Trendbestimmung in Aktien-, Future- und Indexcharts. Berechnung: Die Berechnung des SMA ist sehr einfach durchzuführen. Es wird die Summe der Kurse des Berechnugszeitraumes durch die Anzahl an Handelstagen im Berechnungszeitraum geteilt: SMA(t) = n 1 i=0 Close(t n), n = Berechnungsperiode n Anstatt des Schlusskurses Close können natürlich auch Durchschnitte von anderen Werten berechnet werden. Je länger dabei die Berechnungsperiode ist, desto träger folgt die Durchschnittslinie dem tatsächlichen Kurs. Die Bezeichnung gleitend ergibt sich dabei aus der Berechnung. Mit jedem neuen Handelstag wird ein neuer Wert in die Berechnung aufgenommen und der letzte Wert fällt aus der Berechnung heraus. Interpretation: Zuerst bewirkt der SMA eine Glättung der sehr beweglichen und schwankenden Kursverläufe. So wird der Trend über den gewählten Zeitraum besser erkennbar. Weiterhin dient der SMA aber auch als Widerstands- und Unterstützungslinie. 26

31 3.6 Technische Indikatoren Das Überkreuzen (cross-over) zweier gleitender Durchschnitte wird sehr verbreitet als Handelssignal gewertet. So gilt z.b. das Unterschreiten eines langfristigen Durchschnitts (z.b. n=200) durch einen kurzfristigen Durchschnitt (z.b. n=20) als bearisches Signal. Umgekehrt gilt das Überschreiten des längerfristigen über einen kurzfristigen Durchschnitt als bullisches Signal 2. Die gleitenden Durchschnitte geben Auskunft über den Durchschnittspreis der Aktie in der jeweils gewählten Berechnungsperiode. Ein 200-SMA auf einem Tageschart zeigt also den Durchschnittspreis der letzten 200 Tage an. Der SMA ist unter den Durchschnitten mit fester Berechnungslänge der mit der gröÿten Trägheit. Ein weiterer Nachteil ist die gleiche Gewichtung aller Kurse innerhalb einer Berechnungsperiode. So gehen aktuelle Kurse lediglich mit gleichem Gewicht in die Berechnung ein wie ältere Kurse, obwohl diese stärker gewichtet werden sollten. Fällt ausserdem ein besonders stark abweichender Kurs am Ende der Berechnugsperiode heraus, so kann es sein, dass der SMA von einem auf den anderen Tag gröÿere Abweichungen anzeigt. Es gibt daher neben dem einfachen arithmetischen Durchschnitt SMA weitere Varianten des gleitenden Durchschnitts, welche versuchen, die glättende Eigenschaft des SMA zu erhalten, während die zeitliche Verzögerung reduziert werden soll: WMA Weighted Moving Average Der linear gewichtete Durchschnitt WMA bewertet nicht alle Daten innerhalb einer Berechnung gleich, sondern gewichtet die jüngeren Daten stärker als die älteren: W MA(t) = n 1 i=0 (W (t n) Close(t n)) n 1 i=0 W (t n) wobei beispielsweise W (t) = n, W (t 1) = n 1 usw. sein kann. Bei einem Betrachtungszeitraum von 7 Tagen würde der jüngste Kurs mit 7 multipliziert, der nächste mit 6 usw. Das Gesamtergebnis würde dann in diesem Beispiel durch 7i=1 i = 28 dividiert. Der WMA liegt durch seine Berechnug damit enger am Kursverlauf als der SMA, weist aber dennoch ein weiches Verlaufsmuster auf, was wichtig im Hinblick auf die Anzahl von Fehlsignalen ist. Für Indikatoren mit sehr unruhigem Verlauf ist der WMA als Signallinie dagegen nicht geeignet, da er mehr Fehlsignale produzieren würde als eine trägere Signallinie. EMA Exponential Moving Average Der exponentielle gleitende Durchschnitt EMA kann als Weiterentwicklung des einfachen gleitenden Durchschnitts SMA und des gewichteten gleitenden Durchschnitts WMA betrachtet werden. Während für die 2 Der Begri Bullenmarkt oder Hausse steht an der Börse für steigende Kurse und Bärenmarkt oder Baisse für sinkende Kurse. 27

32 3 Wertpapiere und Indikatoren beiden einfachen Varianten mit jedem neuen Kurs, der in die Berechnung ein- ieÿt, am Ende der Datenreihe ein Kurs aus der Berechnung herausfällt, gilt dies für den EMA nicht mehr. Er wird fortlaufend berechnet, indem zum Wert des gestrigen Durchschnitts ein gewichteter Anteil des heutigen Schlusskurses addiert wird. Dadurch sind im Prinzip alle Daten der gesamten Datenreihe im aktuellen Durchschnittswert enthalten. Durch die exponentielle Gewichtung der hinzukommenden Daten verblassen die älteren Daten mit jedem Tag. Die Berechnung des EMA ist demnach wesentlich komplizierter als die Berechnung des SMA oder WMA. Zunächst wird ein Gewichtungsfaktor festgelegt: Ew(t) = 1 n oder Ew(t) = 2 n + 1 wobei bei Verwendung des zweiten Gewichtungsfaktors, der heute von den meisten Analyseprogrammen angewandt wird, der Indikatorverlauf enger am Kursverlauf liegt. Nach Festlegung des Gewichtungsfaktors wird der eigentliche EMA berechnet: EMA(t) = (Close(t) EMA(t 1)) Ew(t) + EMA(t 1) Die Dierenz aus aktuellem Schlusskurs und gestrigem Wert des Durchschnitts wird mit dem Gewichtungsfaktor multipliziert. Anschlieÿend wird das Ergebnis zum gestrigen Wert des Durchschnitts addiert. Der EMA unterscheidet sich dabei in seiner Verwendung nicht von den zuvor vorgestellten und anders berechneten Durchschnitten Momentum-Oszillatoren Diese Art von Indikatoren schwingen aufgrund ihrer Berechnungsart um eine Mittelpunktslinie oder sie bewegen sich innerhalb eines Bandes, dessen Ränder Extrembereiche kennzeichen. Sie dienen dem Aufzeigen von Extrembereichen, zeigen also nicht die Trendrichtung auf, sondern die der Richtung zugrundeliegende Kraft. Ein Oszillator eignet sich demnach zur Qualitätsbestimmung einer Kursbewegung, er misst dessen Beschleunigung oder Verlangsamung. Oszillatoren sind hauptsächlich in Seitwärtsbewegungen einzusetzen, um überkaufte bzw. überverkaufte Marktsituationen anzuzeigen. Sie können aber auch Divergenzen 3 identizieren oder sogar konkrete Handelssignale generieren. Der klassische Oszillator ist dabei das Momentum. Die meisten anderen Oszillatoren werden auf ähnliche Weise berechnet. 3 Gegenläuge Entwicklung zwischen dem Verlauf des Indikators und der Analyse zugrundeliegendem Basiswert 28

33 3.6 Technische Indikatoren Abbildung 3.3: TInTo-Darstellung des Momentums, Berechnungsperiode n=10, im unteren Diagrammbereich. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Beispiel: Momentum Beschreibung: Das Momentum ist einer der am häugsten verwendeten Indikatoren, obwohl seine Berechnung äuÿerst einfach durchzuführen ist. Vielleicht ist dies aber auch ein Grund für seinen grossen Erfolg - nicht zuletzt gilt unter Chartisten der KISS-Ansatz. Dabei seht KISS für Keep it simple and stupid. Das Momentum beschreibt die Beschleunigung beziehungsweise die Verlangsamung von Kursbewegungen. Diese Kurs- oder Trendbewegungen laufen nicht mit einheitlicher Geschwindigkeit ab. Sie beschleunigen, werden langsamer, erreichen einen Hochpunkt im Aufwärtstrend oder einen Tiefpunkt im Abwärtstrend. Diese sich wiederholenden Zyklen sind durch das Momentum zu messen. Eine weitere Eigenschaft ist der Vorlaufcharakter des Momentums: es erreicht seinen Höhe- bzw. Tiefpunkt oft vor dem eigentlichen Kurs des Basiswertes (siehe Abbildung 3.3). Berechnung: Die Berechnung des Momentums ist sehr einfach durchzuführen. Vom aktuellen Schlusskurs wird der Schlusskurs von vor n Tagen abgezogen: Eine alternative Berechnung wäre auch: Momentum(t) = Close(t) Close(t n) 29

34 3 Wertpapiere und Indikatoren Momentum(t) = Close(t) Close(t n) 100 Meistens werden 10 Handelstage als Vorgabe für n verwendet. Möglich ist aber auch eine längere Einstellung von Kurseinheiten zur Analyse von längerfristigen Trends. Je kürzer n gewählt wird, desto unruhiger schwingt das Momentum um seine Mittellinie. Interpretation: Das Momentum erfasst die Kraft hinter einer Kursbewegung. Bendet sich ein Markt in einem Aufwärtstrend und das Momentum liegt über der Nulllinie, bedeutet ein weiteres Steigen des Indikators, dass die Kurse sich mit zunehmender Beschleunigung bewegen. Für einen Abwärtstrend gilt das Gleiche: ein unter der Nulllinie liegendes und weiter fallendes Momentum bedeutet, daÿ die Beschleunigung der Kursverluste anhält. Das Momentum erreicht dabei seine Hoch- und Tiefpunkte, wenn die Kraft, die hinter der Kursbewegung steht, am gröÿten ist. Dabei läuft das Momentum dem Kurs voraus, d.h. der Kurs kann noch eine Weile weiter in eine Richtung steuern, während das Momentum bereits dreht und in die Gegenrichtung steuert. Dies lässt sich auch im obigen Beispiel in Abbildung 3.3 gut beobachten. Eines der häugsten Anwendungsgebiete des Momentums ist die Suche nach Konvergenz bzw. Divergenz zum Basiswertkursverlauf. Wie bereits angedeutet, beschreibt Konvergenz dabei Gleichläugkeit von Indikator- und Basiswert (eine Extrembewegung des Basiswertes wird durch eine ähnliche Bewegung im Indikator begleitet), Divergenz die Gegenläugkeit (Kursverläufe werden nicht vom Indikator bestätigt). Bildet das Momentum noch neue Höchst- bzw. Tiefststände, der Basiskurs aber nicht mehr, so ist mit einem baldigen Trendwechsel zu rechnen Trendbestimmungsindikatoren Oft stehen die Aussagen der Trendfolgeindikatoren, welche beispielsweise intakte Trends aufweisen, im Widerspruch zu den Aussagen der Oszillatoren, die bereits gegenläuge Signale generieren. Hier helfen Trendbestimmungsindikatoren wie der ADX Average Directional Movement Index bei der Klärung der Frage, ob ein Trend oder eine trendlose Phase vorliegt. Sie zeigen also Trendwechsel und Trendstärke und liefern dabei Hintergrundinformationen wie Trendrichtung bzw. Bewegungsdynamik. Trendbestimmende Indikatoren werden immer mit den Oszillatoren und trendfolgenden Indikatoren in Kombination gesehen. 30

35 3.6 Technische Indikatoren Abbildung 3.4: TInTo-Darstellung des ADX Average Directional Movement Index, Berechnungsperiode n=14, inklusive der Directional Movements +DM und -DM im unteren Diagrammbereich. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Beispiel: ADX Average Directional Movement Index Beschreibung: Beim ADX handelt es sich um einen Teil des in den späten 70er Jahren von Welles Wilder im Rahmen des sogenannten Direction-Movement-Systems erdachten Indikatorkonzepts, welches sowohl Trendstärke als auch Trendrichtung zu bestimmen vermag. Dabei zeigt der ADX nur die Trendstärke an und wird daher oft als Filter für Seitwärtsbewegungen verwendet. Der für den ADX noch zuvor berechnete Indikator DMI (Directional Movement Index) zeigt zusätzlich zur Trendstärke auch noch die Trendrichtung. Da er aber sehr unruhig im Verlauf ist, wird meist die hier vorgestellte geglättete Variante ADX verwendet (siehe Abbildung 3.4). Ist der ADX im Steigen begrien und bendet er sich über 20 Punkten, liegt eine Trendbewegung vor. Wenn der ADX abfällt und/oder unterhalb von 20 notiert, handelt es sich um eine Seitwärtsbewegung. Berechnung: Der ADX wird in mehreren Schritten berechnet: 1. Berechnung des Directional Movements +DM und -DM. Sie bestimmen die gerichtete Bewegung des Handelstages in zwei Variablen. Diese tauchen im eigentlichen Indikator nicht mehr auf und dienen nur als Hilfsgröÿen in der Berechnung. 31

36 3 Wertpapiere und Indikatoren +DM(t) = DM(t) = { High(t) High(t 1) für High(t) > High(t 1) 0 sonst { Low(t 1) Low(t) für Low(t) < Low(t 1) 0 sonst 2. Berechnung der True-Range. Diese von Wilder erdachte echte Handelsspanne berücksichtigt neben der normalen Hoch-Tief-Spanne, also der maximalen Handelsspanne einer Handelsperiode, noch die Kurslücken zwischen Schlusskurs und folgendem Erönungskurs: T ruehigh(t) = Max(High(t), Close(t 1)) T ruelow(t) = Min(Low(t), Close(t 1)) T ruerange(t) = T ruehigh(t) T ruelow(t) 3. Berechnung der Directional-Indikatoren (+DI und -DI) durch Division der Directional Movements DM durch die True-Range TR: +DI(t) = +DM(t) T R(t) DI(t) = DM(t) T R(t) Die Indikatoren +DI und -DI zeigen dabei hauptsächlich die Trendrichtung an. Da es sich bei den Linien um eine geglättete Summierung der Kursveränderungen nach oben und nach unten handelt, entscheidet ihre Lage zueinander über die Aussage zur Trendrichtung. Diese Indikatoren sind allerdings zu unruhig, daher ist eine Glättung angemessen. Wilder hat dazu einen Zeitraum von n=14 Tagen vorgeschlagen: +DI(t) = n 1 i=0 +DM(t n) n n 1 i=0 T R(t n) n 100 DI(t) = n 1 i=0 DM(t n) n n 1 i=0 T R(t n) n Aus +DI und -DI ergibt sich der Directional Movement Index DMI, welcher aufgrund seiner Volatiltät nur selten dargestellt wird: DMI(t) = (+DI(t)) ( DI(t)) (+DI(t)) + ( DI(t)) Durch Glättung des DMI ergibt sich schliesslich der ADX: ADX(t) = n 1 i=0 DMI(t n) n 32

37 3.6 Technische Indikatoren In der ADX-Werteskala können Extrembereiche markiert werden, wobei die untere Begrenzungslinie einen Bereich ohne nennenswerte Trendaktivität markiert, die obere Begrenzung einen Bereich starker Trendaktivität. Die Werte für den unteren Bereich bewegen sich zwischen 15 und 30 und die der oberen zwischen 30 und 45. Interpretation: Der ADX ist einer der meistverwendeten Trendstärkeindikatoren, er kann jedoch keine Trendrichtung anzeigen. Ein aufwärtsgerichteter ADX zeigt also nur steigende Trendintensität. Er besagt nicht, dass ein Aufwärtstrend vorliegt. Ein fallender ADX zeigt eine nachlassende Trendintensität an, aber keinen Abwärtstrend. Der ADX wird ausserdem für das Anzeigen von trendgerichteten Bewegungen oder der Bewertung von Kursausbrüchen und Breakouts 4 verwendet. Weiterhin hilft der ADX zu entscheiden, welche Handelsansätze zu verwenden sind: bei fallendem ADX oder sehr niedrigen Werten sind Oszillatormodelle protabel, bei steigendem ADX sind Trendfolgemodelle erfolgreich. Durch die zahlreichen Glättungsoperationen in der Berechnungskette unterliegen die Signale jedoch einer nicht unerheblichen zeitlichen Verzögerung. Durch schnelle und besonders steile Kursbewegungen ist der Indikator daher überfordert und liefert in diesen Fällen keine brauchbaren Ergebnisse Volatilitätsindikatoren Volatilitätsbezogene Indikatoren werden genutzt, um die aktuelle Schwankungsintensität des analysierten Basiswertes zu bestimmen. Sie beschreiben also, in welcher Volatilitätsphase man sich gerade bendet. Über die Richtung des Kurses können sie keinen Hinweis geben. Je volatiler dabei ein Finanzwert ist, desto gröÿer sind die Risiken. Ein Beispiel für einen Volatilitätsindikator ist die Average True Range (ATR). Beispiel: ATR Average True Range Beschreibung: Die True-Range und ihre geglättete Form, die Average-True-Range (ATR, siehe Abbildung 3.5), wurden von Welles Wilder 1978 in dem Buch New Concepts in Technical Trading Systems vorgestellt. Wilder suchte nach einer Möglichkeit, die Schwankungsbreite der Rohsto- und Terminmärkte in einem Indikator abzubilden, wobei alle geläugen Methoden, wie etwa einfache arithmetische Durchschnitte der Tageshandelsspanne, nur unzureichende Ergebnisse lieferten. Weiterhin wurden Kurslücken zwischen Schlusskurs und folgendem Erönungskurs vernachlässigt. Wilder fügte daher für die Berechnung der wahren Handelsspanne einige Bedingungen 4 Ausbrechen des Kurses 33

38 3 Wertpapiere und Indikatoren Abbildung 3.5: TInTo-Darstellung des ATR Average True Range, Berechnungsperiode n=10, im unteren Diagrammbereich. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. ein, die unter anderem gerade diese Kurslücken berücksichtigen sollen. Ausgehend von der normalen Hoch-Tief-Spanne, also der maximalen Handelsspanne einer Handelsperiode, sollen diese zusätzlich eingeführten Bedingungen prüfen, ob eventuell Kurslücken zur vorherigen Handelsperiode zu berücksichtigen sind. Berechnung: Wie schon in dem vorherigen Abschnitt vorgestellten ADX muss zunächst die True-Range berechnet werden: T ruehigh(t) = Max(High(t), Close(t 1)) T ruelow(t) = Min(Low(t), Close(t 1)) T ruerange(t) = T ruehigh(t) T ruelow(t) Um die Average True Range ATR zu erhalten, wird auf der True-Range meist ein einfacher gleitender Durchschnitt (SMA) mit der Periodenvorgabe n berechnet: AT R(t) = n 1 i=0 T ruerange(t n) n Meist wird für die ATR eine Berechnungsdauer zwischen 5 und 30 Handelstagen verwendet. 34

39 3.7 Handelssysteme Interpretation: Die ATR zeigt die wahre Handelsspanne eines Basiswertes oder eines Marktes, womit sie ein Maÿ für die Volatilität ist. Da dabei in der ATR auch auftretende Kurslücken berücksichtigt werden, zeichnet sie ein sehr genaues Abbild der Marktaktivität. Ähnlich wie mit dem ADX ist es mit dem ATR möglich, eine Aussage über Trendaktivität und Stärke zu treen. Jedoch ist es nicht möglich, eine Aussage über die Bewegungsrichtung im Markt zu machen. Die ATR kann weiterhin, wie auch andere Volatilitätsindikatoren, in Handelssystemen eingesetzt werden. Ausserdem kann sie für die Berechnung und Darstellung verschiedener volatilitätsbasierter Bänder und Kanäle, dann aber multipliziert mit einem Faktor (meist zwischen 1.5 bis 3), verwendet werden. 3.7 Handelssysteme Ein Handelssystem (oder auch Handelsplan) soll den Handel mit Wertpapieren erfolgreicher und eektiver machen. Es besteht aus einer Anzahl von Regeln, Bedingungen und Anweisungen für den Handel mit Wertpapieren. Diese können vom menschlichen Anwender (manuelles Handelssystem) oder von einem Computerprogramm (mechanisches oder algorithmisches Handelssystem) ausgeführt werden. Dabei stützen sich die meisten Handelssysteme auf die fundamentale oder technische Analyse einschlieÿlich ihrer Indikatoren, um Kauf- oder Verkaufsentscheidungen zu generieren. Neben spezischen Kauf- und Verkaufsregeln lassen sich bei den gängigen Handelssystemen folgende übergreifende Strategien feststellen (dabei kann ein Handelssystem sich natürlich auch nach mehreren dieser Strategien richten): Trendfolger Trendfolge-Handelsansätze versuchen, möglichst gewinnbringend in bereits erkennbare Kurstrends einzusteigen. Bei steigenden Kursen kaufen sie und bei fallenden Kursen verkaufen sie, steigen also aus, sobald der Trend bricht. Da es unmöglich ist, einen Trend zu erkennen, bevor er sich ausgebildet hat, bezeichnet man Trendfolger-Systeme oft auch als Trittbrettfahrer. Sie nehmen es in Kauf, nicht die gesamte Bewegung (also vom tiefsten Tief eines Kurses bis zu seinem höchsten Hoch) mitzumachen, sondern immer nur einen Teil davon. Pullback Ein Pullback-Handelssystem wartet auf eine auÿergewöhnliche Preisbewegung und nutzt eine kurz darauf folgende gegenläuge Korrekturbewegung. Channel-Breakout Wenn die Preise einen vorher festgelegten Bereich, den Channel, verlassen, wird jeweils nach zugrundeliegendem Wertpapier und Zeitfenster entweder mit oder gegen diese Preisbewegung gehandelt. Zyklen Dieser Ansatz geht davon aus, dass in der Preisbewegung Zyklen enthalten sind, die sich in bestimmen Perioden wiederholen. Diese Zyklen macht sich das System zunutze. 35

40 3 Wertpapiere und Indikatoren Patterns Patterns sind Preismuster, die von den aufeinanderfolgenden Kurswerten in einem Chart gebildet werden (vgl. Kapitel 3.5). Man geht davon aus, dass gleichartige Muster aus Erönungs-, Hoch-, Tief- und Schlusskurs eines Wertpapiers auch ähnliche Verläufe in der Zukunft erwarten lassen, da die Marktteilnehmer in gleichgelagerten Situationen auch gleich agieren - so zumindest die Annahme. Die Entwicklung eines mechanischen Handelssystems erfolgt dabei durch Anwendung der Regeln auf historische Kursdaten (Backtesting). Dabei werden die Parameter und Regeln des System auf bestimmte Kriterien wie z.b. Performance oder Kontinuität (möglichst gleichmäÿiges Verhalten) optimiert. Dabei besteht die Gefahr der Überoptimierung an die historischen Daten, welches im ungünstigsten Fall in einem System resultiert, das bei neuen Daten keine guten Ergebnisse liefert. Die Anfälligkeit des Systems bezüglich der Überoptimierung lässt sich durch verschiedene Strategien verringern. Es ist ratsam, nur wenige stabile Parameter zu verwenden, wobei kleine Parameteränderungen das System nur möglichst wenig beeinussen sollten. Gleichzeitig sollte der Backtesting-Zeitraum relativ groÿ sein, um möglichst viele Marktsituationen abzudecken. Dennoch sollten aber nicht alle historischen Daten betrachtet werden, um eine Restmenge der Daten mit dem resultierenden System zu testen. Diese Strategie der Walk-Forward-Optimierung verringert die Gefahr der Überoptimierung an die historischen Daten. Ein Handelssystem sollte zusätzlich immer mit eiserner Disziplin sowie mit einem geeigneten Money Management einhergehen. Mit eiserner Disziplin ist dabei das konsequente Setzen und Einhalten von Stop-Loss-Kursen gemeint: es ist wenig ratsam darauf zu warten, dass nach einem Verlust die Kurse wieder nach oben laufen, viel sinnvoller ist der sofortige Verkauf nach einem schiefgelaufenen Geschäft. Unter Money Management versteht man hingegen die Sicherung von angesammeltem Kapital. Es soll dabei sowohl das hinterlegte als auch das bereits gewonnene Geld gesichert werden. Dabei befasst sich das Money Management unter anderem mit den folgenden Themen: Wieviel Geld sollte pro Transaktion maximal riskiert werden? Welcher (ggf. prozentuale) Anteil des verfügbaren Kapitals darf investiert werden? Wie werden Positionen auf- und wieder abgebaut? Ein sinnvolles Money Management erlaubt dabei durchaus kleinere Verluste, da diese wesentlich einfacher auszugleichen sind als groÿe Verluste. Um beispielsweise einen Verlust von -20% auszugleichen muss mit dem Restkapital 25% Gewinn eingefahren werden, ein Verlust von -50% erfordert hingegen bereits einen 100%-igen Gewinn des 36

41 3.7 Handelssysteme Restkapitals. Dabei gehen viele Anleger nach derartigen Verlusten oft ein höheres Risiko ein, um den Verlust wieder auszugleichen (Harakiri-Mentalität). Diese Risikobereitschaft zieht oft erneute Verluste nach sich, gefolgt von noch höherer Risikobereitschaft. Dieses Anlegerverhalten endet oft im Totalverlust des eingesetzen Kapitals. Inzwischen werden durch mechanische Handelssysteme nicht unerhebliche Transaktionsvolumina umgesetzt. Dieser algorithmische Handel wird weiterhin erheblich zunehmen. Bereits heute wächst der Anteil der automatisch erzeugten Quotes und Orders mit zweistelligen Raten. Aktuell liegt der Anteil des automatisch generierten Handelsvolumens auf Xetra bereits bei 37 Prozent [XETRA06]. 37

42 3 Wertpapiere und Indikatoren 38

43 4 Entwurf von TInTo 4.1 Idee und Zielsetzung Ziel dieser Arbeit ist die Entwicklung des datenbankgestützten Werkzeugs TInTo (Technical Indicator Tool) zur regelbasierten Analyse von Wertpapierkursen. Dabei soll TInTo technische Indikatoren auf der Basis von Kurs- und Umsatzdaten möglichst ezient und unter ausschlieÿlicher Verwendung der Datenbanksprache SQL berechnen. Die hierzu notwendigen Kurs- und Umsatzdaten sollen dabei aus einer geeigneten Quelle (vorzugsweise dem Internet) eingelesen, gegebenenfalls geltert und abschliessend in der Datenbank vorgehalten werden. Die Verarbeitung von Intraday-Kursdaten ist nicht erforderlich, unterscheidet sie sich doch nicht grundsätzlich von der Verarbeitung normaler End-Of-Day-Kursdaten. Auf den so eingelesenen Kurs- und Umsatzdaten soll dann eine Hierarchie von Sichten aufgebaut werden, mit denen (im Idealfall) beliebige technischen Indikatoren berechnet werden können. Dabei sollen nur die Mittel und Möglichkeiten des DBMS ausgeschöpft werden, konkret also Abfragen in der Abfragesprache SQL formuliert werden. Bei dem Entwurf von TInTo soll auf gröÿtmögliche Flexibitität für den Anwender geachtet werden: er soll nicht in seiner Verwendung von Abfragen zur Indikatorberechnung durch das Werkzeug eingeschränkt werden - der volle Umfang von SQL soll zur Verfügung stehen. Gleichzeitig sollte die Funktionalität, in die der Anwender nicht eingreifen muss, unbedingt im Hintergrund transparent ablaufen. Dies gilt zunächst für die gesamte Kommunikation mit dem Internet, einschlieÿlich dem Einlesen, Filtern und Speichern der Wertpapier-Stammdaten sowie der Kurs- und Umsatzdaten. Der Anwender soll keine Verbindungsparameter eingeben müssen. Rückfragen sollten nur im Fall von Mehrdeutigkeiten erfolgen. Weiterhin soll TInTo Abhängigkeiten in der Abfragehierarchie selbsständig erkennen können und automatisch dafür sorgen, daÿ aufeinander aufbauende Abfragen vor der Ausführung dem DBMS vollständig bekannt und angelegt sind, da es ansonsten zu Fehlern in der Ausführung kommen kann. Weiterhin sollte TInTo möglichst einfach und intuitiv anwendbar sein. Bereits angelegte Indikatoren sollen einfach aufgerufen und angezeigt werden können, ohne die Oberäche mit den Details der Abfrageformulierung zu überladen. Daher bietet sich eine Implementierung mit einem Hauptformular an, welches alle notwendigen Parameterund Anzeigeelemente enthält, die zur Darstellung bereits vorhandener Indikatorsich- 39

44 4 Entwurf von TInTo ten notwendig sind. Das Anlegen und Modizieren der Indikatorsichten sollte jedoch in ein separates Formular ausgelagert werden. Hier sollen dann alle Möglichkeiten der SQL-Formulierung sowie der Parametrierung der Indikatoren (beispielsweise Darstellungsparameter) zur Verfügung stehen. Die Anzeige der Kurs-, Umsatz- und Indikatorwerte durch TInTo sollte möglichst in grascher Form erfolgen. Nicht umsonst ist dies die übliche Darstellungsform für derartige Daten, da sowohl die Kursverläufe, als auch die Indikatorlinien visuell vom Anwender viel schneller aufzunehmen sind. Dennoch sollten die exakten Werte der Kurs-, Umsatz- und Indikatordaten wenn möglich zusätzlich in tabellarischer Form zur Verfügung stehen. Der Entwicklung von TInTo gehen zwei Diplomarbeiten voraus. Die Arbeit von Andreas Krumme [KR04] befasste sich hauptsächlich mit der Vorstellung der unterschiedlichen Wertpapierarten und deren Modellierung als Datenbankobjekte. Die Folgearbeit von Alexander Geppert [GE05] reduzierte die Anzahl der unterschiedlichen Wertpapiertypen erheblich und legte dafür ein Datenbankschema inklusive beispielhafter Abfragedenitonen einiger Indikatoren vor. Auch diese Arbeit war, wie bereits die Arbeit von Andreas Krumme, rein theoretischer Natur: einige der Sichtendenitionen konnten dabei aufgrund der fehlenden Implementierung des verwendeten SQL- Funktionsumfangs von keinem kommerziellen DBMS umgesetzt werden. Mit TInTo soll hingegen ein konkretes, auf aktuell verfügbaren Systemen lauähiges, Werkzeug geschaen werden. Es müssen daher realisierbare und speziell im Bezug auf die Abfrageformulierung tatsächlich umsetzbare Konzepte erarbeitet werden. Das verwendete Datenbankschema sowie die denierten Sichten müssen auf einem kommerziellen DBMS implementierbar und ausführbar sein TInTo als Bestandteil eines Handelssystems TInTo kann in seiner im Rahmen dieser Arbeit zu implementierenden Form als Teil eines wesentlich umfangreicheren Gesamtsystemes gesehen werden. Funktional ist TInTo im Bereich der Wertpapieranalyse anzusiedeln, daher ist ein vollständiges Handelssystem als umfassender inhaltlicher Rahmen für dieses Werkzeug zu sehen (siehe auch Kapitel 3.7). Neben den bei TInTo betrachteten End-Of-Day-(EOD)-Daten, also den am Ende eines Tages ermittelten Kurs- und Umsatzdaten in Form von Tagesenddaten, sollte ein Handelssystem unbedingt auch auf den zeitnahen Intraday-Daten, die jeden einzelnen Handelsabschluss, oder Tick, an der Börse enthalten, operieren können. Aus dieser Forderung heraus ergeben sich jedoch weitere Probleme. Zum einen müsste das Einlesen der Kursinformation auf den Umgang mit Intraday-Daten umgestellt werden, da die Kursdaten möglichst zeitnah in die Datenbank aufgenommen und darauf dann die 40

45 4.1 Idee und Zielsetzung notwendigen Indikatoren berechnet werden sollen. Schnelligkeit ist bei einem Handelssystem von enormer Wichtigkeit. Zum anderen müsste die Datenstruktur sowohl EODals auch Intraday-Daten parallel in einer Tabelle speichern können, damit die Sichten nicht mehrfach deniert werden müssen. Ohne eine entsprechende Modikation der Sicht sind die zugrundeliegenden Quellrelationen nicht ohne weiteres austauschbar. So ist es beispielweise nicht möglich, die gleiche Abfrage einmal auf einer Tabelle TKurs auszuführen, ein anderes mal auf einer Tabelle TIntrakurs. In TInTo werden Intraday-Kurse nicht betrachtet, obwohl die in TInTo erarbeiteten Berechnungsmethoden für Indikatoren durchaus auch auf Intradaykurse anwendbar sind. Die gerade geschilderten Probleme bestehen ausserhalb der Sichtendenitionen und haben keinen Einuss auf die eigentliche Formulierung der Indikatorsichten. Das Einlesen der Intraday-Daten müsste dann entweder mit höherer Einlesefrequenz geschehen, oder die neuen Intraday-Daten müssten ereignisgesteuert (in einer Art Push- Betrieb) in die Datenbank aufgenommen werden. Ein Handelssystem, welches auf den in TInTo berechneten technischen Indikatoren aufbaut, sollte ausserdem in der Lage sein, dem Anwender möglichst gewinnbringende Kauf- oder Verkaufsentscheidungen zu liefern. Dazu muss das Handelssystem die Berechnung von (möglicherweise) mehreren Indikatoren mit einem zuvor festgelegten Regelwerk eines Money-Managements kombinieren (siehe dazu auch Kapitel 3.7). Unter Umständen wäre das System sogar in der Lage, vollständig autonom zu arbeiten und entsprechende Kauf- oder Verkaufsentscheidungen selbstständig am Markt zu vollziehen, beispielsweise indem diese direkt über eine geeignete Schnittstelle an die Börse übergeben würden. TInTo soll die Berechnung von technischen Indikatoren durch möglicherweise mehrstuge, also hierarchisch aufgebaute Sichten ermöglichen. Es unterstützt dabei keine parallele Berechnung von mehreren unterschiedlichen Indikatoren, sondern kann stets nur einen Indikator anzeigen. Weiterhin enthält TInTo auch keine Möglichkeit zum Anlegen, Modizieren, Speichern und Auswerten von Regeln des Money-Managements. Mit TInTo, oder allgemeiner, mit Hilfe der in dieser Arbeit vorgestellten Methoden als Grundlage, lässt sich allerdings ein solches System durchaus entwickeln und implementieren. Die notwendigen Erweiterungen können dabei auf die TInTo-Funktionalität aufgesetzt werden. Dies soll jedoch nicht Teil dieser Arbeit sein Problemklasse der Data Streams Auch wenn sich TInTo inhaltlich dem Bereich der Wertpapieranalyse, konkret der Berechnung von technischen Indikatoren, zuordnen lässt, so sind die zu bewältigenden Probleme doch in einer Vielzahl anderer Bereiche zu nden. TInTo wird dabei zu einem beispielhaften Vertreter einer ganzen Problemklasse. 41

46 4 Entwurf von TInTo Die von TInTo verarbeiteten Daten stehen in Form eines Datenstromes (engl. Data Stream), also einer kontinuierlichen Abfolge von Datensätzen, zur Verfügung. Dabei ist die Datenrate der hier betrachteten End-Of-Day-Kurse noch relativ gering. Es entsteht ein neuer Satz von Kurs- und Umsatzdaten pro Tag. Die Datenrate kann sich aber beispielweise bei der Verwendung von Intraday-Kursdaten sehr schnell erhöhen. Dieser Datenstrom muss eingelesen, gegebenenfalls geltert und abschliessend in die Datenbank aufgenommen werden. Auf den in der Datenbank auf diese Weise eingelesenen Quelldaten wird nun mit Hilfe von, möglicherweise hierarchisch verschachtelten, Sichten eine Anzahl von Informationen berechnet. Im Fall von TInTo sind dies technische Indikatoren. In der Regel ist die Berechnung dieser Informationen sogar von den gerade neu eingelesenen Daten abhängig und muss immer wieder aktualisiert werden. Die berechnete Information muss schliesslich in einer geeigneten Form für den Anwender aufbereitet und visualisiert werden. In TInTo werden die Kurs-, Umsatz- und Indikatordaten hierzu grasch in einem Chart dargestellt, was für den Anwender die zugänglichste und am schnellsten aufnehmbare Darstellungsform ist. Zusätzlich unterstützt TInTo aber auch die tabellarische Darstellung der Daten und Indikatorwerte. Diese Art der Informationsverarbeitung vom Datenstrom über die Berechnung auf den Daten bis hin zur Visualisierung ndet sich in einer Vielzahl von Anwendungsbereichen wieder (siehe auch [AG06]): Verkehrsmonitoring Monitoringsysteme überwachen Verkehrsnetze oder Straÿen und Autobahnen und generieren aus den Quelldaten aktuelle Zustandsmeldungen oder sogar Prognosen über Verkehrsdichte und Staus. Transportunternehmen überwachen mit einem ähnlichen System gegebenenfalls ihre Flottenbewegungen. Umweltmonitoring Aufgrund diverser Umweltdaten generiert ein Monitoringsystem Informationen zu Wetter oder Umweltkatastrophen, aber auch zu möglichem Tierverhalten (Vogelzüge, etc.). Monitoring im Handel Lagerdaten dienen einem entsprechenden System als Grundlage für Bestandsverwaltung oder für automatisierte Bestellvorschläge. Spielfeldüberwachung Im Rahmen der Spielfeldüberwachung ist zum Beispiel die hochgenaue und zeitlich hochauösende 3-D-Lokalisierung dynamischer Objekte aus geeigneten Senderdaten, bespielsweise im Ball, notwendig. Durch weitere Sender wäre auch eine Spielerüberwachung (Tracking) möglich. 42

47 4.2 Anforderungsprol und Use-Cases Die bei dem Entwurf und der Implementierung von TInTo auftretenden Probleme und deren Lösung sind also durchaus auf eine Reihe von anderen Anwendungsfällen dieser Problemklasse übertragbar, sofern sie ähnlich aufgebaute Daten und Berechnungsvorschriften vorweisen. Die Analyse von Wertpapieren durch die Berechnung von technischen Indikatoren ist im Rahmen der Auseinandersetzung mit den auftretenden Problemen daher nur exemplarisch zu sehen. Genauso wäre die Anwendung auf dynamischen Verkehrs-, Umsatz- oder Handelsdaten möglich - überall also, wo mengenorientierten Operationen notwendig sind und die Anwendung eines DBMS zur Berechnung dieser Daten möglich und sinnvoll ist. Dennoch kann die Implementierung von TInTo auf einem kommerziellen DBMS nur ein Zwischenschritt in der Lösung der Probleme bei der Berechnung von mengenorientierten Daten auf Datenströmen sein. Vielmehr sind langlaufende, kontinuierliche Abfragen statt der in den aktuell verfügbaren Werkzeigen unterstützten Einzelabfragen nötig. Diese Funktionalität kann jedoch von den aktuell verfügbaren kommerziellen DBMS bestenfalls simuliert werden, da für die Berechnung auf Datenströmen zur Zeit lediglich Prototypen zur Verfügung stehen (beispielsweise [STR06]). 4.2 Anforderungsprol und Use-Cases Ziel des Programms TInTo (Technical Indicator Tool) ist das Einlesen und Anzeigen von Kursdaten aus dem Internet sowie die Berechnung und Anzeige diverser dazugehöriger technischer Indikatoren. Der Anwender muss in der Lage sein, Wertpapiere anhand des Wertpapier-Symbols auszuwählen, woraufhin das System das Symbol überprüft. Sofern das Wertpapier noch nicht in der Datenbank vorhanden ist, liest das System die Wertpapier-Stammdaten sowie die Kursdaten ein und zeigt diese als Chart an. Zusätzlich sollte der Anwender Chartoptionen wie den Darstellungstyp (Candlestick 1, OHLC 2, etc.), die Anzeige (linear oder logarithmisch) und den Anzeigezeitraum auswählen können. Indikatoren sollen vom Anwender als Abfrage in der Datenbanksprache SQL deniert und bearbeitet werden können. Zu den Indikatoren sollen Darstellungsoptionen wie Farbe, Bezeichnung oder Diagrammtyp auswählbar sein. Diese vordenierten Sichten sollen dann als Liste dargestellt und vom Anwender auszuwählen sein. Der ausgewählte Indikator wird dann passend zum Anzeigeintervall dargestellt. Dazu sollte die Möglichkeit bestehen, die Sicht entsprechend einzuschränken, damit keine unnötigen Daten berechnet werden. 1 Die Spanne zwischen Erönungs- und Schlusskurs wird als kleines Rechteck (Körper) dargestellt, darüber hinausragende Schwankungen werden als Docht oder oberer Schatten, darunter ragende Schwankungen als Lunte oder unterer Schatten dargestellt 2 Balken- oder Bar-Chart mit Darstellung des Erönungskurses der Periode durch eine waagrechte Markierung links des Balkens, des Schluÿkurses durch eine Markierung rechts 43

48 4 Entwurf von TInTo Zum Einlesen der Wertpapier-Auswahl (bei einem vom Anwender eingegebenen mehrdeutigen Symbol), der dann zum gewählten Wertpapier gehörenden Wertpapier- Stammdaten sowie der Kurs- und Umsatzdaten wird eine Internet-Schnittstelle benötigt, die per HTML mit dem Internet kommuniziert und die notwendigen Wertpapierund Kursdaten in die Datenbank übernimmt. Datenanbieter soll in diesem Fall Yahoo- Finance sein, da die notwendigen Daten hier kostenfrei über eine einfach zu parametrierende HTTP-Schnittstelle zur Verfügung stehen. Das folgende Anwendungsfalldiagramm (Use-Case-Diagram) soll die benötigte Funktionalität in Bezug auf die Interaktion mit dem Anwender weiter spezizieren. Use- Case-Diagramme sind Teil der Unied Modeling Language (UML), einer Sprache für die Modellierung der Strukturen und des Verhaltens von Software- und anderen Systemen ([JE05]). Ein Use-Case-Diagramm enthält dabei die grasche Darstellung des Systems, der Use-Cases, der Akteure auÿerhalb des Systems und der Beziehungen zwischen Akteur und Use-Case, der Akteure untereinander oder Use-Cases untereinander. Das System wird als rechteckiger Kasten abgebildet, wobei die Kanten des Systems die Systemgrenzen darstellen. Der Name des Systems wird innerhalb des Kastens angegeben. Ein Use-Case (Anwendungsfall) selbst kapselt eine in sich geschlossene Sammlung von Aktionen, die in einer spezizierten Reihenfolge ablaufen. Er stellt somit seiner Umwelt eine Dienstleistung, also ein Verhalten, zur Verfügung. Ein Akteur interagiert mit dem System, steht aber immer auÿerhalb davon. Im Use-Case-Diagramm, wie es in Abbildung 4.1 dargestellt ist, werden die Anwender (Akteure), die Use-Cases und deren Beziehungen zueinander darstellt (vgl. auch [BD00]). In dem TInTo-Anwendungsfalldiagramm sind Anwender und Administratoren getrennte Akteure. Ein Akteur interagiert mit dem System, steht aber immer auÿerhalb davon. Dabei stellt ein Akteur lediglich eine Rolle dar, die mit dem System interagiert. Ein Akteur muss also nicht zwangsläug eine natürliche Person sein. Ebenso gilt, dass unterschiedliche Akteure nicht zwangläug unterschiedliche natürliche Personen sein müssen. Dies trit auch für TInTo zu. In der Rolle des Anwenders betrachtet der TInTo-Benutzer die Kurs- und Umsatzdaten von Aktien inklusive der angewählten Indikatordaten. In der Rolle des Administrators deniert, modiziert oder löscht der (durchaus als Person gleiche) TInTo-Benutzer die Indikator-Denitionen. Die Trennung in die unterschiedlichen Rollen dient also der Aufteilung der Anwendungsfälle in anwenderspezische und administrative Aufgaben. Die folgenden Anwendungsfälle (Use-Cases) sind in dem Diagramm in Abbildung 4.1 enthalten und sollen nun näher erläutert werden: Neues Wertpapier auswählen Der Anwender muss in der Lage sein, ein neues Wertpapier anhand des Wertpapier- Symbols auszuwählen. Dabei soll TInTo das Symbol mit Hilfe der Yahoo-Daten aus 44

49 4.2 Anforderungsprol und Use-Cases TInTo Neues Wertpapier auswählen <<include>> Wertpapier Kursdaten anzeigen <<include>> Neuen Indikator anlegen Anwender <<include>> Administrator Indikator bearbeiten Indikator anzeigen Indikator löschen Abbildung 4.1: TInTo Use-Cases mit zwei Akteuren Anwender und Administrator, die mit dem System interagieren. Die include-beziehungen visualisieren die Einbeziehung des Verhaltens eines weiteren Use-Cases. dem Internet überprüfen und bei Mehrdeutigkeit dem Anwender eine Liste zur Auswahl präsentieren. Nach Auswahl eines neuen Wertpapieres sollen die aktuellen Kursund Umsatzdaten zu diesem Wertpapier direkt angezeigt werden, daher die include- Beziehung zum Anwendungsfall Wertpapier-Kursdaten anzeigen. Wertpapier-Kursdaten anzeigen Nach Auswahl eines bestehenden Wertpapieres oder nach Änderung der Darstellungsparameter wie Darstellungszeitraum, Diagrammtyp oder Skala sollen dem Anwender die entsprechenden Kurs- und Umsatzdaten in Form eines Charts angezeigt werden. Indikator anzeigen Nach Auswahl eines bestehenden Indikators durch den Anwender soll dieser gemäÿ seiner Darstallungsparameter gemeinsam mit den Kurs- und Umsatzdaten des aktuellen Wertpapieres in Form eines Charts angezeigt werden. 45

50 4 Entwurf von TInTo Neuen Indikator anlegen Der Administrator muss in der Lage sein, neue Indikatoren anzulegen. Da die neu angelegten Indikatoren zunächst entsprechend deniert werden müssen, existiert eine include-beziehung zum folgenden Anwendungsfall Indikator bearbeiten. Indikator bearbeiten Der Administrator muss bestehene Indikator-Denitionen einschlieÿlich der Parameter bearbeiten und modizieren können. Indikator löschen Der Administrator muss in der Lage sein, bestehende Indikatoren aus dem System zu entfernen. Dies entspricht diesem Anwendungsfall. Bereits angesprochen wurde die logische Trennung der Anwendungsfälle in anwenderspezische und administrative Aufgaben. Dies dient jedoch rein der Übersichtlichkeit und soll bei einem kompakten Werkzeug wie TInTo nicht unterschiedliche Benutzeroberächen zur Folge haben. Näheres dazu folgt in Kapitel 4.5 zur Benutzerschnittstelle. 4.3 Entwurf des Datenbankschemas In diesem Abschnitt soll ein Datenbankschema für TInTo entworfen werden. Grundlage für das Datenbankdesign sei dabei ein entsprechendes Entity-Relationship-Modell (ER-Modell), dessen Grundlagen zunächst in aller Kürze dargestellt werden. ER-Modellierung Das Entity-Relationship-Modell (ER-Modell) dient im Rahmen der Datenmodellierung dazu, einen Ausschnitt aus der realen Welt zu beschreiben. Dazu werden Beziehungen (Relationships) zwischen Gegenständen Entities betrachtet. Aus diesem Grund wird dieses Modell auch oft Gegenstands-Beziehungs-Modell genannt. Ein Gegenstand (Entity) repräsentiert dabei ein Ding oder Objekt der tatsächlichen Wirklichkeit. Dies können Personen, Bücher, Autoren oder Verlage sein. Im Fall von TInTo sind es beispielsweise Wertpapiere, genauso aber auch die Kursdaten eines Handelstages. Entities können auÿerdem Attribute besitzen, Wertpapiere also beispielsweise ein Symbol, eine ISIN oder einen Namen. 46

51 4.3 Entwurf des Datenbankschemas Eine Beziehung (Relationship) beschreibt in der Regel einen semantischen Zusammenhang zwischen zwei Gegenständen. Auch Beziehungen können mit Attributen versehen werden. Die mögliche Anzahl der an einer Beziehung beteiligten Gegenstände wird dabei als Kardinalität bezeichnet. Entsprechend existieren unterschiedliche Arten von Beziehungen: 1:1 Zu jeder Entität aus der ersten Entitäts-Menge ist höchstens eine Entität aus der zweiten Entitäts-Menge zugeordnet. 1:n-Beziehung Jeder Entität aus der ersten Entitäts-Menge sind beliebig viele Entitäten aus der zweiten Entitäts-Menge zugeordnet. Im Fall einer n:1-beziehung gilt die umgekehrte Annahme, also jeder Entität aus der zweiten Entitäts-Menge sind beliebig viele Entitäten aus der ersten Entitäts-Menge zugeordnet. m:n-beziehung Jede Entität aus der ersten Entitäts-Menge kann mit beliebig vielen Entitäten aus der zweiten Entitäts-Menge in Beziehung stehen und umgekehrt. Für die grasche Repräsentation des Entity-Relationship-Modell existieren heute eine Vielzahl von Darstellungsformen, die sich bezüglich ihrer Kernaussage jedoch kaum unterscheiden. In dieser Arbeit wird die Notation von Peter Chen verwendet, der 1976 die Entity-Relationship-Modellierung für die Datenanalyse erfand ([CH76]). Dabei werden Entities durch ein Rechteck repräsentiert, Attribute der Entities durch ein Oval und Beziehungen durch eine Raute, die durch Linien mit den Entities verbunden ist. Die Linien werden mit den entsprechenden Kardinalitäten versehen. TInTo ER-Modell Zur Konzeption der TInTo-Datenbank müssen zunächst die vorhandenen Entities inklusive ihrer vorhandene Attribute identiziert werden. Dann können die zwischen den Entities bestehenden Beziehungen (Relationships) benannt werden. Zuletzt werden die Kardinalitäten der Beziehungen bestimmt. Der Gegenstandstyp Wertpapier in Abbildung 4.2 umfasst die an der Börse gehandelten Wertpapiere. Er wird eindeutig durch seine ISIN bzw. die WKN identiziert. Die Auswahl erfolgt jedoch meist über ein Wertpapier-Symbol (z.b. MSFT für Microsoft). Sowohl Symbol als auch ISIN und WKN sind also Attribute des Wertpapiers. Ausserdem besitzt das Wertpapier einen Namen, welcher ebenfalls Attribut ist. Zusätzlich ergänzt wird eine eindeutige, programminterne numerische ID, die die Beziehung zwischen dem Wertpapier und seinen Kursen herstellt. Dies ist eine reine 47

52 4 Entwurf von TInTo Symbol ID Wertpapier Name ISIN WKN Abbildung 4.2: TInTo Wertpapier-Entity mit den dazugehörigen Attributen Optimierungsmaÿnahme. Eigentlich wäre die ISIN ein ebenfalls eindeutiger Kandidat für die Verknüpfung zwischen Wertpapier und Kursdaten. Die ISIN ist allerdings eine 12-stellige Zeichenkette, die ID lediglich ein 4-Byte-Long. Somit ist die ID wesentlich besser geeignet für einen ezienten Index, da die Datenbank die notwendigen Vergleichsoperatoren bei Durchlaufen des Index wesentlich schneller und ezienter durchführen kann. Ausserdem müssen die Kursdaten über einen Fremdschlüssel an das Wertpapier gebunden werden. Hier in jedem Kurssatz die ISIN als Zeichenkette zu speichern wäre eine unsinnige Speicherverschwendung und somit ebenfalls äuÿerst inezient. Kurse ID n Date Open High Low Close Vol v1 v2 v3 Abbildung 4.3: TInTo Kurse-Entity mit den dazugehörigen Attributen Der Gegenstandstyp Kurse in Abbildung 4.3 enthält die Kurs- und Umsatzdaten zu einem Wertpapier an einem Handelstag. Als erstes Attribut ist die schon in den Wertpapieren vorhandene ID enthalten - diese stellt die Beziehung zwischen den beiden Entities her. 48

53 4.3 Entwurf des Datenbankschemas Ergänzend zum Datum der Kurs- und Umsatzdaten ndet sich ein zusätzliches Attribut n, welches ein Zugeständnis an die Berechnung der technischen Indikatoren ist. Für die in den Indikatoren oft vorkommenden Durchschnittsberechnungen muss bei der Abfrageformulierung die Kurstabelle mit sich selber verknüpft werden, also der Satz für einen Handelstag mit einem oder mehreren vorausgehenden Handelstagen. Da aber nicht jeder Kalendertag gleichzeitig Handelstag ist, ist eine Verknüpfung über das Datum nicht möglich. Dies wird über das Attribut n gelöst: hier liefert beispielsweise die Verknüpfung T1.n=T2.n-1 für die Relation T2 immer den vorausgehenden Handelstag, auch wenn sich dazwischen beispielsweise ein Wochenende oder ein Feiertag bendet, an dem kein Handel stattgefunden hat. Für jeden neuen Handelstag wird n demnach um 1 inkrementiert. Die Attribute Open, High, Low und Close entsprechen den Erönungs-, Höchst-, Tiefst- und Schlusskursen des Wertpapieres an dem entsprechenden Tag. Das Attribut Vol enthält die Volumendaten (oder Umsatzdaten), also die Anzahl der gehandelten Wertpapiere an diesem Tag. Die Attribute v1, v2 und v3 sind notwendige Hilfswerte zur Berechnung von Indikatoren mit rekursiver Denition. Die genaue Erläuterung dieser Hilfswerte sowie deren Notwendigkeit erfolgt in Kapitel 5.4.4, in dem die Berechnung des rekursiv denierten Moving Average Convergence/Divergence MACD- Indikators erläutert wird. Sicht Priority Caption IName1 IName3 ICol2 IPar1 IPar3 Name SQL IName2 ICol1 ICol3 IPar2 Notes Abbildung 4.4: TInTo Sicht-Entity mit den dazugehörigen Attributen Der Gegenstandstyp Sicht in Abbildung 4.4 enthält die Denition der Indikatorsichten. Die jeweilige Sicht besitzt einen Namen, der diese Sicht eindeutig kennzeichnet, jedoch dem Anwender nicht angezeigt wird. Ausgewählt wird die Sicht über das Attribut Caption, welches länger und damit aussagekräftiger sein darf als der Name. Da Sichten mehrstug sein dürfen und der Zugri auf die Sichten untereinander über den Namen erfogt, ist dies ein Zugeständnis an den Entwicker der Sicht-Dention. Ein kurzer, prägnanter Name (z.b. ADX0) lässt sich in rekursiven Sichten bei der Denition viel einfacher verwenden als eine lange Bezeichnung (hier z.b. ADX Average 49

54 4 Entwurf von TInTo Directional Movement Index). Dem diese Sicht aufrufenden Anwender ist jedoch mit einen ausführlicheren Namen eher gedient. Die Trennung von Name und Caption erhöht also die Bedienerfreundlichkeit sowohl für den Entwickler der Indikator-Sichten als auch für den Endanwender. Das Attribut SQL enthält die eigentliche Sichtdenition in der Datenbanksprache SQL. Die Attribute IName1, IName2 und IName3 enthalten die angezeigten Namen der in der Sicht berechneten Indikator-Kennlinien. Da die Indikatoren oft aus mehreren dargestellten Linien bestehen und TInTo zur Abbildung der meisten Indikatoren drei berechnete Linien unterstützen soll, sind hier auch drei Attribute vorgesehen. Gleiches gilt für die Attribute ICol1, ICol2 und ICol3, die den RGB-Farbwert der Indikatorlinie speichern. Die Attribute IPar1, IPar2 und IPar3 beinhalten zusätzliche Informationen für die Anzeigeform des Indikatorwerts. So können die Indikatoren als Linie oder als Balkendiagramm angezeigt werden. Zusätzlich sind unter Umständen Grenzbereiche anzugeben, beispielsweise bei Oszillatoren, die im Indikatordiagramm dann zusätzlich eingefärbt werden sollen. Wertpapier besitzt 1 n Kurse Sicht Abbildung 4.5: TInTo Beziehungen zwischen den Entities Wertpapier und Kurse Die Beziehungen zwischen den verschiedenen Gegenstandstypen in TInTo sind sehr einfach und naheliegend, wie auch aus Abbildung 4.5 ersichtlich ist. Ein Wertpapier kann n verschiedene Kurse (also Kurs- und Umsatzdaten) besitzen. Dies wird durch die besitzt-beziehung zwischen den beiden Gegenstandstypen verdeutlicht. Die Sichten stehen hingegen mit den anderen Entities nicht in Beziehung, auch wenn sich die Sichten in ihrer Berechnung auf die Kursdaten beziehen. Dies ist aber keine Beziehung im datenbanktechnischen Sinn. Logischer Entwurf Basierend auf dem konzeptuellen Entwurf wird nun als zweiter Schritt des Datenbankentwurfs die Umsetzung des Modells in ein Relationenschema vorgenommen. Ziel ist 50

55 4.3 Entwurf des Datenbankschemas ein Schema, das möglichst direkt in einer konkreten relationalen Datenbank implementiert werden kann. Die im ER-Modell betrachteten Gegenstandstypen lassen sich dabei, aufgrund des auÿerst simplen Aufbaus, sehr einfach in das relationale Modell übertragen: Wertpapier: {Symbol:string, ID:counter, Name:string, ISIN:string, WKN:string} Kurs: {ID:long, n:long, Date:date, Open:oat, High:oat, Low:oat, Close:oat, Vol:oat, v1:oat, v2:oat, v2:oat} Sicht: {Priority:long, Name:string, Caption:string, SQL:memo, IName1:string, IName2:string, IName3:string, ICol1:long, ICol2:long, ICol3:long, IPar1:string, IPar1:string, IPar3:string, Notes:string} Das Relationenschema erfüllt die dritte Normalform, was im folgenden kurz erläutert werden soll. Eine Einführung zu Normalformen wurde bereits in Kapitel gegeben. Die erste Normalform liegt vor, wenn jedes Attribut der Relation atomare Wertebereiche hat, d.h. kein Attributwertbereich kann in andere sinnvolle Wertebereiche aufgespalten werden. Dies ist hier oensichtlich der Fall, damit erfüllt das Relationenschema die erste Normalform. Die zweite Normalform liegt vor, wenn zusätzlich alle Nichtschlüsselattribute (d.h. alle Spalten, die nicht in einem Schlüssel vorkommen) von jedem Schlüsselkandidaten voll funktional (also vom ganzen Schlüssel) abhängig sind. Aufgrund des sehr einfachen Aufbaus der Tabellen ist auch hier schnell einzusehen, dass die zweite Normalform von allen Relationen erfüllt ist. Damit sind mögliche Redundanzen und daraus folgend die Verletzung der Integrität der Daten durch die Auswahl der Primärschlüssel sowie der Auftrennung der Daten in Wertpapiere und Kurse nicht vorhanden. Die dritte Normalform liegt vor, wenn zusätzlich keine transitiven Abhängigkeiten vorliegen. Das angegebene Relationenschema erfüllt ebenfalls die dritte Normalform. Datendenition Die folgenden Anweisungen der SQL-DDL (Data Denition Language) erzeugen die Relationen in der TInTo-Datenbank. Für die Zeichenketten wurden gleichzeitig sinnvolle Längenvorgaben ergänzt, welche jeweils im Anschluss erläutert werden. CREATE TABLE TWertpapier ( Symbol VARCHAR(10) NOT NULL, ID COUNTER, Name CHAR(200), ISIN CHAR(15), WKN CHAR(8), PRIMARY KEY(Symbol)); 51

56 4 Entwurf von TInTo Das Symbol wird mit einer maximalen Länge von 10 Zeichen angegeben. Das Feld muss ausgefüllt und darf nicht NULL sein. Das Feld ID ist ein Ganzzahlwert, der von TInTo für jeden neuen Wertpapier-Satz automatisch mit einer neuen, eindeutigen ID gefüllt wird. Das Feld Name enthält den Namen des Wertpapiers. Der Name darf maximal 200 Zeichen groÿ sein, was durchaus Platz für Namensergänzungen lässt. Da das Feld nicht im Index ist und ausserdem vom Typ VARCHAR 3 ist, wird dennoch kein überüssiger Speicher in der Datenbank belegt. Der Name wird zusammen mit dem Symbol in TInTo angezeigt. ISIN und WKN sind selbsterklärend. Ihre Länge ergibt sich aus ihrer Denition. CREATE TABLE TKurs ( ID LONG, n LONG, Date DATETIME, Open FLOAT, High FLOAT, Low FLOAT, Close FLOAT, Vol FLOAT, v1 FLOAT, v2 FLOAT, v3 FLOAT, PRIMARY KEY(ID,n), FOREIGN KEY (ID) REFERENCES TWertpapier(ID)); Das Feld ID enthält die Referenz auf die 1-Relation TWertpapier, n einen innerhalb der ID eindeutigen Zähler. Die Notwendigkeit des zusätzlich zum Datum vorhandenen Attributes n wurde bereits beim ER-Modell dargelegt. Die Eindeutigkeit von n innerhalb des Wertpapiers wird durch den Primärschlüssel sichergestellt. Date enthält das Datum (also den Handelstag) für die Kurs- und Umsatzdaten Open, High, Low, Close sowie Vol. Die Felder v1, v2 und v3 sind Hilfswerte zur Indikatorberechnung und ebenso wie die Kurs- und Umsatzfelder vom Datentyp Gleitkommawert. CREATE TABLE TView ( Priority LONG, Name VARCHAR(50), Caption VARCHAR(50), SQL MEMO, IName1 VARCHAR(20), IName2 VARCHAR(20), IName3 VARCHAR(20), ICol1 LONG, 3 Werte in VARCHAR-Spalten sind Zeichenketten variabler Länge. Sie nur mit so vielen Zeichen wie nötig gespeichert. 52

57 4.3 Entwurf des Datenbankschemas ICol2 LONG, ICol3 LONG, IPar1 VARCHAR(100), IPar2 VARCHAR(100), IPar3 VARCHAR(100), Notes VARCHAR(255), PRIMARY KEY(Name)); Das Feld Priority legt die Priorisierung bezüglich der Anzeigereihenfolge in TInTo fest. Der Name enthält den internen Indikatornamen, Caption den für den Anwender angezeigten Namen. In SQL wird die eigentliche Denition der Sicht in der Datenbanksprache SQL formuliert, daher ist SQL vom Datentyp Memo (Langtext). Die übrigen Felder enthalten Namen, Farben und zusätzliche Parameter zu dem Indikator. Ezienzüberlegungen In der Vorgängerarbeit von Alexander Geppert [GE05] wurde ein Datenbankschema entworfen, welches die Wertpapier-Stammdaten sowie deren Kurs- und Umsatzdaten für jedes Wertpapier in getrennten Tabellen gespeichert hat. Als Resultat dieses Schemas war es erforderlich, die Sichten zur Berechnung der Indikatoren für jede dieser Tabellen getrennt zu denieren. Dieser Auftrennung lag die folgende Annahme zugrunde: bei 100 betrachteten Wertpapieren, die an 10 Handelsplätzen gehandelt werden, fallen pro Tag 600 Intraday Kurs- und Umsatzdaten an. Bei etwa 250 Handelstagen pro Jahr ergibt dies 150 Millionen Datensätze für ein Jahr. Diese Annahme ist jedoch so nicht korrekt, da die Intraday Kurs- und Umsatzdaten nur für den aktuellen Tag von Interesse sind, d.h. es genügt, für zurückliegende Handelstage die End-Of-Day (EOD) Kurs- und Umsatzdaten zu speichern. Die jeweiligen Intraday-Daten können dann verworfen werden. Unter dieser korrigierten Annahme reduziert sich die Datenmenge für ein Jahr auf nur noch Datensätze - eine etwa um den Faktor 175 kleinere Satzanzahl. Die aus dieser Erkenntnis sich als einzig pragmatische ergebende Schlussfolgerung, nämlich die Tabellen für die Wertpapiere zusammenzulegen, wurde in der Vorgängerarbeit nicht gezogen, wenn auch erkannt wurde, dass historische Intraday-Kursdaten nicht mehr von Interesse für das System sind. Stattdessen wurden die Tabellen weiter aufgeteilt: für jedes Wertpapier sollte eine getrennte Tabelle für Intraday und für EOD-Kursdaten angelegt werden. Der sich hieraus ergebene administrative Aufwand, ganz zu schweigen von der zig-fachen Deniton der erforderlichen Abfragesichten, ist natürlich enorm. Da der Zugri auf die Kursdaten über den Primärschlüssel der Relation erfolgt und auÿerdem die zu betrachtende Datenmenge relativ gering ist (selbst bei einem 5-Jahres-Intervall sind lediglich etwa 1200 Datentupel anzuladen), ist daher jeglicher Vorteil des Auftrennens der Daten kritisch zu sehen. Wie bereits erwähnt, steht der 53

58 4 Entwurf von TInTo Aufwand, der sich in einer tatsächlichen Implementierung ergibt, dabei in keinem vernünftigen Verhältnis zum erzielten Zeitgewinn beim Zugri auf die Daten. Um diese Aussage zusätzlich zu verizieren, wurde eine Probedatenbank mit insgesamt Kurs- und Umsatztupeln angelegt (also beinahe sieben Millionen Datentupel). Dies entspricht den Daten für über Wertpapiere über den Zeitraum von beinahe 6 Jahren, also etwa ab dem Jahr Die so betrachtete Datenbank hatte dabei eine Gröÿe von über 600 MB. Danach wurde der Datenzugri auf einem Desktop-PC mit 3000 MHz AMD Sempron Prozessor für beliebige 5-Jahres-Intervalle getestet. Sowohl die Zugrisgeschwindigkeit als auch die Berechnung verschiedener ein- und mehrstuger Indikatoren verlief dabei subjektiv nicht langsamer als in einer Vergleichsdatenbank mit lediglich einem Wertpapier. Die gemessene Verlangsamung betrug unter 5 Prozent und war damit zu vernachlässigen. Der Anwender muÿ also in beiden Fällen der ein- und mehrstugen Indikatoren mit keiner relevanten Verzögerung rechnen. Als Ergebnis dieser Ezienüberlegungen wurde in TInTo auf die Auftrennung der Wertpapier-Stammdaten sowie deren Kurs- und Umsatzdaten für jedes Wertpapier in getrennte Tabellen zugunsten einer wesentlich übersichtlicheren Datenstruktur verzeichtet. Wie nachgewiesen werden konnte, ist dies ohne nennenswerten zeitlichen oder performancemäÿigen Nachteil möglich. 4.4 Architektur von TInTo In diesem Kapitel sollen die grundlegenden Elemente und die Struktur von TInTo beschrieben werden. Konkret werden die Systemkomponenten inklusive ihre Beziehungen zueinander benannt. In der Abbildung 4.6 wird die TInTo Softwarearchitektur grasch dargestellt. Dabei werden die Komponenten zunächst grundsätzlich in die folgenden Kategorien unterteilt: Vorhandene Komponente (rot) Hierbei handelt es sich um bereits vorhandene Komponenten, die entweder in TInTo eingebunden oder deren Funktionalität von TInTo genutzt wird. Nur Basisfunktionalität (gelb) Diese Komponenten werden lediglich in ihrer Basisfunktionalität implementiert. Umfassende Funktionalität (grün) Diese Komponenten werden möglichst umfassend mit umfangreicher Funktionalität implementiert. 54

59 4.4 Architektur von TInTo Benutzerschnittstelle ChartDirector Visualisierung TInTo Hauptkomponente Neues Wertpapier Anzeigedaten Neuen Kurs/Indikator anzeigen WP/Indikator Stammdaten Chart Manager Kursdaten anfordern Kursdaten DB-Interface (Jet) Kurs-/ Wertpapier daten Internet-Schnittstelle Nachrichten Filter Daten Vorhandene Komponente Nur Basisfunktionalität DB Views Internet Umfassende Funktionalität Abbildung 4.6: TInTo Softwarearchitektur mit Darstellung der Komponenten des Systems sowie deren Abhängigkeiten. Grundsätzlich handelt es sich hier um einen Top-Down 4 -Ansatz. Das TInTo Hauptmodul kontrolliert alle Aktivitäten, fordert bei entsprechender Benutzeraktivität ggf. neue Daten an und veranlasst Anzeige von Kurs- und Umsatzdaten sowie die Berechnung und Darstellung der Indikatoren. Aufgrund des relativ groÿen Aktualisierungs- Intervalls der Kursdaten von einem Tag wurde dieser Ansatz gewählt. Bei kleineren Intervallen wäre unter Umständen eine Modikation dieses Ansatzes nötig. Neue Kursdaten müssten dann selbständig das Einlesen der Daten sowie die Aktualisierung der Anzeige anstossen. In einer Realisierung dieses Push-Ansatzes würde etwa ein Ereignis (Event 5 ) ausgelöst, welches dem Hauptmodul die Ankuft neuer Daten mitteilen würde. Hierzu wären jedoch nur geringe Änderungen zum gewählten Ansatz notwendig. Im Folgenden soll auf die unterschiedlichen TInTo-Module sowie deren Abhängigkeiten untereinander näher eingegangen werden: 4 hier: Steuerung und Kontrolle von oben nach unten 5 Methode der Softwaretechnik zur Steuerung des Programmusses. Eine entsprechende Routine (Event Handler) wird dann ausgeführt, wenn ein bestimmtes Ereignis eintritt. 55

60 4 Entwurf von TInTo Internet-Schnittstelle Die in TInTo benötigten Kursdaten sollen aus dem Internet eingelesen werden. Das Finanzportal nance.yahoo.com liefert kostenlos End-Of-Day Kurs- und Umsatzdaten und stellt diese auf Anfrage als CSV-Datei 6 zur Verfügung. Werden Kurs- und Umsatzdaten für ein bestimmtes Wertpapier angefordert, soll diese Komponente die Anfrage zunächst validisieren, gegebenenfalls (bei nicht eindeutigem Wertpapier) eine Liste der möglichen Wertpapiere anbieten und zuletzt die Kurs- und Umsatzdaten für den entsprechenden Zeitraum einlesen. Dabei müssen die Daten einen (zumindest rudimentären) Filter durchlaufen, da Yahoo aussergewöhliche Aktivitäten wie z.b. Aktiensplits genauso in einer Datenzeile anliefert wie normale Kurs- und Umsatzdaten. Die Internet-Schnittstelle muss mit dem Internet kommunizieren können und dabei die von Yahoo für diese Daten erforderliche Anfrage im HTTP 7 zur Übertragung der Daten über das Netzwerk unterstützen. DB-Interface (Jet) Diese Komponente bezeichnet das DMBS zur Speicherung und Verwaltung der Kursund Umsatzdaten sowie der Speicherung und Verwaltung der Denitionen der technischen Indikatoren in Form von (ggf. verschachtelten) Sichten. Hier wird auf eine bestehende Komponente zurückgegrien, da Ziel von TInTo nicht der Entwurf und die Implementierung eines DBMS ist. In Kapitel wird näher auf die Auswahl eines für TInTo geeigneten DBMS eingegangen. TInTo Hauptkomponente Dieses Modul stellt das Kernstück von TInTo dar. Es übernimmt die Steuerung aller übrigen Komponenten. Alle Interaktionen vom Benutzer durch die Benutzerschnittstelle werden hier weiterverarbeitet und die relevanten Aktionen in den übrigen Komponenten ausgelöst. Anforderungen für ein neues Wertpapier werden an die Internet- Schnittstelle weitergegeben. Änderungen in der Kursdarstellung (z.b. Änderung des Diagrammtyps oder des angezeigten Intervalls, werden ebenso an den Chart Manager weitergegeben wie die Auswahl eines neuen Indikators. Ausserdem können die Sichten für die Indikatoren deniert und modiziert werden. 6 Textdatei zum Austausch einfach strukturierter Daten. CSV steht für Character Separated Values oder Comma Separated Values, weil die einzelnen Werte durch ein spezielles Trennzeichen, beispielsweise das Komma, getrennt werden. 7 Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. 56

61 4.5 TInTo-Benutzerschnittstelle Chart Manager Der Chart Manager stellt die Schnittstelle zwischen den Kurs- und Umsatzdaten sowie der Darstellung dieser Daten dar. Ausserdem führt er die vom Anwender ausgewählten Sichten zur Berechnung der technischen Indikatoren aus. Er stellt spezielle Funktionen zur Einschränkung der Sichten nach Wertpapier-ID und Zeitraum zur Verfügung. Zusätzlich erlaubt er zum einen die Ausführung von mehrstugen, hintereinander ausführbaren Abfragen, zum anderen aber auch die Ausführung aufeinander aufbauender Sichten. Sollten Kurs- und Umsatzdaten für den anzuzeigenden Zeitraum fehlen, fordert der Chart Manager diese selbstständig bei der Internet-Schnittstelle an. ChartDirector Visualisierung Der ChartDirector ist eine bestehende COM-Komponente 8, die zur reinen Visualisierung der Kurs-, Umsatz- und Indikatordaten verwendet wird. Da sich diese Arbeit mit der Berechnung der Indikatoren befasst, wird für die Visualisierung eine vorhandene Komponente verwendet. In Kapitel wird näher auf die Auswahl dieser Komponete sowie deren Möglichkeiten eingegangen. Benutzerschnittstelle Die Benutzerschnittstelle stellt das Bindeglied zwischen Anwender und TInTo dar. In entsprechend geeigneten Formularen kann der Anwender Wertpapiere und Indikatoren auswählen. Diese werden ihm dann für ein bestimmtes Intervall grasch in Form eines Diagramms oder auch tabellarisch angezeigt. Ausserdem muss der Anwender in die Lage versetzt werden, die für die Indikatoren erforderlichen Sichten anzulegen, zu modizieren oder zu löschen. Die unterschiedlichen Gestaltungsmöglichkeiten der Benutzerschnittstelle, sowie deren Vor- und Nachteile, werden im nächsten Kapitel gesondert untersucht. 4.5 TInTo-Benutzerschnittstelle Die Gestaltung der Benutzerschnittstelle, also der Teil eines Programms, der den Datenaustausch mit dem Benutzer durchführt, ist von groÿer Bedeutung, nicht zuletzt auch für die Gesamtakzeptanz des Programms. Leider wird diesem Teil des Softwareentwurfs auch heute noch allzuoft zu wenig Beachtung geschenkt. Selbst ein kleinens Tool wie TInTo verdient daher in diesem Bereich besondere Aufmerksamkeit. 8 COM: Component Object Model. Eine von Microsoft entwickelte Technologie, um unter Windows Klassen aus DLLs (Dynamic Link Libraries) zu exportieren und somit eine leichte Wiederverwendung von bereits geschriebenem Programmcode möglich zu machen. 57

62 4 Entwurf von TInTo Die Benutzeroberäche hat die Aufgabe, Anwendungssoftware auf einem Rechner mittels grascher Elemente bedienbar zu machen. Dies geschieht meistens mittels einer Maus oder der Tastatur als Steuergeräte. Dabei sollen alle Funktionen, in die der Anwender eingreifen muss, möglichst intuitiv zur Verfügung gestellt werden. Dies beinhaltet zunächst die Auswahl eines Wertpapieres und dessen Anzeige in verschiedenen Darstellungsmodi (bezogen beispielweise auf Zeitbereich oder Diagrammtyp). Weiterhin müssen Indikatordenitionen einschlieÿlich ihrer Parameter erstellbar, modizierbar und löschbar sein. Diese Indikatoren sollten dann, idealerweise gemeinsam mit den Kurs- und Umsatzdaten, angezeigt werden können. Wünschenswert wäre neben der graschen Darstellung auch eine tabellarische Darstellung der Kurs- und Umsatzdaten, aber auch der errechneten Indikatorwerte. Im Hintergrund ablaufende Funktionalitäten, in die der Benutzer nicht parametrierend eingreifen kann, sollten hingegen von der Oberäche vollkommen entkoppelt werden. Dies gilt beispielweise für den Zugri über das Internet auf die Kurs- und Umsatzdaten. Solange vom Anwender keine Interaktion gefordert ist, sollte derartige Funktionalitäten für den Anwender vollkommen transparent ablaufen. Grundsätzlich gilt es, zwei gegensätzliche Vorgehensweisen bei der Gestaltung der Benutzerschnittstelle zu betrachten. Zum einen gibt es die (leider allzu häug angewandte) Atomisierung (oder Zerlegung) der Daten in mehrere Formulare. Dieser Ansatz ndet sich in vielen Programmen wieder, unter anderem auch im Betriebssystem Windows von Microsoft. Hier werden Einstellungen völlig unsinnigerweise auf unterschiedliche Formulare verteilt, die nicht nur inhaltlich, sondern auch unter Berücksichtigung des im Formular vorhandenen Platzes, durchaus zueinander passen würden. Besser ist die Konzentration auf ein Formular, mit allen notwendigen Daten und Eingabemöglichkeiten. Dieser Alles-auf-einen-Blick Ansatz bietet den Vorteil, dass der Anwender die komplette Basisfunktionalität in einem Formular durchführen kann. Lediglich Sonder- oder administrative Funktionen werden in zusätzliche Formulare ausgelagert. Dieser Ansatz soll auch bei TInTo gewählt werden. Die Auswahl eines Wertpapiers, die Einstellung der Diagrammparameter und nicht zuletzt die Wahl der anzuzeigenden technischen Indikatoren sollen alle in einem Formular einzustellen sein. Lediglich das Anlegen neuer und die Wartung bestehender Indikatoren soll in ein zusätzliches Formular ausgelagert werden. Ausserdem soll es im Einzelfall zusätzliche Formulare geben. So wird zum Beispiel die (optionale) tabellarische Darstellung der Kurs- und Umsatzdaten, ebenso wie die tabellarische Darstellung der Indikatordaten bei der De- nition der Indikatorsichten, in einem separaten Formular erfolgen. Die in Kapitel 4.2 vorgenommene Trennung der Akteure in Anwender und Administratoren soll, wie bereits angesprochen, in TInTo nicht vorgenommen werden. Vielmehr soll sowohl die Anwendung als auch die Administration von TInTo unter einer Oberäche erfolgen. 58

63 5 Implementierung 5.1 Verwendete Software Die Auswahl eines geeigneten Programmierwerkzeugs für die Realisierung des TInTo- Projektes ist von nicht unerheblicher Bedeutung. Zum einen soll in möglichst kurzer Zeit ein brauchbares Resultat erzielt werden, zum anderen soll das Werkzeug bei der Entwicklung nicht unnötig einschränken. Für die Realisierung von TInTo müssen folgende Anforderungen durch die Programmierumgebung erfüllt sein: Zugri auf das Internet: Zum Einlesen der Kurs- und Umsatzdaten muss TInTo auf das Internet zugreifen können. Datenbankfunktionalität: Die eingelesenen Daten müssen in einer Datenbank gespeichert und verwaltet werden können. Benutzerschnittstelle: Der Anwender muss die Möglichkeit haben, mit TInTo über Formulare zu interagieren. Aufgrund dieser geforderten Funktionalitäten wäre eine reine Datenbanklösung nicht praktikabel, da diese in den meisten Fällen keine Möglichkeit bietet, eine komfortable Benutzerschnittstelle zu implementieren. Diese müsste dann mit einem weiteren Werkzeug implementiert werden. Der Zugri auf die Daten müsste dann über eine geeignete Schnittstelle, etwa ODBC 1 realisiert werden, was den Aufwand weiter erhöhen würde. Darüber hinaus wäre auch der Zugri auf das Internet bei einem reinen DBMS unter Umständen nur umständlich oder gar nicht möglich. Unter Berücksichtigung der oben genannten Anforderungen el die Wahl eines geeigneten Implementierungswerkzeuges schnell auf Microsoft Access, welches die reine Datenbankfunktionalität mit den Möglichkeiten der freien Gestaltung einer Benutzeroberäche sowie der exiblen Programmierbarkeit unter Visual Basic kombiniert. 1 Open Data Base Connectivity - standardisierte Datenbankschnittstelle, die es erlaubt, die Anwendung möglichst unabhängig vom verwendeten DBMS zu entwickeln. 59

64 5 Implementierung Microsoft Access Das von Microsoft als Teil des Oce-Paketes angebotene Microsoft Access ist ein Datenbanksystem, welches zum einen die Verwaltung von Daten, zum anderen auch die Entwicklung von kompletten Datenbankanwendungen ermöglicht. Neben der reinen DBMS-Funktionalität verfügt Access über die Möglichkeit der komfortablen Gestaltung einer Benutzeroberäche über Formulare mit frei denierbaren Bedienelementen. So ist es möglich, innerhalb von kurzer Zeit datenbankbasierte Anwendungen zu erstellen. Durch die Integration von VBA (Visual Basic for Applications) ist es ausserdem möglich, benötige Funktionalität mit geringem Aufwand zu ergänzen. So ist der Zugri auf das Internet zum Einlesen der Kurs- und Umsatzdaten genauso zu realisieren wie die Erweiterung der Benutzeroberäche. Zur Verbesserung der Geschwindigkeit der Programmausführung kann der auf Basis von VBA erstellte Quelltext kompiliert und zusätzlich als Pseudocode in der Datenbankdatei gespeichert werden. Darüber hinaus ist auch der Zugri auf die Windows-API 2 möglich. So sind auch Funktionen realisierbar, die durch Anwendung der reinen Access-Funktionalität nicht möglich wären. Microsoft Access existiert momentan in der Version Access 2003 und unterstützt SQL-92. In seinem Funktionsumfang war Microsoft Access unter Windows lange Zeit ohne Konkurrenz, inzwischen existieren jedoch weitere Produkte mit ähnlichem Funktionsumfang, wie z.b. das Base-Modul des OpenOce Programmpaketes (jedoch erst ab Version 2.0). Aufgrund der hohen Verbreitung von Microsoft Access und der Erfahrung des Autors mit dem Produkt el die Wahl des Entwicklungswerkzeuges hier jedoch auf Microsoft Access ChartDirector Da es unter Microsoft Access, selbst unter Berücksichtigung von VBA, nur mit erheblichem Aufwand möglich ist, die zur Ausgabe der Kurs-, Umsatz- und Indikatordaten notwendige Chart-Funktionalität zu implementieren, kommt bei TInTo zur Visualisierung dieser Daten eine entsprechende Komponente zum Einsatz. Der von Advanced Software Engineering Limited implementierte ChartDirector übernimmt die Darstellung dieser Daten als Diagramm und ermöglich es so, den Schwerpunkt bei der Entwicklung von TInTo in die Berechnung der technischen Indikatoren zu legen. Implementiert als COM-Komponente, kann der ChartDirector von jeder Anwendung verwendet werden, die COM unterstützt, also auch von Microsoft Access. Dabei wird die Komponente lediglich unter Windows registriert und die notwendigen Verweise in Access gesetzt. Die Registrierung sowie das Setzen der Verweise übernimmt dabei 2 Application Programming Interface: Schnittstelle, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. 60

65 5.2 Umsetzung des Schemaentwurfs in Microsoft Access TInTo. Danach ist die ChartDirector-Komponente nahtlos eingebunden und kann wie ein Access-spezisches Bedien- bzw. Anzeigeelement programmiert werden. In TInTo verwendet wird der ChartDirector-Diagrammtyp FinanceChart, der neben der Darstellung der Kursdaten als Candlestick, OHLC oder als Linienchart (ggf. ergänzt um Umsatzinformationen) auch die parallele Anzeige von einem oder mehreren Indikatoren erlaubt. Dabei werden die relevanten Daten der Komponente aus Visual- Basic heraus per Funktionsaufruf übergeben. Der ChartDirector bietet darüber hinaus noch die eigenständige Berechnung einiger technischer Indikatoren auf den übergebenen Kursdaten. In TInTo ist es daher für den Anwender möglich, sich diese Indikatoren zusätzlich zu den über Sichten berechneten Indikatoren anzeigen zu lassen. Da die ChartDirector-Berechnungszeiträume allerdings programmseitig auf ein festes Intervall eingestellt sind und unter Umständen nicht mit den vom Anwender eingegebenen Parametern der Sichten übereinstimmen, kann die Darstellung des ChartDirector Indikators von der Darstellung des über Sichten berechneten Indikators abweichen. Bei gleicher Intervalleingabe und identischer Denition der Sicht sind die Darstellungen jedoch übereinstimmend. Neben den in TInTo benötigten FinanceCharts unterstützt der ChartDirector eine Vielzahl von anderen Chart-Typen, so z.b. Torten-, Balken-, Linien- oder Punktdiagramme. Auch eine Kombination oder Überlagerung von verschiedenen Typen ist möglich. Die Herstellerrma Advanced Software Engineering Limited hat den ChartDirector für das TInTo-Projekt freundlicherweise kostenlos zur Verfügung gestellt. 5.2 Umsetzung des Schemaentwurfs in Microsoft Access In Kapitel 4.3 wurde bereits ein für die TInTo-Anwendung passendes Datenbankschema entworfen, welches bei der Implementierung umgesetzt wurde. Im folgenden wird für jede Tabelle eine beispielhafte Ausprägung dargestellt. Abbildung 5.1: TInTo Wertpapier-Tabelle TWertpapier Die Tabelle TWertpapier aus Abbildung 5.1 enthält in diesem Beispiel die Stammdaten von drei unterschiedlichen Aktien: Google Inc., IBM sowie Microsoft Corp. Neben 61

66 5 Implementierung dem Ticker-Symbol sind ausserdem der Wertpapiername, die ISIN (International Securities Identication Number) und wie WKN (Wertpapier-Kennummer) gespeichert. Wie bereits im Entwurf festgelegt, wird TInTo-Intern für jedes Wertpapier eine eigene ID vom Typ Counter vergeben. Dies dient der ezienten Verknüpfung von Wertpapier und Kursdaten, da die Datenbankengine auf Zahlenwerten ezienter operiert als auf Zeichenketten. Abbildung 5.2: TInTo Kursdaten-Tabelle TKurs Die Tabelle TKurs aus Abbildung 5.2 enthält die Kurs- und Umsatzdaten für die in der Tabelle TWertpapier enthaltenen Stammdaten. In Abbildung 5.2 sind beispielhaft Kursdaten der Microsoft Corp. zu Beginn des Jahres 2000 dargestellt. Wie bereits beim Entwurf angedeutet, sind die zusätzlichen Felder v1-v3 Hilfswerte für die Auswertung besonders schwierig zu berechnender Indikatoren (z.b. MACD). Diese Hilfswerte werden bei der Beschreibung der MACD-Berechnung in näher erläutert. Abbildung 5.3: TInTo Indikatorsichten-Tabelle TView In der Tabelle TView aus Abbildung 5.3 werden die Sichten für die technischen 62

67 5.3 Programmstruktur und Visual Basic Module Indikatoren gespeichert. Dargestellt sind beispielhaft in TInTo denierte Indikatoren mit internem Namen, Beschreibung, Abfrageformulierung in SQL sowie diverser Darstellungsparameter (siehe Kapitel 4.3). 5.3 Programmstruktur und Visual Basic Module Im Kapitel 4.4 wurde die TInTo-Softwarearchitektur vorgestellt. Die dort vorgestellte Aufteilung in die unterschiedlichen Komponenten ndet sich auch in der Implementierung der Visual Basic Module von Microsoft-Access wieder. Eine vollständige Auistung der in den Modulen enthaltenen Funktionen ndet sich im Anhang. Form_Main Form_Symbol Chart Yahoo Form_Ind Helper clshttp Abbildung 5.4: TInTo Visual Basic Module sowie deren Abhängigkeiten. Eine Übersicht zu den Modulen sowie deren Abhängigkeiten untereinander ndet sich in Abbildung 5.4. Ein Pfeil von einem Modul zu einem anderen entspricht einem Funktionsaufruf und damit einer Abhängigkeit untereinander. Globale Module sind blau eingefärbt, Formularmodule gelb. Modul Yahoo In diesem Modul sind die erforderlichen Funktionen für den Abruf und die Auswertung der Daten aus dem Internet vorhanden. Dabei wird eine von Yahoo zur Verfügung gestellte Schnittstelle verwendet, welche den Zugri auf Wertpapier, Kurs- und Umsatzdaten ermöglicht. Im wesentlichen erfüllt dieses Modul zwei Aufgaben: den Zugri auf Wertpapier-Stammdaten sowie den Zugri auf Kurs- und Umsatzdaten. Beim Zugri auf Wertpapier-Stammdaten wird zunächst für ein übergebenes Wertpapiersymbol geprüft, ob in Yahoo dieses Wertpapier bekannt ist. Wenn nicht, wird es 63

68 5 Implementierung abgewiesen und eine Fehlermeldung zurückgeliefert. Bei Mehrdeutigkeit (beispielsweise bei der Teileingabe eines Symbols oder beim Handel von einem Wertpapier an mehreren Märkten) wird ein Formular geönet, in dem der Anwender das gewünschte Wertpapier auswählen kann. Bei erfolgreicher Auswahl werden die Wertpapier-Stammdaten in die Tabelle TWertpaper geschrieben. Das Wertpapier ist daraufhin in TInTo verwendbar. Sollen für ein vorhandenes Wertpapier die Kurs-, Umsatz- und/oder Indikatorwerte dargestellt werden, prüft TInTo zunächst, ob aktuelle, noch nicht in der TInTo- Datenbank gespeicherte Kurs- und Umsatzdaten vorliegen. Dazu wird eine entsprechend formulierte Anfrage an Yahoo gesendet, welche die Kurs- und Umsatzdaten vom maximal 5 Jahren bis zum aktuellen Tag abruft. Der maximale Zeitbereich von 5 Jahren ergibt sich aus dem momentan auswählbaren maximalen Anzeigezeitraum. Dieser kann aber ohne weiteres angepasst werden. Noch nicht in der Datenbank vorhandene Kurs- und Umsatzdaten werden analysiert und gemeinsam mit dem Datum und einer fortlaufenden ID gespeichert. Nach dieser Aktualisierung der Kurs- und Umsatzdaten können die Indikatorsichten aufgerufen werden. Die Funktionen dieses Moduls, also sowohl der Wertpapier- als auch der Kurs- und Umsatzzugri, verwenden die im folgenden Abschnitt vorgestellte HTTP-Klasse. Klassenmmodul clshttp Dieses bereits als VBA-Quellcode frei verfügbare Klassenmodul fungiert als Wrapper 3 für die unter Microsoft Windows im WININET.DLL vorhandene Internetfunktionalität. Es deklariert eine eigene VBA-Klasse für den komfortablen Zugri auf das Internet und stellt Funktionen zum Verbindungsaufbau, Lesen von Daten und Dateien aus dem Netz, Schreiben von Daten in das Netz sowie administrative Funktionen wie Fehlerhandling zur Verfügung. Da die von dieser Klasse zur Verfügung gestellte Funktionalität fast vollständig im WININET.DLL implementiert ist, ist dieses Modul zwangsläug sehr einfach gehalten. Modul Chart Dieses Modul bildet die Funktionalität des bereits im Entwurf vorgestellten Chart Managers ab (siehe Kapitel Softwarearchitektur 4.4). Es fungiert als Schnittstelle oder Mediator zwischen dem Benutzer und seiner Auswahl, den Kurs-, Umsatz und Indikatordaten aus den gewählten Sichten sowie der ChartDirector-Komponente als Darstellungswerkzeug. Kernfunktion dieses Moduls ist die Funktion ChartShow, welche die vom Anwender ausgewählte Abfrage analysiert, ausführt und die resultierenden Werte zur Anzeige 3 Schnittstelle zwischen dem aufrufenden und dem umschlossenen (engl. wrapped) Programmcode 64

69 5.3 Programmstruktur und Visual Basic Module dem ChartDirector übergibt. Zunächst wird die ausgewählte Abfrage angeladen und mit Hilfe der rekursiven Funktion ChartAddQuery analysiert. Diese Rekursion stellt sicher, dass die der aktuellen Abfrage zugrundeliegenden Sichten ebenfalls als Abfrage vorliegen, also in Access entsprechend deklariert sind. Aber auch, wenn die zugrundeliegenden Abfragen bereits vorliegen, könnten in der aktuellen Instanz Änderungen vorgenommen worden sein. Daher werden zugrundeliegende Abfragen in jedem Fall angelegt bzw. aktualisiert. Zusätzlich übernimmt die ChartAddQuery-Funktion die Ausführung der Aktualisierungsabfragen bei mehreren hintereinander auszuführenden Teilabfragen, wie sie beispielsweise für die Berechnung des MACD-Indikators (vgl. Kapitel 5.4.4) benötigt werden. Nach dem erfolgreichen Anlegen der für die Berechnung des Indikators notwendigen hierarchisch verschachtelten Sichten wird die eigentliche Abfrage ausgeführt. Die von der Abfrage berechneten Indikatorwerte werden dann gemeinsam mit den Kursund Umsatzdaten in einem Array 4 von Gleitkommawerten gepuert. Dieses Array wird gemeinsam mit den zusätzlichen Darstellungsparametern für die Indikatoren wie Darstellungstyp, Farbe und Bezeichnung, an den ChartDirector zur Darstellung übergeben. In diesem Modul sind ausserdem die globalen Funktionen deklariert, die in den SQL- Formulierungen der Indikatoren zu verwenden sind. Die dienen dem Anfragen des aktuellen Wertpapiers, des gewählten Zeitraums sowie zum Auswählen von Parametern. Da diese Funktionen einen unmittelbaren Bezug zur Formulierung der Indikatorsichten haben, werden sie hier nur kurz erwähnt, im Detail aber im folgenden Kapitel 5.4 beschrieben. Die Funktion spgetid() liefert die ID des gerade angezeigten Wertpapiers, die Funktion spgetn() liefert einen zum aktuell gewählten Anzeigezeitraum passenden Grenzwert zur zeitlichen Einschränkung der Abfrage und die Funktion spgetpar(p) dient der Abfrage von notwendigen Parametern. Helper In diesem Modul nden sich globale Hilfsfunktionen wieder, die von den übrigen Modulen aufgerufen werden. Im wesentlichen handelt es sich hierbei um API-Wrapper 5 zur Verwendung der entsprechenden Funktionen unter VBA. Zur Skalierung des Chart- Director Steuerelementes innerhalb des TInTo-Formulares sowie zur Skalierung des Hauptfensters werden Funktionen des Windows-GDI 6 benötigt, die nicht unmittelbar in VBA zur Verfügung stehen. 4 Datenstruktur in der Informatik; Daten eines einheitlichen Datentyps werden geordnet so im Speicher eines Computers abgelegt, dass ein Zugri auf die Daten über einen Index möglich wird. 5 Application Programming Interface; funktionsorientierte Schnittstelle zur Windows- Anwendungsprogrammierung 6 Graphic Device Interface; Windows Programmschnittstelle zu den Grakgeräten 65

70 5 Implementierung Weiterhin enthält das Helper-Modul die Funktionalität zur Installation sowie zur Lizensierung der ChartDirector-Komponente. Beim Programmstart von TInTo müssen die DLL und OCX-Dateien des ChartDirectors in den entsprechenden Verzeichnissen von Windows vorhanden sein. Dies wird in diesem Modul überprüft, welches ebenfalls bei Bedarf die Dateien kopiert und unter Windows registiert. Die Registrierung beim Betriebssystem entspricht dem Eintragen der Komponente in der zentralen Kongurationsdatenbank von Windows und damit der Bekanntmachung der Komponente unter Windows. Die TInTo-Funktionalität, welche sich auf die Bedienung der jeweiligen Formulare bezieht, wird in Microsoft Access üblicherweise in die Module der entsprechenden Access Klassenobjekte eingebettet. Daher existieren neben den gerade vorgestellten Modulen noch weitere, an das jeweilige Formularobjekt gebundene Module: Form_Main Dieses Formularmodul enthält die notwendigen Funktionen, um das TInTo Hauptformular mit Leben zu füllen. So wird beim Betätigen von Schaltächen die entsprechende Funktion ausgeführt. Wird ein neues Wertpapiersymbol eingegeben, wird die Wertpapierauswahl im Modul Yahoo aufgerufen. Beim Auswählen eines neuen Darstellungszeitraumes wird die Aktualisierung der angezeigten Kurs-, Umsatz und Indikatorwerte über die Funktionen des Modules Chart aufgerufen. Zusätzlich enthält dieses Modul die Funktionalität zur freien Skalierung des Hauptformulars und der dadurch notwendigen Anpassung des ChartDirector-Steuerelements. Form_Symbol Die wenigen Funktionen dieses Modules rufen die notwendigen Funktionen nach Auswahl über die Steuerelemente auf, beispielsweise die Auswahl eines Wertpapieres über Doppelklick auf das Listenelementfeld. Form_Ind Dieses Modul stellt die Attribute des gewählten Indikators im Indikator-Detailfenster dar und speichert die Werte nach der Aktualisierung durch den Anwender. Ausserdem wird nach Betätigung der entsprechenden Schaltäche ein Formular mit der tabellarischen Darstellung der aktuellen Sicht geönet. Dies dient der Kontrolle der formulierten Abfrage durch den Benutzer. 66

71 5.4 Umsetzung der Indikatorklassen in TInTo 5.4 Umsetzung der Indikatorklassen in TInTo Da TInTo lediglich das Handwerkszeug zur Formulierung, Ausführung und Darstellung der gewünschten Indikatoren zur Verfügung stellt, ist zur Berechnung der Indikatoren die eigentliche SQL-Formulierung der Indikator-Sichten ebenfalls erforderlich und wird daher in dieser Ausarbeitung als Teil der Implementierung betrachtet. Von TInTo werden dafür Hilfsfunktionen zur Einschränkung der Sichten sowie zur Abfrage von Parametern zur Verfügung gestellt, die vom Anwender in der SQL- Formulierung der Indikatoren verwendet werden können. Die sonst auch in Microsoft Access übliche Abfrage der Parameter über die Notation in eckigen Klammern (also beispielsweise Datum<[Bitte Datum eingeben...] ) funktioniert nicht beim Önen von Abfragen aus einer Visual-Basic-Funktion. Ausserdem ist es nicht möglich, Vorgaben für die Parameter anzugeben. Die zur Verfügung gestellten Funktionen werden im Folgenden kurz erläutert: Public Function spgetid() As Long Diese Funktion ohne Parameter liefert die Wertpapier-ID des aktuell vom Anwender ausgewählten Wertpapiers. Sie dient der Einschränkung der Kurs- und Umsatzdaten der Tabelle TKurs auf das entsprechende Wertpapier und sollte in jedem Fall angewendet werden, da ansonsten die Kurs- und Umsatzdaten von unterschiedlichen Wertpapieren vermischt werden. Public Function spgetn() As Long Diese Funktion liefert einen zum aktuell gewählten Darstellungszeitraum (also beispielsweise Monat, Quartal, Jahr, etc.) und zum in der Tabelle TKurs vorhandenen Maximalwert des Attributes n passenden unteren Grenzwert für n. Dadurch kann die unter Umständen grosse Anzahl von Kurs- und Umsatzdaten erheblich eingeschränkt werden. Da die Anzahl der Datensätze für einen Darstellungszeitraum aufgrund von Wochenenden und Feiertagen unterschiedlich sein kann, sollten die Daten nach Wertpapier-ID und n (also gemäÿ dem Primäschlüssel der TKurs-Tabelle) in absteigender Sortierung geliefert werden, damit das Einlesen der Daten am Anfang des Darstellungszeitraumes durch TInTo abgebrochen und keine überüssigen Daten eingelesen werden müssen. Public Function spgetpar(p As String) As Double Die Funktion spgetpar fragt einen für die Indikatorberechnung notwendigen Parameter beim Anwender ab. Der Funktion muss die entsprechende Rückfrage, ggf. inklusive optionalem Standardwert, übergeben werden. Der Aufruf spgetpar(grenzwert eingeben=10) fragt den Anwender also nach dem Grenzwert und gibt im Eingabefeld der Rückfrage bereits den Standardwert 10 vor. Dieser kann vom Benutzer einfach bestätigt, oder aber modiziert und dann bestätigt werden. Die Eingabe wird in einen 67

72 5 Implementierung Gleitkommawert umgewandelt. Dieser Rückgabewert der Funktion wird dann in der SQL-Anweisung für die Ausführung der Abfrage als statischer Wert betrachtet. Die in den Grundlagen (vgl. Kapitel 3.6) vorgestellte Gliederung der markttechnischen Indikatoren in Trendfolgeindikatoren (TF), Oszillatoren (OS), Trendbestimmungsindikatoren (TB, auch richtungs- und dynamikbestimmende Indikatoren) und Volatilitätsindikatoren (VO) ist im Bezug auf deren Berechnungskomplexität allerdings unbrauchbar. Daher sollen hier die Indikatoren nach deren Schwierigkeit im Bezug auf ihre Umsetzung klassiziert werden. Die sich ergebenden unterschiedlichen Komplexitätsklassen sind: Aggregatfreie Indikatoren (OA) Die Indikatoren dieser Komplexitätsklasse sind die am einfachsten zu berechnenden Indikatoren. Sie erfordern keine Aggregatbildungen und berechnen den Indikator über die zum Handelstag vorliegenden Kurs- und Umsatzwerte. Indikatoren mit einfachen Aggregaten (AVG, MIN, MAX) (EA) Zur Berechnung der Indikatoren dieser Komplexitätsklasse sind einfache Aggregate erforderlich. In den meisten Fällen sind dies Durchschnitte (AVG), die durch die Verknüpfung der Kurstabelle auf sich selber und einer entsprechenden Gruppierung berechnet werden. Indikatoren mit mehrstugen Aggregaten (MA) Die Indikatoren dieser Komplexitätsklasse sind mehrstug aufgebaut und erfordern eine Aggregatbildung auf einer bereits bestehenden Aggregatbildung. Oft ist es bei der Berechnung dieser Indikatoren notwendig, auf einem berechneten Durchschnitt nach bestimmten Operatoren einen weiteren Durchschnitt zu berechnen. Die hierzu erforderlichen Sichten bauen hierarchisch aufeinander auf. Rekursive Indikatoren (RI) Die Denition dieser Indikatoren ist rekursiv aufgebaut, die Indikatorwerte für einen Handelstag beruhen also auf den Indikatorwerten für einen bereits berechneten Handelstag. Die rekursive Formulierung von Sichten wird in dem von Access unterstützten SQL-92 gar nicht, aber auch in aktuellen DBMS, sofern überhaupt vorhanden, nur rudimentär unterstützt. Daher sind diese Indikatoren die am schwierigsten zu berechnenden, da sie, wenn überhaupt, nur durch geschickte Abfrageformulierungen berechnet werden können. Insgesamt wurden in TInTo die gebräuchlichsten technischen Indikatoren umgesetzt (siehe Tabelle 5.1), wobei durch den gewählten generischen Ansatz beliebige weitere Indikatoren zu ergänzen sind. In den folgenden Abschnitten wird für jeweils einen Vertreter der vier Komplexitätsklassen die unter TInTo erarbeitete Lösung im Detail vorgestellt. Andere Indikatoren 68

73 5.4 Umsetzung der Indikatorklassen in TInTo Symbol Name Typ Problemklasse ACC Accelerator OS EA ADL Accumulation Distribution Line TB EA ADO A/D Oscillator OA ADX Average Directional Movement Index TB MA AroonOsc Aroon Osc OS EA AroonUpDown Aroon Up/Down TB EA ATR Average True Range VO ME BMP Balance of Market Power TB EA CCI Commodity Channel Index TB MA CMF Chaikin Money Flow TB EA DMI Directional Movement Index TB MA MACD Moving Average Convergence/Divergence TB,TF RI Momentum Momentum OS EA RSI Relative Strength Index OS EA SMA Simple Moving Average TF EA FSTOC Fast Stochastic OS MA SSTOC Slow Stochastic OS MA Tabelle 5.1: In TInTo aktuell implementierte Indikatoren der gleichen Komplexitätsklasse lassen sich dann auf identische oder ähnliche Weise abbilden Aggregatfreie Indikatoren Die technischen Indikatoren aus dieser Problemklasse sind die im Bezug auf ihre Formulierung in SQL am einfachsten zu berechnenden Indikatoren. Es werden keine Aggregate und damit auch keine Verknüpfungen benötigt. Die Berechnung des Indikators erfolgt rein über die Kurs- und Umsatzwerte für ein Datensatz. Beispiel: ADO Accumulation/Distribution Oscillator Beschreibung: Die Begrie Accumulation und Distribution tauchen bei vielen technischen Indikatoren auf. Meist wird damit die Kaufkraft, also die Stärke des Engagements der Marktteilnehmer, die in einen Markt oder ein Wertpapier einsteigen und die Verkaufskraft, also die Stärke der Marktteilnehmer, die sich aus diesem Markt zurückziehen, beschrieben. Der ADO Indikator (siehe Abbildung 5.5) versucht nun, diese beiden gegenläugen Kräfte zu beschreiben und gegenüberzustellen. Ziel ist es zu prüfen, ob der Markt genug Kraft zum steigen hat oder ob eher die abwärts wirkende 69

74 5 Implementierung Abbildung 5.5: TInTo-Darstellung des ADO A/D Oscillator im unteren Diagrammbereich. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Kraft dominierender sein wird. Berechnung: Die Berechnung des ADO ist äusserst simpel. Der Indikator enthält keine Glättungskomponente, es sind also keine Durchschnitte zu berechnen. ADO(t) = (High(t) Open(t)) + (Close(t) Low(t)) 2 (High(t) Low(t)) Der Indikator lässt sich also allein aus den Kurswerten High, Open, Low und Close durch einfache Operationen für einen Handelstag berechnen. TInTo-Umsetzung: Die einfache Berechnung des ADO spiegelt sich auch in seiner SQL-Formulierung in TInTo wieder. Da keine Durchschnitte zu berechnen sind, ist auch keine Verknüpfung der Kurstabelle mit Gruppierung und Aggregatbildung notwendig. Die erforderlichen Kurs- und Umsatzwerte sowie der berechnete Indikator können direkt in der SELECT-Klausel der Abfrage formuliert werden: 1 SELECT ID, n, Date, High, Low, Open, Close, Vol, 2 (High-Open)+(Close-Low)/(2*(High-Low)) AS Ind1 3 FROM Tkurs 4 WHERE ID=spGetID() AND n>spgetn() 5 ORDER BY ID DESC, Date DESC 70

75 5.4 Umsetzung der Indikatorklassen in TInTo In der ersten Zeile der Abfrage werden die Basiswerte der Tabelle TKurs in die Ausgabe mit aufgenommen. Die zweite Zeile enthält die Berechnung des ADO Indikators gemäÿ der oben angegeben Formel, der Alias Ind1 ist zur programmseitigen Erkennung des Ausgabefeldes wichtig. Die Tabelle TKurs ist als einzige Quelltabelle der FROM-Klausel in der dritten Zeile enthalten. Die WHERE-Klausel der vierten Zeile enthält die Einschränkung auf die Wertpapier-ID sowie die Einschränkung der Daten passend zum Anzeigeintervall. Die fünfte Zeile sortiert die Daten in der von TInTo geforderten chronologisch absteigenden Sortierung. Da die Darstellung eines Indikators immer bis zum aktuellen Handelstag, der erste zu betrachtende Handelstag allerdings durch die Eingabe möglicher Parameters variabel ist, werden die Werte in absteigender Sortierung angeliefert. So kann das programmseitige Einlesen der Werte zur Übergabe an den ChartDirector an der richtigen Stelle abgebrochen werden. Interpretation: Der A/D Oscillator misst die vorherrschenden Marktkräfte und signalisiert durch seine Bewegungen die Veränderungen innerhalb des Marktgefüges. Dabei ist der Indikator leider sehr schnelllebig und liefert ein zackiges und fast chaotisches Bild. Mit Hilfe des Indikators können Aussagen zu Kaufdruck und Verkaufsdruck gemacht werden. Steigende Werte signalisieren einen zunehmenden Kaufdruck. Es erscheint sinnvoll, dem Indikator zwei Extremzonen zu spendieren, in denen er sich bei Bedarf aufhalten kann. Hat eine der beiden Marktkräfte die Übermacht erlangt, wird sich der Indikator in der entsprechenden Extremzone aufhalten und diesen Machtüberschwang signalisieren. Es können also Wendepunkte oder Übertreibungsphasen erkannt werden, um an den darauf folgenden Korrekturen zu verdienen. Bendet sich der Indikator in einer der beiden Extremzonen, so handelt es sich meist um eine kurzfristig stark übertriebene Kursbewegung. Hier könnte auf eine kurze scharfe Korrektur spekuliert werden Indikatoren mit einfachen Aggregaten Die Indikatoren dieser Problemklasse erfordern zur Berechnung eine Aggregatbildung, meist einen einfachen Durchschnitt (AVG), oder aber auch Extremwerte (MIN, MAX). Dazu ist die Verknüpfung der Kurstabelle auf sich selber nötig um die erforderlichen Werte für die Berechnung zu liefern. Diese Vorgehensweise erhöht aufgrund der Verknüpfung die Anzahl der zu betrachtenden Datensätze. Da aufgrund der Verknüpfung meist mehrere Datensätze betrachtet werden, die zeitlich vor dem berechneten und angezeigten Intervall liegen, sollte sichergestellt sein, dass die entsprechenden Sätze vorhanden sind. Dies ist in TInTo der Fall, da die Kurs- und Umsatzinformationen ab dem angeladen und gespeichert werden, das maximale Anzeigeintervall jedoch höchstens 5 Jahre ab dem aktuellen Datum beträgt. 71

76 5 Implementierung Abbildung 5.6: TInTo-Darstellung des RSI Relative Strength Index im unteren Diagrammbereich mit oberem und unterem Grenzbereich. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Beispiel: RSI Relative Strength Index Beschreibung: Der von Welles Wilder erdachte RSI, dargestellt in Abbildung 5.6, vergleicht die Stärke von Kursverlusten einer Periode mit den Kursgewinnen und ermittelt dadurch die innere Stärke des Basistitels. Er gilt als Momentum-Indikator und wird oft als Weiterentwicklung des Momentums verstanden. Er arbeitet mit den Kursveränderungen einer festen Berechnungsperiode. Mit dem RSI werden zwei Probleme des klassischen Momentum-Oszillators gelöst (vgl. auch Kapitel 3.6.2). Das Momentum ist sehr anfällig für einzelne Extremwerte im Basistitel. Wird das 10 Tage Momentum gemessen und vor 10 Tagen gab es einen extremen Kursausschlag, so wird das den aktuellen Momentumwert stark beeinussen, obwohl dieser Extremkurs längst korrigiert wurde. Der RSI löst dieses Problem, indem er eine interne Glättung der verwendeten Summen vornimmt. Das zweite Problem ist die oene Skala des Momentum-Oszillators. Dadurch wurde der Vergleich mehrerer Aktien nach ihren Momentum-Werten erschwert. Dies wird beim RSI durch Skalierung des Indikators auf eine konstante Bandbreite zwischen 0 und 100 gelöst. Berechnung: Die Berechnung des RSI ist aufwändiger als die des ADO, die folgenden Rechenschritte lassen sich jedoch in der anschliessend in TInTo formulierten SQL- Abfrage zusammenfassen. Zunächst werden zwei Summen gebildet. Die eine enthält 72

77 5.4 Umsetzung der Indikatorklassen in TInTo alle Kursveränderungen an Tagen mit gestiegenem Schlusskurs. Die zweite enthält alle Kursveränderungen von Tagen mit gefallenem Schlusskurs. Up(t) = Down(t) = { Close(t) Close(t 1) für Close(t) > Close(t 1) 0 sonst { Close(t 1) Close(t) für Close(t) < Close(t 1) 0 sonst Es folgt eine Glättung der Werte, indem ein einfacher Durchschnitt berechnet wird. Jede der beiden Summen wird durch die Berechnungsperiode dividiert (dabei ist n ein statischer Parameter). SU(t) = n 1 i=0 Up(t i) SD(t) = n 1 i=0 Down(t i) AvgSU = SU n AvgSD = SD n Abschliessend wird der RSI inklusive Skalierung berechnet: RSI(t) = 100 AvgSU AvgSU + AvgSD Es gibt abweichende Berechnungen ohne Glättung oder mit exponentieller statt einfacher Glättung. Die Skala des RSI wird mit zwei Extremzonen geteilt. Die eine beginnt bei 70 und trennt den Überkauft-Bereich nach oben ab. Die zweite Zone beginnt ab 30 nach unten und wird als Überverkauft-Bereich bezeichnet. TInTo-Umsetzung: Wie bereits angedeutet, lässt sich die mehrschrittige Berechnung in der Formulierung des SQL zusammenfassen, wobei sich jedoch eine etwas komplexere Formulierung nicht vermeiden lässt. Dabei sind zwei Verknüpfungen der Kurstabelle auf sich selber notwendig. Die erste Verknüpfung (TK2) dient der Berechnung der Up(t) und Down(t); hier müssen Werte eines Handelstages mit den Werten des Vortages verglichen werden. Die zweite Verknüpfung (TK1) dient der notwendigen Durchschnittsbildung für die Glättung der Up(t) und Down(t). Die eigentliche Berechnung des RSI geschieht dann ebenfalls im SELECT-Teil direkt auf den per AVG berechneten Durchschnitten. 1 SELECT TKurs.ID,TKurs.n,TKurs.Date, 2 TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol, 3 100*(AVG(IIF(TK1.Close>TK2.Close,TK1.Close-TK2.Close,0))/ 4 (AVG(IIF(TK1.Close>TK2.Close,TK1.Close-TK2.Close,0))+ 5 AVG(IIF(TK1.Close<TK2.Close,TK2.Close-TK1.Close,0)))) 73

78 5 Implementierung 6 AS Ind1 7 FROM (TKurs INNER JOIN TKurs AS TK1 ON (TKurs.ID=TK1.ID)) 8 INNER JOIN Tkurs AS TK2 ON (TK1.ID=TK2.ID AND 9 TK1.n-1=TK2.n) 10 WHERE Tkurs.ID=spGetID() AND 11 Tkurs.n>spGetN() AND 12 TK1.n<=TKurs.n AND 13 TK1.n>=TKurs.n-spGetPar("Periodenvorgabe=14") 14 GROUP BY TKurs.ID,TKurs.n,TKurs.Date, 15 TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol 16 ORDER BY Tkurs.ID DESC, Tkurs.Date DESC Zeile 3 berechnet AvgSU und bildet den Zähler der Division in der RSI-Berechnung. In Zeile 4 wird nochmals der AvgSU berechnet, der gemeinsam mit dem in Zeile 5 berechneten AvgSD den Nenner der Division bildet. Der Bruch wird mit 100 multipliziert (Zeile 3) und der fertig berechnete RSI als Alias Ind1 zurückgeliefert. Da jeweils der Schlusskurs mit dem Schlusskurs des Vortages verglichen werden muss, wird die Kurstabelle in den Zeilen 7-9 zweimal mit sich selber verknüpft. Die Einschränkung auf Wertpapier-ID und Zeitraum gleicht der Berechnung des ADO im vorhergehenden Kapitel. Zusätzlich wird noch die Periodenvorgabe abgefragt und entsprechend für die Aggregatbildung eingeschränkt. Aufgrund der Aggregate ist ausserdem eine Gruppierung auf die Basis-Kurs- und Umsatzwerte notwendig. Die Sortierung ist wieder chronologisch absteigend, die jüngsten Werte werden also zuerst angeliefert. Interpretation: Durch die Extremzonen ergibt sich die folgende Interpretation des RSI. Werte des Indikators über 70 zeigen eine überkaufte Situtation an. Ein Verkaufssignal entsteht bei der Wende des Indikators nach unten. Werte des Indikators unter 30 zeigen dagegen eine überverkaufte Situation an. Ein Kaufsignal entsteht bei der Wende des Indikators nach oben. Vorhandene Divergenzen zwischen Indikator und Aktie deuten auf eine Trendwende Indikatoren mit mehrstugen Aggregaten Diese Problemklasse zeichnet sich durch die Notwendigkeit der mehrstugen Berechnung aus. Dies ist beispielsweise der Fall bei Indikatoren, bei denen auf bereits berechneten Durchschnitten eine erneute Durchschnittsbildung notwendig ist. In TInTo wird dies durch die hierarchische Anordnung der Sichten realisiert. Eine Indikator-Abfrage darf also nicht nur auf die Basiswerte der Kurstabelle zugreifen, sondern auch auf beliebige andere, in TInTo bereits denierte, Abfragen. 74

79 5.4 Umsetzung der Indikatorklassen in TInTo Abbildung 5.7: TInTo-Darstellung des SSTOC Slow Stochastik im unteren Diagrammbereich mit gleichzeitiger Darstellung der K- und D-Linien. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Beispiel: SSTOC Slow Stochastik Beschreibung: Der Stochastik-Indikator, dargestellt in Abbildung 5.7, ist sicherlich der am meisten verwendete Indikator überhaupt. Man ndet ihn in jedem Software- Paket, in jedem Charting-Tool und auf jeder Website die Charts und Kurse anbietet. Jedes Anlegermagazin, das sich mit technischer Analyse beschäftigt, bildet Aktiencharts mit diesem Indikator ab. Der Stochastik-Oszillator zeigt an, wo sich innerhalb der Handelsspanne einer festgelegten Berechnungsperiode der aktuelle Schlusskurs be- ndet. Dazu wird die Spanne aus höchsten und tiefsten Kurs des Betrachtungszeitraumes ermittelt. Im Aufwärtstrend wird der Schlusskurs im oberen Bereich dieser Spanne liegen und dort möglicherweise längere Zeit verweilen. Im Abwärtstrend wird der Schlusskurs im unteren Bereich dieser Spanne liegen und dort möglicherweise ebenfalls länger verweilen. In Märkten die sich wellenförmig bewegen, möglichst noch in kleinen Spannen, gelingt die Ermittlung eines Marktgipfels oder eines Kurstals recht gut. In lang ausgeprägten Trendphasen ist dies jedoch nicht möglich. Berechnung: Zunächst wird die maximale Handelsspanne der betrachteten Handelsperiode ermittelt. Die Dierenz aus dem höchsten Kurs der in dieser Zeit gehandelt wurde und dem niedrigsten Kurs, der innerhalb dieser Zeit gehandelt wurde, ergibt unsere gesuchte Handelsspanne. In der Berechnung sei n die Länge des Betrachtungszeitraumes. Es gilt also 75

80 5 Implementierung H(n)=höchster Kurs des Betrachtungszeitraumes L(n)=tiefster Kurs des Betrachtungszeitraumes H(n)-L(n)=Handelsspanne In der Stochastik-Berechnung wird nun die Dierenz aus dem aktuellen Schlusskurs und dem niedrigsten Kurs des Zeitraumes gebildet und dieser Wert durch den Wert der ermittelten Handelsspanne dividiert. Der als %K bezeichnete Stochastik-Oszillator ergibt sich aus dem Quotienten dieser Division multipliziert mit 100. Der so berechnete Indikator wird als Fast-Stochastik bezeichnet. K(t) = Close(t) L(n) H(n) L(n) 100 Eine auf den Indikator berechnete Signallinie wird mit %D-Linie bezeichnet. Es wird ein einfacher gleitender Durchschnitt auf den %K-Oszillator berechnet. Beide Linien werden dann gemeinsam dargestellt. D(t) = m 1 i=0 K(t i), m = Berechnungsperiode Das Verlaufsmuster der %K-Linie ist sehr unruhig und auch die Verwendung der %D-Linie wird dadurch erschwert. Deshalb wird in der Regel eine geglättete Version des Indikators verwendet. o 1 S(t) = D(t i), o = Berechnungsperiode i=0 Die %D-Linie wird somit als Slow Stochastik bezeichnet, die dazu berechnete geglättete Version ist die Signallinie des Indikators. TInTo-Umsetzung: Die Berechnung des SSTOC inklusive seiner Signallinie wird in TInTo durch drei hierarchisch verschachtelte Abfragestufen durchgeführt. Die erste Abfrage FSTOC0 bildet den ersten Schritt in der Berechnung der Stochastik- Indikatoren und liefert die %K-Linie im Attribut Ind1. Die Berechnung der L(n) und H(n) geschieht mittels Min() und Max()-Aggregaten in Zeilen 3 und 4 über die beim Benutzer abgefragten Periode. Dazu ist eine Verknüpfung der Kurstabelle auf sich selbst notwendig (Zeile 5). Die Sortierung ist auch hier wieder chronologisch absteigend. Die jüngsten Werte werden also zuerst angeliefert, was für alle hier aufgeführten Abfragen gilt. 76

81 5.4 Umsetzung der Indikatorklassen in TInTo 1 SELECT TKurs.ID,TKurs.n,TKurs.Date, 2 TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol, 3 ((Tkurs.Close-Min(TK1.Low))/ 4 (Max(TK1.High)-Min(TK1.Low)))*100 AS Ind1 5 FROM TKurs INNER JOIN TKurs AS TK1 ON (TKurs.ID=TK1.ID) 6 WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN() AND 7 TK1.n<=TKurs.n AND 8 TK1.n>=TKurs.n-spGetPar("Periode K-Linie=10") 9 GROUP BY TKurs.ID,TKurs.n,TKurs.Date, 10 TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol 11 ORDER BY Tkurs.ID DESC,Tkurs.Date DESC Die Abfrage FSTOC in der hierarchisch darüber liegenden Ebene berechet den Indikator FSTOC Fast Stochastik inklusive seiner geglätteten Signallinie und basiert auf der zuvor berechneten Abfrage FSTOC0. Der in FSTOC0 berechnete %K-Wert wird hier mittels eines einfachen gleitenden Durchschnittes in Zeile 2 als Ind2 geglättet, was dem %D-Wert in der obigen Berechnung entspricht. Zu diesem Zweck wird die FSTOC0-Abfrage in Zeile 4 mit sich selbst verknüpft. 1 SELECT FSTOC0.ID,FSTOC0.n,FSTOC0.Date, 2 FSTOC0.High,FSTOC0.Low,FSTOC0.Open,FSTOC0.Close,FSTOC0.Vol, 3 FSTOC0.Ind1,AVG(FSTOC1.Ind1) AS Ind2 4 FROM FSTOC0 INNER JOIN FSTOC0 AS FSTOC1 ON 5 (FSTOC0.ID=FSTOC1.ID) 6 WHERE FSTOC1.n<=FSTOC0.n AND 7 FSTOC1.n>=FSTOC0.n-spGetPar("Periode D-Linie=3") 8 GROUP BY FSTOC0.ID,FSTOC0.n,FSTOC0.Date, 9 FSTOC0.High,FSTOC0.Low,FSTOC0.Open,FSTOC0.Close,FSTOC0.Vol, 10 FSTOC0.Ind1 11 ORDER BY FSTOC0.ID DESC,FSTOC0.Date DESC Basierend auf dem gerade berechneten FSTOC Indikator wird nun auf der hierarchisch obersten Ebene eine weitere Glättung (in Zeile 4) durchgeführt und man erhält den Indikator %D inklusive der neuen Signallinie %S. Auch hierzu ist wiederum eine Verknüpfung notwendig, jetzt aber von der Abfrage FSTOC auf sich selbst (siehe Zeile 5). 1 SELECT FSTOC.ID,FSTOC.n,FSTOC.Date, 2 FSTOC.High,FSTOC.Low,FSTOC.Open,FSTOC.Close,FSTOC.Vol, 3 FSTOC.Ind2 AS Ind1, 4 AVG(FSTOC1.Ind2) AS Ind2 5 FROM FSTOC INNER JOIN FSTOC AS FSTOC1 ON (FSTOC.ID=FSTOC1.ID) 6 WHERE FSTOC1.n<=FSTOC.n AND 7 FSTOC1.n>=FSTOC.n-spGetPar("Periode Slow-D-Linie=3") 8 GROUP BY FSTOC.ID,FSTOC.n,FSTOC.Date,FSTOC.High,FSTOC.Low, 77

82 5 Implementierung 9 FSTOC.Open,FSTOC.Close,FSTOC.Vol,FSTOC.Ind2 10 ORDER BY FSTOC.ID DESC,FSTOC.Date DESC Insgesamt ergibt sich die folgende Abhängigkeit zwischen der Basistabelle und den denierten Abfragen: T Kurs F ST OC0 F ST OC SST OC Die Basistabelle TKurs liefert also die Daten für die Abfrage FSTOC0, diese ist wiederum Grundlage für die Berechnung des FSTOC Fast Stochastik Indikators, welche die Werte für die Berechnung des SSTOC Slow Stochastik Indikators liefert. Interpretation: Das Ergebnis der Berechnung ist eine um die Mittellinie schwingende Kurve. Die Skala des Indikators liegt zwischen 0 und 100. Werte ab 80 gelten als überkauft, dort wird eine entsprechende Extremzone markiert. Werte unter 20 gelten als überverkauft, dort wird ebenfalls eine entsprechende Extremzone markiert. Stochastikwerte nahe 100 zeigen an, dass der Basiswert am Hoch der betrachteten Zeitspanne gehandelt wird. Stochastikwerte nahe 0 zeigen an, dass der Basiswert am Tief der betrachteten Zeitspanne gehandelt wird. Wichtiger ist die Verwendung der Signallinie. Findet im Basiswert eine Veränderung der Kursrichtung statt, wird der Indikator ebenfalls die Richtung wechseln. Dieser Richtungswechsel wird durch den Schnitt mit der Signallinie erkannt. Man erhält also frühzeitig Informationen über eine veränderte Tendenz in den Kursbewegungen. Schneidet der Indikator die Signallinie nach oben, gilt dies als Kaufsignal. Schneidet der Indikator die Signallinie nach unten, gilt dies als Verlaufssignal Rekursive Indikatoren Die technischen Indikatoren dieser Problemklasse gehören für TInTo zu den am schwierigsten zu berechenden Indikatoren, da ihre Denition rekursiv ist, d.h. für die Berechnung eines Indikatorwertes wird mindestens ein Vorgängerwert des Indikators benötigt. Naheliegend wäre für diese Indikatoren eine rekursive Formulierung der Abfrage. Diese ist hier allerdings nicht möglich, da sie in dem von Access unterstützten SQL- 92 gar nicht angeboten wird. Aber auch in aktuellen DBMS werden Rekursionen, sofern überhaupt vorhanden, nur rudimentär unterstützt. Weiterhin besäÿe die rekursive Formulierung einen enormen Ezienznachteil, da notwendige Indikatorwerte, je nach Implementierung der Rekursion im DBMS, viel zu häug berechnet würden. Wie beim nachfolgend vorgestellten MACD-Indikator sind die meisten rekursiv de- nierten Indikatoren in ihrem Wert abhängig von einem der Vorgängerwerte. Ohne Zwischenspeicherung der Werte ist dies jedoch für die klassische Rekursion, welche 78

83 5.4 Umsetzung der Indikatorklassen in TInTo erst bei baumartigen Strukturen ihre volle Ezienz und Eleganz zeigt, eine äuÿerst ungünstige Denition. Wesentlich ezienter lassen sich derartige Indikatoren mit dem folgenden Workaround berechnen. Es wird nun der MACD-Indikator vorgestellt, der aufgrund der Verwendung des exponentiellen gleitenden Durchschnitts rekursiv formuliert ist. In TInTo kann dieser Indikator dennoch durch die Anwendung von Aktionsabfragen, rein in der Abfragesprache SQL, formuliert und berechnet werden. Abbildung 5.8: TInTo-Darstellung des MACD Moving Average Convergence/Divergence im unteren Diagrammbereich mit Darstellung des MACD, der zugehörigen Signallinie sowie der Dierenz aus MACD und Signallinie als Histogramm. Zugrundeliegende Kurs- und Umsatzdaten im oberen Diagrammbereich. Beispiel: MACD Moving Average Convergence/Divergence Beschreibung: Der MACD ist ein von Gerald Appel in den späten 70er Jahren entwickelter Indikator, der sowohl Trendrichtung als auch Trendstärke anzeigt und der in der Lage ist, auf Trendwechsel im Basiswert hinzuweisen. Dargestellt wird er in Abbildung 5.8. Zudem kann der MACD direkt als Signalgeber für Handelssignale verwendet werden. Er basiert auf zwei exponentiellen gleitenden Durchschnitten unterschiedlicher Länge, deren Dierenz er darstellt. Trotz dieses einfachen Aufbaus ist der MACD heute einer der am meisten verwendeten Indikatoren. Der MACD vereinigt zwei wichtige Indikatoreigenschaften in sich. Er hat eine starke trendfolgende Komponente, weil er dem Basiswert innerhalb einer Trendbewegung 79

84 5 Implementierung zu neuen Hoch- und Tiefpunkten folgt. In dieser Funktion zeigt er Trendrichtung und Stärke an. Der MACD hat aber auch Oszillator-Eigenschaften, da er um seine Nulllinie schwingt und Divergenzen zum Kursverlauf des Basiswertes aufzeigt. In Verbindung mit seiner Signallinie erzeugt er ähnlich wie andere Oszillatoren direkte Handelssignale. Berechnung: Zur Berechnung des MACD werden zunächst zwei exponentielle gleitende Durchschnitte EMA nach der folgenden Formel berechnet: EMA(t) = (Close(t) EMA(t 1)) Ew(t) + EMA(t 1) Dabei ist Ew(t) der Gewichtungsfaktor: Ew(t) = 2 n + 1 Aus den so berechneten Durchschnitten EMA1(t) (exponentieller Durchschnitt der kürzeren Berechnungsperiode) und EMA2(t) (exponentieller Durchschnitt der längeren Berechnungsperiode) ergibt sich direkt der MACD, indem vom Wert des kürzeren der Wert des längeren Durchschnitts abgezogen und das Ergebnis als Linie dargestellt wird. MACD(t) = EMA1(t) EMA2(t) Für den kurzen Durchschnitt werden 12 Tage verwendet, für den langen 26 Tage. Die Wahl der Parameter basiert unter anderem auf den Zyklen der von Appel beobachteten Märkte. Als dritte und vor allem sehr wichtige Komponente wird auf die MACD-Linie eine Signallinie mit einer Glättung (wiederum ein exponentieller gleitender Durchschnitt) von 9 Tagen berechnet. TInTo-Umsetzung: Die Berechnung des MACD in TInTo gestaltet sich naturgemäÿ sehr schwierig, da die Formulierung von rekursiven Sichten in dem von Access 2003 unterstützen SQL-92 Dialekt nicht möglich ist. Daher wird in TInTo zu einem Trick gegrien. Die rekursive Berechnung sowohl der exponentiellen Durchschnitte als auch der nachträglichen Glättung wird durch mehrere Aktionsabfragen auf den Hilfsvariablen v1, v2 und v3 der Tabelle TKurs durchgeführt. Diese Hilfsvariablen fungieren als Zwischenspeicher für die Berechnung des Indikators. Aufgrund dieser Art der Berechnung kann eine Rekursion vermieden werden. Im ersten Schritt der Berechnung werden die Schlusskurse des jeweiligen Handelstages in die Hilfswerte v1 und v2 der Kurstabelle eingetragen. 80

85 5.4 Umsetzung der Indikatorklassen in TInTo n-3 n-2 n-1 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 Close Close Close Close Close Ausgehend von diesen Hilfswerten werden im zweiten Schritt die beiden exponentiellen Durchschnitte EMA1 und EMA2 berechnet. Die folgende Abbildung verdeutlicht dies lediglich für die EMA1-Berechnung. Dabei wird die folgende Eigenschaft von SQL genutzt: Wenn eine UPDATE-Anweisung eine ORDER BY-Klausel enthält, werden die Datensätze in der in der Klausel angegebenen Reihenfolge aktualisiert. Da die v1 damit in aufsteigender Indexreihenfolge berechnet werden, enthält der Wert des vorherigen Handelstages v1 (n-1) für die Berechnung v1 (n) des aktuellen Handelstages bereits den zuvor berechneten und gesetzten Wert. Dies ist der Kern dieser simulierten Rekursion. Erst dieses Verhalten des DBMS ermöglicht die Berechnung des MACD auf diese Art. Die Berechnung des EMA2 auf v2 geschieht analog. n-3 n-2 n-1 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 EMA1 EMA1 Gleichzeitig wird in v3 die Dierenz zwischen EMA2 und EMA1 gespeichert, dies ergibt den MACD. n-3 n-2 n-1 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 EMA2-EMA1=MACD..... Der jetzt in v3 vorliegende MACD muss nochmals geglättet werden. Dies geschieht mit Hilfe des gleichen Verfahrens wie bereits zuvor die Berechnung der EMA1 und EMA2. Dabei sei die Durchschnittsbildung durch das Tildesymbol (~) repräsentiert. Damit stehen alle erforderlichen Werte in den Hilfsvariablen zur Verfügung: v1 enthält EMA1, v2 enthält EMA2, (v2 -v1 ) enthält den MACD und v3 enthält den exponentiell 81

86 5 Implementierung n-3 n-2 n-1 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 v1 v2 v3 ~MACD ~MACD geglätteten MACD. Diese Werte können dann mit einer einfachen Abfrage abgerufen und anschliessend dargestellt werden. Die erste Aktionsabfrage initialisiert also die Hilfswerte v1 und v2 mit den Schlusskursen des jeweiligen Handelstages. Die Reihenfolge der Aktualisierung ist hier unwichtig. 1 UPDATE Tkurs 2 SET v1=close, v2=close 3 WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()-2 Die zweite Aktionsabfrage berechnet die beiden exponentiellen Durchschnitte EMA1 und EMA2. Da die Werte durch die Abfrage in Indexreihenfolge berechnet werden, liefert der Zugri auf den Vortageswert über die Verknüpfung (Zeilen 1 und 2) den bereits berechneten EMA-Wert für den Vortag. Durch diesen Trick wird die Berechnung der beiden Durchschnitte realisiert. Der EMA für die längere Berechnungsperiode wird dabei in v1 berechnet, der EMA für die längere Berechnungsperiode in v2. Ausserdem wird der Hilfswert v3 direkt durch Subtraktion der beiden EMA mit dem MACD initialisiert. 1 UPDATE Tkurs INNER JOIN Tkurs AS TK0 ON 2 (Tkurs.ID=TK0.ID AND (Tkurs.n-1)=TK0.n) 3 SET Tkurs.v1=((Tkurs.v1-TK0.v1)*2/(26+1))+TK0.v1, 4 Tkurs.v2=((Tkurs.v2-TK0.v2)*2/(12+1))+TK0.v2, 5 Tkurs.v3=((((Tkurs.v2-TK0.v2)*2/(12+1))+TK0.v2)- 6 (((Tkurs.v1-TK0.v1)*2/(26+1))+TK0.v1)) 7 WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()-1 8 ORDER BY TKurs.ID, TKurs.n Die dritte Aktionsabfrage errechnet auf Basis des v3 (enthält jetzt den MACD) auf die gleiche Art wie die zweite Abfrage den exponentiellen gleitenden Durchschnitt. Nach Ausführung dieser Abfrage enthält v1 also den EMA für die längere Berechnungsperiode, v2 den EMA für die kürzere Berechnungsperiode und v3 den exponentiellen Durchschnitt auf dem MACD. 1 UPDATE Tkurs INNER JOIN Tkurs AS TK0 ON 2 (Tkurs.ID=TK0.ID AND (Tkurs.n-1)=TK0.n) 3 SET Tkurs.v3=((Tkurs.v3-TK0.v3)*2/(9+1))+TK0.v3 82

87 5.4 Umsetzung der Indikatorklassen in TInTo 4 WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN() 5 ORDER BY TKurs.ID, TKurs.n Die letzte Abfrage deniert die eigentliche Sicht auf die Kurs-, Umsatz- und Indikatordaten. Dabei enthält Ind1 die Dierenz zwischen dem MACD (v2 -v1 ) und der Signallinie (dem exponentiellen Durchschnitt des MACD in v3 ). Aus dieser Dierenz sind direkte Handelssignale ableitbar. Ind2 enthält die Signallinie und Ind3 enthält den MACD-Indikator. 1 SELECT TKurs.ID,TKurs.n,TKurs.Date, 2 TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol, 3 (v2-v1)-v3 AS Ind1,(v2-v1) AS Ind3,v3 AS Ind2 4 FROM TKurs 5 WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN() 6 ORDER BY Tkurs.ID DESC, Tkurs.Date DESC Es sei darauf hingewiesen, dass diese Lösung zur Berechnung des MACD nur in einer Einzelplatzumgebung anwendbar ist. Arbeiten mehrere Anwender gleichzeitig auf einer TInTo-Datenbank und würden diese Anwender über unterschiedliche Zeiträume auf dem gleichen Wertpapier den MACD berechnen, so würden unterschiedliche Werte in die Hilfsfelder eingetragen und es kommt zu inkonsistenten Hilfswerten. Eine mögliche Lösung ist jedoch die Einführung einer eigenständigen und anwenderabhängigen Tabelle für die Hilfswerte. Da jeder Anwender jeweils nur einen Indikator berechnet, käme es dann zu keinen Kollisionen mehr. Das hier vorgestellte Prinzip der Berechnung ist ohne weiteres auf diese erweiterte Konstruktion anwendbar. Interpretation: Der MACD kann für verschiedene Analysezwecke verwendet werden. Als Trendfolger oder Trendlter kommt ihm die Aufgabe zu, die Trendrichtung des Basiswertes anzuzeigen, dessen Trendstärke zu bewerten und auf eventuelle Schwächephasen hinzuweisen. Als Signalgeber in der Art herkömmlicher Oszillatoren kommt ihm die Aufgabe zu, direkte Handelssignale zu erzeugen. Aus den Schnittsignalen mit der Mittellinie lassen sich diese Signale ableiten. Es handelt es sich dabei um ein einfaches Moving-Average-Crossover-System 7. Im Folgenden werden die wesentlichen Eigenschaften dieses wichtigen Indikators aufgelistet. Wesentliche Eigenschaften des MACD sind: Trendfolgende Eigenschaften; er vollzieht die Bewegung des Basiswertes samt Hoch und Tiefpunkten nach. Lage zur Mittellinie zeigt den Trend an. Entfernung zur Mittellinie ist ein Maÿ für die Trendstärke. 7 Einfaches Handelssystem; vgl. auch Kapitel

88 5 Implementierung Steigender MACD über der Mittellinie zeigt ein steigendes Momentum im Aufwärtstrend an. Fallender MACD unter der Mittellinie zeigt eine zunehmende Stärke im Abwärtstrend an. Fallender MACD über der Mittellinie zeigt nachlassende Intensität des Aufwärtstrends an. Steigender MACD unter der Mittellinie zeigt nachlassende Intensität des Abwärtstrends an. Divergenzen zwischen MACD und Kursverlauf weisen auf Schwächen im vorhandenen Trend hin und signalisieren bevorstehende Trendwechsel. Schnittpunkte der Mittellinie oder Schnittpunkte mit der Signallinie, möglichst nach vorangegangener Divergenz, gelten als mögliche Trendwechsel. Schnittpunkte von MACD und Signallinie oder MACD und Mittellinie gelten als Handelssignal. Abschliessend sei als Besonderheit des MACD nochmals auf seine Zwitterfunktion hingewiesen. Einerseits zeigt er ein oszillatorähnliches Verhalten, schwingt also um die Mittellinie und erzeugt oszillatortypische Handelssignale. Andererseits ist er ein trendfolgender Indikator, der wie ein herkömmlicher gleitender Durchschnitt dem Basiswert folgt und dessen Bewegungsmuster nachformt. Gerade diese Kombination macht ihn zu einem der beliebtesten Indikatoren in der technischen Analyse. 5.5 Leistungsbewertung und Ezienz Im Rahmen dieser Arbeit sollte untersucht werden, ob die Berechnung von technischen Indikatoren durch eine Formulierung in der Datenbanksprache SQL möglich ist und, wenn ja, mit welcher Ezienz eine solche Berechnung durchführbar ist. Bereits im Implementierungskapitel 5.4 wurde gezeigt, dass die Berechnung der Indikatoren der verschiedenen Komplexitätsklassen realisiert werden kann. Noch nicht diskutiert wurde, wie ezient dies möglich ist. Bei der Vorstellung der vier unterschiedlichen Komplexitätsklassen bei der Berechnung der technischen Indikatoren (Aggregatfreie Indikatoren, Indikatoren mit einfachen Aggregaten (AVG, MIN, MAX), Indikatoren mit mehrstugen Aggregaten sowie Rekursive Indikatoren) wäre durchaus zu erwarten gewesen, dass mit ansteigender Problemkomplexität ebenfalls die notwendige Berechnungskomplexität und damit die 84

89 5.5 Leistungsbewertung und Ezienz Berechnungsdauer ansteigen würde. Es ist leicht einzusehen, daÿ eine Abfrageformulierung ohne Aggregate und Verknüpfungen weniger Datensätze betrachten muss als eine Abfrage mit Aggregatbildung. Um die Leistungsfähigkeit der Berechnungen zu bewerten, werden die bereits im Kapitel 5.4 vorgestellten Indikatoren der unterschiedlichen Komplexitätsklassen für die verschiedenen Darstellungszeiträume untersucht. Die folgende Tabelle 5.2 listet die Laufzeiten für die Berechnung der Indikatoren auf einem Desktop-PC mit 3000 MHz AMD Sempron Prozessor in Millisekunden auf. Unter den Darstellungszeiträumen ist ausserdem die Anzahl der betrachteten Datensätze für den Zeitraum vermerkt. Monat Quartal 1 Jahr 3 Jahre 5 Jahre (18 Sätze) (62 Sätze) (250 Sätze) (754 Sätze) (1268 Sätze) ADO RSI SSTOC MACD Tabelle 5.2: Berechnungsdauer Indikatoren in Millisekunden Wie zu erwarten, steigt die Laufzeit für die Indikatoren der ersten drei Komplexitätsklassen kontinuierlich an. Der ADO-Indikator der ersten Komplexitätsklasse Aggregatfreie Indikatoren wird rein auf den vorhandenen Kurs- und Umsatzdaten eines Handelstages berechnet und kann daher bezogen auf die Anzahl der betrachteten Sätze in linearer Zeit in Bezug auf die Anzahl der Datensätze berechnet werden. Bei der Anzeige des RSI, einem Indikator der zweiten Komplexitätsklasse mit einfacher Aggregatbildung, muss die Kurstabelle für die Berechnung des gleitenden Durchschnittes mit sich selber verknüpft werden. Das Standardintervall für die Durchschnittsbildung ist dabei 14 Tage, also muss, neben dem Aufwand des DBMS für die Verknüpfung, die 14-fache Datenmenge im Vergleich zum ADO betrachtet werden. Dies spiegelt sich auch in den Laufzeiten der Berechnung wieder. Der Slow-Stochastic-Indikator SSTOC der dritten Komplexitätsklasse mit mehrstu- ger Aggregatbildung wird in insgesamt drei Stufen berechnet. Dabei werden über drei Abfragesichten, die hierarchisch aufeinander aufbauen, insgesamt drei gleitende Durschnitte mit unterschiedlichen Periodenvorgaben berechnet. Die Standardvorgaben des SSTOC sind dabei 10 Tage, 3 Tage sowie abermals 3 Tage. Daraus ergibt sich die Notwendigkeit für die Datenbank-Engine, insgesamt die 10*3*3 = 90-fache Datenmenge zu betrachten, was sich auch bei den Berechnungszeiten dieses Indikators bemerkbar macht. Auällig ist allerdings, dass die Rechenzeiten für den rekursiven MACD Indikator aufgrund der geschickten Berechnung über Aktionsabfragen vergleichsweise gering ausfallen. Die Berechnung des vermeintlich komplexesten Indikators benötigt also 85

90 5 Implementierung Berechnungsdauer Indikatoren msec ADO RSI SSTOC MACD Monat Quartal 1 Jahr 3 Jahre 5 Jahre Abbildung 5.9: Berechnungsdauer der vorgestellten Indikatoren der Komplexitätsklassen in Millisekunden nicht mehr Zeit als der Indikator der einfachsten Klasse ohne Aggregatbildung. Dies ist auch nicht weiter verwunderlich, da der bei der Berechnung des MACD keine Verknüpfung der Kursdaten auf sich selber benötigt wird. Daher kann der Indikator in linearer Zeit (im Bezug auf die Anzahl der Kursdatensätze) berechnet werden. Insgesamt bewegen sich die Berechnungszeiten der Indikatoren grundsätzlich im erwarteten Rahmen. Lediglich die Berechnungsdauer des rekursiv denierten MACD fällt aufgrund der unkonventionellen Berechnungsmethode erfreulich kurz aus. Unbefriedigend sind die Zeiten speziell bei den mehrstug-berechneten Indikatoren mit mehreren Durschnittsbildungen, hier wäre eine Verbesserung der Laufzeiten durchaus wünschenswert. Ezienzverbesserungen Abschliessend soll die Frage untersucht werden, ob die nicht zufriedenstellenden Rechenzeiten der mehrstug zu berechnenden Indikatoren nicht verbessert werden können. Aufgrund ihrer Denition sind mehrere Durschnittsbildungen notwendig. Diese lassen sich in Abfragen nur über Aggregate berechnen, welche eine Verknüpfung der Kurstabelle auf sich selber benötigen. Hierdurch wird die Zahl der betrachteten Datensätze erheblich vergröÿert. 86

91 5.5 Leistungsbewertung und Ezienz Vielleicht ist es möglich, durch Materialisierung der berechneten Werte eine bessere Performance zu erreichen? Die in TInTo verwendeten Abfragen sind bisher nur virtuelle Sichten. Sie werden bei jedem Zugri auf die Sicht vollständig neu berechnet. Anders verhält es sich bei materialisierten Sichten. Hier wird der jeweilige Inhalt explizit in der Datenbank gespeichert. Diese Sichten werden bei Erstellung einmal ausgewertet und ihre Daten sind jederzeit ohne Neuberechnung zugreifbar. Das Problem hierbei besteht jedoch darin, dass bei Basisdatenänderung die gespeicherten Daten unter Umständen angepasst werden müssen. Das in der Datenbankforschung untersuchte Verfahren der Änderungspropagierung (auch Update-Propagation) adressiert dieses Problem. Dennoch gibt es zur Zeit keine kommerziell verfügbare Realisierung dieser Methode, insbesonders auch, da noch viele Detailprobleme ungelöst sind. Auch Microsoft Access unterstützt die Änderungspropagierung nicht, so dass mögliche Methoden von Hand implementiert werden müssten. Eine Materialisierung der Daten macht insbesonders dann Sinn, wenn auf die abgeleiteten Daten häug zugegrien wird und sich die zugrundeliegenden Basisdaten nur wenig ändern. Ein häuger Zugri auf die gleichen materialisierten Daten ist in dem hier vorliegenden Fall der Indikatorberechnung nicht gegeben, aber der Zugri bei nur wenig geänderten Basisdaten kommt zwangsläug vor. Dies ist dann der Fall, wenn ein neuer Kurssatz hinzukommt. Dieser muss dann in die Berechnung mit aufgenommen werden und der älteste bisher in die Berechnung mit eingeganene Satz wird entfernt. t=0 vn... v1 Kurswerte Indikator n Sätze t=1 vn... v0 neu= alt- vn+v0 n Abbildung 5.10: Ezientere Indikatorberechnung durch Materialisierung des Indikators bei Durchschnittsbildung Exemplarisch soll nun ein möglicher Ansatz zur ezienteren Lösung der in der Indikatorberechnung sehr häug vorkommenden Berechnung des einfachen Durchschnitts vorgestellt werden. Wie in Abbildung 5.10 zu sehen, wird der Indikator mit Durchschnittsberechnung für eine Periode von n Tagen zunächst wie gewohnt berechnet 87

92 5 Implementierung und dann materialisiert, also dauerhaft gespeichert. Ist dieser erst einmal berechnet und abgelegt, ist beim Hinzukommen eines neuen Wertes keine erneute, vollständige Durchschnittsbildung mehr erforderlich. Es reicht vielmehr ein Zugri auf den ältesten Wert vn des Intervalls vom alten, bereits gespeicherten Durchschnitt. Dieser Wert wird dann durch den neu hinzukommenden Wert v0 anteilig, also geteilt durch n, ersetzt und das Ergebnis als neuer Durchschnitt gespeichert. Auch wenn dieses Verfahren ebenfalls eine Verknüpfung der Kurstabelle auf sich selber erfordert, so ist dennoch keine Aggregatbildung notwendig und die Zahl der in der Abfrage betrachteten Sätze wird dadurch nicht vergröÿert. Bereits bei diesem Beispiel wird jedoch auch deutlich, dass sich keine allgemein gültige Lösung für die Materialisierung der Daten im Fall der Indikatorberechnung und damit für die Anwendung der Änderungspropagierung nden lässt. Dies gilt insbesonders dann, wenn das Verfahren auf dem DBMS nicht unterstützt wird und nachprogrammiert werden muss. Da die verschiedenen Indikatoren auf vielfältigste Weise berechnet werden, müssten die Verfahren zur Materialisierung und zur Änderungspropagierung ebenfalls entsprechend vielseitig sein. Möglich wäre die Beschränkung auf bestimmte, bei der Indikatorberechnung immer wiederkehrende Probleme, beispielsweise der einfachen Durchschnittsbildung. Dies ist jedoch nicht Thema dieser Arbeit und wird gegebenenfalls in Folgearbeiten noch weiter untersucht. 5.6 Optimierungen und Anpassungen Bereits während der Implementierungs- und Testphasen wurden bei TInTo diverse Anpassungen und Optimierungen durchgeführt, deren Notwendigkeit bei der Denition der Indikatoren und bei der Anwendung des Tools auelen. Diese sollen im Folgenden dargestellt werden: ChartDirector-Einbindung Damit Microsoft-Access 2003 ohne Probleme mit dem ChartDirector zusammenarbeitet, muss die ChartDirector-Komponente zunächst installiert werden. Weiterhin muss in der Verweise-Datenbank von Visual Basic die Komponente ausgewählt und aktiviert sein. Zuletzt muss der ChartDirector über einen Schlüssel freigeschaltet werden, da dieser sonst in einem Demo-Modus mit einer entsprechenden Einrasterung läuft. Um dem Anwender diese Schritte abzunehmen, wird beim Starten von TInTo die Installation und Registrierung der erforderlichen DLL und OCX-Dateien 8 geprüft und 8 Dynamic Link Library: Programmbibliothek unter Windows. OCX: Softwarekomponenten, die unter dem Component Object Model (COM) arbeiten 88

93 5.6 Optimierungen und Anpassungen ggf. vorgenommen. Ausserdem wird in Visual Basic der entsprechende Verweis eingetragen sowie die Freischaltung des ChartDirectors vorgenommen. Dies erspart dem Anwender die mehrschrittige Installation und Einbindung des ChartDirectors. Statische SQL-Formulierung der Abfragen Im ersten Ansatz zur Berechnung der Indikatoren war eine Einschränkung nach Wertpapier-ID und betrachtetem Zeitbereich noch nicht notwendig. Diese Einschränkungen wurden nach Analyse der SQL-Gesamtklausel als Einschränkung in den WHERE- Bereich der Abfrage eingefügt. Ausserdem wurden die zur Indikator-Berechnung notwendigen Parameter (als Platzhalter in der Abfrage) aus VBA 9 heraus abgefragt und die Platzhalter dann durch die eingegebenen Werte ersetzt. Zuletzt waren die zusätzlichen Darstellungsparameter wie Anzeigetyp (Linie, Balken), Grenzwerte (Thresholds) oder Farben ebenfalls in der SQL-Formulierung der Abfrage enthalten. Diese Modikation der SQL-Klausel ist jedoch aus mehreren Gründen nicht vorteilhaft. Zum einen kann die Analyse fehlschlagen, und die Modikation resultiert in einer syntaktisch nicht mehr korrekten und damit unausführbaren Abfrage. Zum anderen wird der Anwender bei der Denition der Abfrage in seiner Kontrolle eingeschränkt. So ist es beispielsweise möglich, dass der Anwender die Einschränkungen anpassen (oder versuchsweise sogar ganz entfernen) möchte. In TInTo wurden daher VBA-Funktionen vorgesehen, die die Einschränkung nach Wertpapier und Zeitraum sowie die Verwendung von Parametern in den Abfragen ermöglichen. Die zusätzlichen Darstellungsparameter wurden in zusätzliche Felder ausgelagert und werden damit nicht mehr in der SQL-Formulierung der Abfrage deniert. Unterstützung von Aktionsabfragen Besonders bei der Umsetzung von rekursiv denierten Indikatoren (siehe auch Kapitel 5.4.4, MACD) wurde deutlich, dass sich diese Indikatoren nicht wie die anderen Indikatoren über (mehrstuge) Abfragesichten berechnen lassen. Dies gilt insbesonders für den von Access unterstützen SQL-92 Dialekt, der keinerlei Rekursionen zulässt. Zusätzlich wäre die Berechnung über rekursive Abfragen, wenn sie denn möglich wären, nicht ezient. Dies wurde bereits bei der Berechnung des MACD dargelegt. Daher wurde eine Lösung erarbeitet, die über eine Kette von Aktionsabfragen, gefolgt von der eigentlichen Sicht-Abfrage, den Indikator berechnet. TInTo musste also in der Lage sein, neben den klassichen Sichten (SELECT FROM) auch Aktionsabfragen (UPDATE) zu erkennen, anzulegen und auszuführen. Dazu wurde die Analyse der vom Anwender 9 Visual Basic for Applications: eine aus dem von Microsoft entwickelten Basic-Dialekt Visual Basic (VB) abgeleitete Skriptsprache, die zur Steuerung von Programmabläufen in den Microsoft Oce- Programmen entwickelt wurde. 89

94 5 Implementierung eingegebenen SQL-Formulierung der Abfrage erweitert, um die notwendigen Aktionsabfragen zu erkennen und auszuführen. Mehrschrittige Abfragen Für die Berechnung der rekursiv denierten Indikatoren war es ebenfalls notwendig, mehrere Aktionsabfragen sequentiell auszuführen. So wird der MACD-Indikator über drei Aktionsabfragen gefolgt von einer Sicht-Abfrage berechnet. Da die hierarchische Verkettung über versichiedene Sichten-Ebenen hier nicht gegeben ist, kann der Datenbankmechanismus der aufeinander aufbauenden Sichten (nur oberste Sicht ausführen, die darunterliegenden Sichten werden implizit mitausgeführt) hier nicht angewendet werden. TInTo muss also die Denition von mehrschrittigen (Aktions-)Abfragen zulassen, diese erkennen und nacheinander ausführen. In der Indikatordenition werden die einzelnen Teilabfragen über das Ÿ-Zeichen voneinander getrennt. Skalierbarkeit des TInTo-Formulares Das TInTo-Hauptformular wurde für eine Bildschirmauösung von 800x600 Bildpunkten bei normaler Schriftgröÿe entworfen. Bei höheren Auösungen oder bei kleineren Schriftgröÿen (und damit niedrigeren DPI-Werten 10 ) wurde das TInTo-Hauptformular, und damit natürlich auch der angezeigte Kurs- und Indikatorverlauf, sehr klein dargestellt. Es wurde also notwendig, das Hauptformular skalierbar, also in der Gröÿe anpassbar, zu gestalten. Dazu musste das ChartDirector-Steuerelement ereignisgesteuert (also beim Verändern der Gröÿe bzw. beim Minimieren oder Maximieren des Fensters) angepasst und erneut gezeichnet werden. Nicht zuletzt dank dieser Anpassungen und Optimierungen ist aus TInTo ein praktikables und anwendbares Werkzeug zur Berechnung aller gängigen Indikatoren entstanden. Dennoch sind zusätzliche Erweiterungen durchaus denkbar und wurden bereits an anderer Stelle angesprochen. Dies sind beispielsweise die Mehrbenutzerfähigkeit im Bezug auf die Berechnung der rekursiv denierten Indikatoren oder die Unterstützung von Intraday-Kursdaten. Zu diesen beiden Anpassungen wurden bereits Lösungsvorschläge vorgestellt. 10 Dots-Per-Inch (Punkte-Pro-Zoll). Durch heraufsetzen des Wertes werden alle Elemente auf dem, Bildschirm vergröÿert, heruntersetzten des Wertes verkleinert alle Werte. 90

95 6 Beispielszenario für TInTo In diesem Kapitel soll der Bedienungsablauf des TInTo-Programmes beispielhaft vorgestellt werden - also der gesamte Weg vom Symbol bis hin zum technischen Indikator. Nach dem Starten des Programms wird automatisch das Access-Hauptfenster ausgeblendet und der Anwender sieht das TInTo-Hauptformular. Abbildung 6.1: TInTo Hauptformular Das Hauptformular, dargestellt in Abbildung 6.1, präsentiert sich übersichtlich und aufgeräumt. Auf der rechten Seite bendet sich das ChartDirector-Control mit der Darstellung des aktuell gewählten Wertpapier-Kursverlaufes sowie der graschen Darstellung des momentan aktiven technischen Indikators. Auf der linken Seite benden sich im oberen Bereich zunächst die zur Auswahl eines Wertpapieres sowie die zur Einstellung der Wertpapier-Darstellung notwendigen Steuerelemente. Darunter benden sich die Steuerelemente zur Aktivierung der ChartDirector-eigenen Preisband- und Indikatordarstellungen. Darunter folgen die Steuerelemente zur Anlage, Auswahl, Modikation und Löschung der TInTo-eigenen technischen Indikatoren. Die unterschied- 91

96 6 Beispielszenario für TInTo lichen Steuerelemente des Hauptformulars mit deren Möglichkeiten der Bedienung werden im Folgenden vorgestellt: Wertpapier (Symbol) In diesem Kombinationslistenfeld wird entweder ein bereits vorhandenes Symbol ausgewählt, oder aber ein neues Symbol zur Betrachtung in TInTo eingegeben. Über die Pfeil-Schaltäche neben der Symbolauswahl wird diese aktiviert. Ansicht Die unterschiedlichen Darstellungsformen wie Candlestick, OHLC, Schlusskurs, Typischer Kurs, Gewichteter Kurs oder Mittlerer Kurs werden über dieses Kombinationslistenfeld ausgewählt. Die neue Darstellungsform wird direkt aktiv. Die Tabellen-Schaltäche stellt den Kursverlauf in tabellarischer Form dar. Volumenbalken Bei Aktivierung werden zusätzlich zum Kursverlauf die Umsätze als Volumenbalken am unteren Rand des Diagramms farblich dargestellt (grün bei mehr Käufen als Verkäufen, sonst rot). logarithmische Skala Bestimmt, ob für das Diagramm eine logarithmische statt einer linearen Skalierung angewendet werden soll. ChartDirector Preis-Band Über dieses Kombinationslistenfeld sind die im ChartDirector vorhandenen Preisbänder Bollinger Band, Donchain Channel oder Envelope auswählbar. ChartDirector Indikator In diesem Listenfeld ist die Auswahl von im ChartDirector vordenierten Indikatoren möglich. Der Indikator wird zusätzlich zum Diagramm angezeigt. Die Pfeil-Schaltäche aktiviert die Auswahl. Indikator In diesem Listenfeld ist die Auswahl der TInTo-eigenen Indikatoren möglich. Die ersten drei Schaltächen dienen dem Anlegen, Bearbeiten bzw. Löschen einer Indikator-Deniton. Die Pfeil-Schaltäche aktiviert den ausgewählten Indikator und zeigt diesen an. Access ein-/ausblenden Über diese Schaltäche kann das Access-Hauptfenster einbzw. ausgeblendet werden. Nach dem Start von TInTo wird das Access-Fenster zunächst ausgebelendet. Monat, Quartal, 1 Jahr, 3 Jahre, 5 Jahre Diese Radio-Schaltächen legen den Anzeigezeitraum fest. Der Anwender gibt jetzt über das Wertpapier-Steuerelement das gewünschte Wertpapiersymbol ein. Da es sich hierbei um ein Kombinationslistenfeld handelt, sind die bereits in TInTo vorhandenen Wertpapiere in der Liste aufgeführt, es kann aber auch ein neues Symbol eingegeben werden. Nach Eingabe eines neuen Wertpapier-Symbols, 92

97 welches in TInTo noch nicht bekannt ist, wird zunächst eine Internetverbindung aufgebaut und über Yahoo (Anbindung an nance.yahoo.com) dieses auf Eindeutigkeit überprüft. Abbildung 6.2: Wertpapierauswahl bei mehrdeutiger Symboleingabe Sollte das Symbol nicht eindeutig sein, bietet TInTo ein Formular zur Auswahl des tatsächlich vom Anwender gewünschten Symbols. In diesem Beispiel wurde nach dem Symbol SYBASE gesucht. Dabei wurden mehrere Treer gefunden (siehe Abbildung 6.2), die dann zur Auswahl angeboten wurden. Vom Anwender gewünscht sei hier das Wertpapier am Handelsplatz NYSE (also der New York Stock Exchange, der gröÿten Wertpapierbörse der Welt, an der Wall Street in New York, USA). Das sich hieraus ergebende Symbol für die Aktie der Sybase Inc. am Handelsplatz New York ist das Kürzel SY. Nach Bestätigung der Auswahl, aber auch bei Auswahl eines bereits bestehenden Wertpapiers, werden die Kursdaten in TInTo aktualisiert. Dies geschieht wiederum über eine Internetverbindung zu Yahoo. TInTo fordert zum gewählten Wertpapier die Kursdaten beginnend ab den letzten vorhandenen Daten bis zum aktuellen Tag an und legt diese in der Datenbank ab. In unserem Beispiel wird danach der Kursverlauf der Sybase Inc. in TInTo unter Berücksichtigung der momentan aktiven Einstellungen wie in Abbildung 6.3 dargestellt. In diesem Beispiel wurde der Zeitraum 1 Jahr inklusive Volumenbalken und Bollinger Preisband ausgewählt. Selbstverständlich ist die Auswahl eines anderen Zeitraums oder eines bereits vorhandenen Indikators jederzeit möglich. Optional können die Kurs- und Umsatzdaten eines Wertpapiers auch in tabellarischer Form gemäÿ Abbildung 6.4 angezeigt werden Dazu betätigt der Anwender die Tabellen-Schaltäche neben dem Ansicht-Kombinationslistenfeld. In der tabellarischen Ansicht wird dabei neben dem Datum und den Erönungs-, Tageshöchst- und Tiefkurs, Schlusskurs und Umsatzdaten auch der Kursverlauf über 93

98 6 Beispielszenario für TInTo Abbildung 6.3: Kursverlauf der Sybase Inc. ohne Indikator eine Farbkodierung des Schlusskurses angezeigt. Eine rote Einfärbung zeigt fallende Kurse, eine grüne Einfärbung steigende Kurse. Abbildung 6.4: Tabellarische Darstellung der Kurs- und Umsatzdaten Nehmen wir jedoch jetzt an, der Anwender möchte einen neuen, noch nicht in TIn- To vorhandenen, Indikator RSI Relative Strength Index denieren. Dazu wird die Schaltäche zum Anlegen eines neuen Indikators gewählt und das Programm önet das Indikator-Detailformular. In diesem Formular, dargestellt in Abbildung 6.5, wird dem neuen Indikator zunächst ein interner Name gegeben, in unserem Beispiel also der Name des Indikators RSI. Dieser Name wird für die Anlage des Indikators unter Microsoft Access verwen- 94

99 Abbildung 6.5: Anlegen eines neuen Indikators det - bei Verwendung des Indikators wird also eine Abfrage mit dem Namen RSI erzeugt. Im Listenfeld des TInTo-Hauptfensters dagegen erscheint allerdings nicht der (meist kurze) interne Name des Indikators, sondern dessen Titel (Caption), hier also RSI Relative Strength Index. Diese Trennung in interne und angezeigte Namen erlaubt kurze Abfragenamen, die ja unter Umständen auch von anderen Abfragen referenziert werden, und lange, aussagekräftigere Bezeichnungen für die Auswahl durch den Anwender. Die Reihenfolge, in welcher die Indikatoren im Listenfeld erscheinen, lässt sich (zumindest grob) durch Auswahl der Anzeigepriorität (niedrig, mittel, hoch) festlegen. Häug verwendete Indikatoren können so durch Auswahl einer hohen Priorität an den Anfang der Liste gesetzt werden, sekundär wird dann nach dem Namen sortiert. In dem relativ groÿen Eingabefeld wird nun die entsprechende Abfrage für den Indikator RSI in der Datenbanksprache SQL formuliert. Dabei kann sowohl auf die Basisdaten (Kurse und Umsätze) der Tabelle TKurs, aber auch die Werte beliebiger anderer Abfragen (und damit Sichten) zugegrien werden. Vor Ausführung der Abfrage wird diese durch TInTo zunächst analysiert und sichergestellt, dass alle zugrundeliegenden Sichten in Access zur Verfügung stehen, da es ansonsten bei dem Aufruf der Abfrage zu einem Fehler durch Access käme. Neben der Möglichkeit der hierarchischen Anordung der Abfragen ist die Zerlegung der Eingabe in diesem Feld in mehrere, hintereinander ausführbare Abfragen, wiederum formuliert in SQL, möglich. Dabei werden die Teilabfragen mit Hilfe des Ÿ-Zeichens voneinander getrennt. Dieses Verfahren ndet z.b. Anwendung bei der Berechnung des MACD-Indikators (vgl. Kapitel 5.4.4). Hier werden vor der Selektion der Indikatordaten durch die Sicht einige Aktionsabfragen ausgeführt, welche den Indikator gemäss seiner rekursiven Denition berechnen. In unserem Beispiel des RSI ist die Formulierung der Abfrage dagegen relativ ein- 95

100 6 Beispielszenario für TInTo fach. Die Abfrage muss die Kurs-, Umsatz- und berechneten Indikatordaten für ein bestimmtes Wertpapier in einem bestimmten Zeitraum zurückliefern. Da bei der Berechnung des RSI ein einfacher gleitender Durchschnitt gebildet werden muss, ist eine Verknüpfung der TKurs-Tabelle auf sich selbst notwendig. Die Einschränkung auf das entspechende Wertpapier sowie den Zeitbereich erfolgt über die bereits in Kapitel 5.4 vorgestellten Funktionen spgetid() sowie spgetn(). Der für diesen Indikator notwendige Parameter für die Periodenvorgabe wird mittels der Funktion spgetpar() angefordert. Der Standardwert wird hier mit 14 Perioden vorgegeben. Da die Darstellung des Indikators immer den gewählten Darstellungszeitraum bis hin zum aktuellen Handelstag berücksichtigt, der erste zu betrachtende Handelstag allerdings durch die Eingabe des Parameters für die Periode nicht auf ein bestimmtes Datum festgelegt ist (zur Erinnerung: die Periode berücksichtigt n Handelstage, dies ist aufgrund von Wochenenden oder Feiertagen kein festes Zeitintervall), werden die Werte in absteigender Sortierung angeliefert. So kann TInTo das Einlesen der Kurs-, Umsatz- und Indikatordaten an der richtigen Stelle abbrechen. Im rechten Bereich des Indikator-Detailformulares bendet sich direkt unter der (optional einzugebenden) Bemerkung ein Bereich zur Eingabe von indikator-spezischen Darstellungsparametern. Der RSI-Indikator besteht aus einer dargestellten Kurve (Liniengrak) und soll bei der Darstellung durch den ChartDirector den Namen RSI erhalten. Die Farbe der dargestellten Linie kann zusätzlich als RGB-Wert in hexadezimaler Darstellung eingegeben werden. Wird keine Farbe eingegeben, erscheint die Indikatorlinie schwarz (dies entspricht dem RGB-Wert h000000). 1. Der Wert h ergibt demnach eine Linie in der Farbe lila. Da der RSI ein Oszillator ist, sollen ausserdem Grenzbereiche hervorgehoben werden. Dies geschieht durch die Eingabe der Darstellungsparameter T:70,h8080,30,h8080FF. Dabei steht das T für den Threshold- Parameterblock, gefolgt von zwei Grenzbereich/Farbwert-Paaren. Die Grenzbereiche von 70 und 30 werden durch eine horizontale Linie optisch angezeigt. Steigt der Indikatorwert über 70, wird die Schnittäche zur optischen Hervorhebung in rot eingefärbt (RGB(,80,80)), sinkt der Wert unter 30, wird die Fläche in blau eingefärbt (RGB(80,80,)). Neben dieser beim RSI gewählten Threshold-Darstellungsform des RSI ist für Indikatoren auch die (optionale) Darstellung als Balkengrak möglich. Wird kein zusätzlicher Darstellungsparameter eingegeben, wird der Indikator standardmäÿig als Kurve (Liniengrak) dargestellt. Eine kurze Hilfe zu den in der Abfrage auszugebenden Feldern, den von TInTo zur Einschränkung zur Verfügung gestellten Funktionen sowie der möglichen Darstellungsparametern ndet der Anwender im rechten Teil des Formulares aus Abbildung 6.5. Über die Tabellen-Schaltäche des Indikator-Detailformlares lässt sich weiterhin al- 1 Der RGB-Wert bezeichnet die Farbmischung von Rot, Grün und Blau. Bei diesem additiven Farbmodell kann jeder Farbanteil zwischen 0 und 255 variieren (oder in h in hexadezimaler Darstellung), h (RGB(00,00,00)) entspricht dabei Schwarz, h (RGB(,,)) entspricht Weiÿ. 96

101 Abbildung 6.6: Tabellarische Darstellung der Indikatorwerte ternativ eine tabellarische Anzeige der aktuell denierten Sicht aufrufen (siehe Abbildung 6.6). So können berechnete Indikatorwerte auf einfache Weise kontrolliert werden. Ist der Indikator vollständig deniert, kann er, wie auch alle anderen schon denierten Indikatoren, im TInTo-Hauptformular ausgewählt werden. Er wird dann gemeinsam mit dem Kursverlauf des Wertpapiers gemäÿ seiner Parameter dargestellt. Abbildung 6.7: Kursverlauf der Sybase Inc. mit RSI-Indikator Die in TInTo zur Visualisierung verwendete ChartDirector-Komponente ist ebenfalls in der Lage, eine gewisse Anzahl von technischen Indikatoren zu berechnen und anzuzeigen. Interessant ist der Vergleich von Indikatorkurven bei gleichen Indikatoren. In Abbildung 6.8 wird zweimal der Aroon-Oszillator dargestellt. Dies wählt der Anwender durch Auswahl des Indikators sowohl in dem Listenfeld des ChartDirector-Indikators 97