PDF file - IDB - Universität Bonn

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
Inhaltsverzeichnis
1 Einleitung
1
2 Datenbanksysteme
5
2.1
2.2
Relationale Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Grundlagen relationaler Datenbanken . . . . . . . . . . . . . . .
5
2.1.2
Normalformen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.3
Regelkonzepte in Datenbanken . . . . . . . . . . . . . . . . . . .
8
SQL - Structured Query Language
. . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Einführung und Überblick
2.2.2
DDL - Data Denition Language
2.2.3
DML - Data Manipulation Language
. . . . . . . . . . . . . . .
13
2.2.4
DCL - Data Control Language . . . . . . . . . . . . . . . . . . .
15
. . . . . . . . . . . . . . . . .
3 Wertpapiere und Indikatoren
12
17
3.1
Wertpapiere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
Börse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3
Aktien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4
Grundlagen der Wertpapieranalyse
. . . . . . . . . . . . . . . . . . . .
21
3.4.1
Fundamentale Analyse
. . . . . . . . . . . . . . . . . . . . . . .
21
3.4.2
Technische Analyse . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Chartanalyse
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.6
Technische Indikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.6.1
Trendfolgeindikatoren . . . . . . . . . . . . . . . . . . . . . . . .
25
3.6.2
Momentum-Oszillatoren
. . . . . . . . . . . . . . . . . . . . . .
28
3.6.3
Trendbestimmungsindikatoren . . . . . . . . . . . . . . . . . . .
30
3.6.4
Volatilitätsindikatoren
. . . . . . . . . . . . . . . . . . . . . . .
33
Handelssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.7
4 Entwurf von TInTo
4.1
Idee und Zielsetzung
39
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.1.1
TInTo als Bestandteil eines Handelssystems
. . . . . . . . . . .
40
4.1.2
Problemklasse der Data Streams . . . . . . . . . . . . . . . . . .
41
4.2
Anforderungsprol und Use-Cases . . . . . . . . . . . . . . . . . . . . .
43
4.3
Entwurf des Datenbankschemas
46
. . . . . . . . . . . . . . . . . . . . . .
i
Inhaltsverzeichnis
4.4
Architektur von TInTo . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.5
TInTo-Benutzerschnittstelle
57
. . . . . . . . . . . . . . . . . . . . . . . .
5 Implementierung
5.1
Verwendete Software
59
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.1.1
Microsoft Access
. . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.1.2
ChartDirector . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.2
Umsetzung des Schemaentwurfs in Microsoft Access . . . . . . . . . . .
61
5.3
Programmstruktur und Visual Basic Module . . . . . . . . . . . . . . .
63
Umsetzung der Indikatorklassen in TInTo
5.4
. . . . . . . . . . . . . . . .
67
5.4.1
Aggregatfreie Indikatoren
. . . . . . . . . . . . . . . . . . . . .
69
5.4.2
Indikatoren mit einfachen Aggregaten . . . . . . . . . . . . . . .
71
5.4.3
Indikatoren mit mehrstugen Aggregaten . . . . . . . . . . . . .
74
5.4.4
Rekursive Indikatoren
78
. . . . . . . . . . . . . . . . . . . . . . .
5.5
Leistungsbewertung und Ezienz
. . . . . . . . . . . . . . . . . . . . .
84
5.6
Optimierungen und Anpassungen
. . . . . . . . . . . . . . . . . . . . .
88
6 Beispielszenario für TInTo
91
7 Zusammenfassung
99
A Module und Funktionen
103
B Literaturverzeichnis
111
ii
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
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
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
1
Structured Query Language (SQL) in Form von Abfragen (oder Sichten ) 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
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
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.
2.1.1 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
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
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.
2.1.2 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
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 NichtSchlü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.
2.1.3 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 norma-
tive 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 ma-
terialisiert deklariert werden können. Mit dem Aufrufen der Sicht werden bei
virtuellen Sichten die resultierenden (oder abgeleiteten) Daten nicht dauerhaft
8
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 stati-
schen (z.B. Gehalt < 250.000) 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
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.
2.2.1 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
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. 1986 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 SQLStandard verabschiedet (SQL-86), der daraufhin auch von der International Organi-
sation 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überwa-
chungssprache einer Datenbank. Befehle sind z.B. GRANT oder REVOKE.
11
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]).
2.2.2 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änen konzept 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 er-
zeugt 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
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
über eine
CHECK-Klausel
NULL)
sowie
allgemeine Wertebereichsbeschränkungen festzulegen.
Eine bestehende Basistabelle kann mittels der
ALTER TABLE-Anweisung
auf ver-
schiedene 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);
DROP COLUMN Spalten zu löschen. Ausserdem können mit ADD CONSTRAINT Indizes hinzugefügt oder diese durch DROP CONSTRAINT
Alternativ ist es möglich, durch
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.
2.2.3 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.
SELECT-Anweisung zur VerSELECT-Anweisung auch als SFW-Block
Zur Selektion bzw. Abfrage von Daten stellt SQL die
fügung. Aufgrund seiner Syntax kann eine
gesehen werden. Dabei steht SFW für die Komponenten SELECT (welche Spalten
13
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. Sich-
ten (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 hal-
ber 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 Ergeb-
nisse 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, ’870747’);
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
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.
2.2.4 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 Ob-
jektes 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
2 Datenbanksysteme
16
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, elek-
1
tronisch gestützter Skontroführer -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
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 575200 für die Bayer AG ergibt sich so also die ISIN DE0005752000 (Präx
DE, NSIN 000575200 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
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
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
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.
3.4.1 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 ge-
teilt 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
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.
3.4.2 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
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
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-SchulterFormation), fallendes Dreieck, inverse V-Formationen, Double/Triple-Top oder
Rounding Top. Zur Erkennung eines Abwärtstrends werden unter anderem VFormation,Double/Triple-Bottom, steigendes Dreieck, inverse SKS, RoundingBottom 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
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 TInTo.
3.6.1 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
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:
Pn−1
SM A(t) =
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
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
2
Durchschnitt als bullisches Signal .
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 be-
wertet nicht alle Daten innerhalb einer Berechnung gleich, sondern gewichtet
die jüngeren Daten stärker als die älteren:
Pn−1
W M A(t) =
wobei beispielsweise
i=0
(W (t − n) ∗ Close(t − n))
Pn−1
i=0 W (t − n)
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
P7
i=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
3 Wertpapiere und Indikatoren
beiden einfachen Varianten mit jedem neuen Kurs, der in die Berechnung einieÿ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:
EM A(t) = (Close(t) − EM A(t − 1)) ∗ Ew(t) + EM A(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.
3.6.2 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
3
anzuzeigen. Sie können aber auch Divergenzen 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
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 Indikato-
ren, 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:
M omentum(t) = Close(t) − Close(t − n)
Eine alternative Berechnung wäre auch:
29
3 Wertpapiere und Indikatoren
M omentum(t) =
Close(t)
∗ 100
Close(t − n)
Meistens werden 10 Handelstage als Vorgabe für n verwendet. Möglich ist aber
auch eine längere Einstellung von 30-40 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. Ben-
det 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.
3.6.3 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
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
3 Wertpapiere und Indikatoren
(
+DM (t) =
High(t) − High(t − 1)
0
(
−DM (t) =
Low(t − 1) − Low(t)
0
für
High(t) > High(t − 1)
sonst
für
Low(t) < Low(t − 1)
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) = M ax(High(t), Close(t − 1))
T rueLow(t) = M in(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:
Pn−1
Pn−1
+DM (t−n)
Pn−1 n
T R(t−n)
i=0
n
+DI(t) =
−DM (t−n)
Pn−1 n
T R(t−n)
i=0
n
i=0
i=0
∗ 100
− DI(t) =
∗ 100
4. Aus +DI und -DI ergibt sich der Directional Movement Index DMI, welcher
aufgrund seiner Volatiltät nur selten dargestellt wird:
DM I(t) =
(+DI(t)) − (−DI(t))
∗ 100
(+DI(t)) + (−DI(t))
5. Durch Glättung des DMI ergibt sich schliesslich der ADX:
Pn−1
ADX(t) =
32
i=0
DM I(t − n)
n
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
4
der Bewertung von Kursausbrüchen und Breakouts
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.
3.6.4 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
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 zu-
nächst die True-Range berechnet werden:
T rueHigh(t) = M ax(High(t), Close(t − 1))
T rueLow(t) = M in(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:
Pn−1
AT R(t) =
i=0
T rueRange(t − n)
n
Meist wird für die ATR eine Berechnungsdauer zwischen 5 und 30 Handelstagen
verwendet.
34
3.7 Handelssysteme
Interpretation:
Die ATR zeigt die wahre Handelsspanne eines Basiswertes oder ei-
nes 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 be-
reits 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 Preisbewe-
gung und nutzt eine kurz darauf folgende gegenläuge Korrekturbewegung.
Channel-Breakout
Wenn die Preise einen vorher festgelegten Bereich, den Chan-
nel, 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
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 Mo-
ney 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
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
3 Wertpapiere und Indikatoren
38
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
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 SQLFunktionsumfangs 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.
4.1.1 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
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 PushBetrieb) 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.
4.1.2 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
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
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 (Candle-
1
2
stick , OHLC , 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
4 Entwurf von TInTo
Zum Einlesen der Wertpapier-Auswahl (bei einem vom Anwender eingegebenen
mehrdeutigen Symbol), der dann zum gewählten Wertpapier gehörenden WertpapierStammdaten 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 YahooFinance 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. UseCase-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 WertpapierSymbols auszuwählen. Dabei soll TInTo das Symbol mit Hilfe der Yahoo-Daten aus
44
4.2 Anforderungsprol und Use-Cases
TInTo
Neues
Wertpapier
auswählen
<<include>>
Wertpapier
Kursdaten
anzeigen
Neuen
Indikator
anlegen
<<include>>
<<include>>
Anwender
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 includeBeziehung 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
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
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
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.
ID
n
Date
Open
High
Kurse
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
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
Handels tag, 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 MACDIndikators erläutert wird.
Priority
Name
Caption
SQL
IName1
IName2
Sicht
IName3
ICol1
ICol2
ICol3
IPar1
IPar2
IPar3
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
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
1
besitzt
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
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 2.1.2 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
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
3
das Feld nicht im Index ist und ausserdem vom Typ VARCHAR
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
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
850.000 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
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 6.832.128 Kurs- und Umsatztupeln angelegt (also beinahe sieben Millionen Datentupel). Dies entspricht den Daten für über 4.000 Wertpapiere über den Zeitraum
von beinahe 6 Jahren, also etwa ab dem Jahr 2000. 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
4.4 Architektur von TInTo
Benutzerschnittstelle
ChartDirector
Visualisierung
Anzeigedaten
TInTo Hauptkomponente
Neuen
Kurs/Indikator
anzeigen
Neues Wertpapier
WP/Indikator
Stammdaten
Kursdaten anfordern
Chart Manager
DB-Interface (Jet)
Internet-Schnittstelle
Kurs-/
Wertpapier
daten
Kursdaten
Filter
Nachrichten
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.
4
Grundsätzlich handelt es sich hier um einen Top-Down -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 AktualisierungsIntervalls 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
5
(Event ) 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
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 5.1.1 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 InternetSchnittstelle 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
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
8
Der ChartDirector ist eine bestehende COM-Komponente , 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 5.1.2 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
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 Denition der Indikatorsichten, in einem separaten Formular erfolgen.
Die in Kapitel 4.2 vorgenommene Trennung der Akteure in Anwender und Ad-
ministratoren 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
5 Implementierung
5.1 Verwendete Software
Die Auswahl eines geeigneten Programmierwerkzeugs für die Realisierung des TInToProjektes 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
5 Implementierung
5.1.1 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 2003.
5.1.2 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
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 VisualBasic 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
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 5.4.4 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
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
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 TInToDatenbank 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 Internetfunk-
tionalitä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
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 SQLFormulierungen 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 ChartDirector 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
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
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 SQLFormulierung 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
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
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
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
OA
Tabelle 5.1: In TInTo aktuell implementierte Indikatoren
der gleichen Komplexitätsklasse lassen sich dann auf identische oder ähnliche Weise
abbilden.
5.4.1 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 tech-
nischen 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
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 sei-
ner 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
2
3
4
5
70
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
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 si-
gnalisiert 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.
5.4.2 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 1.1.2000 angeladen und gespeichert werden, das maximale Anzeigeintervall
jedoch höchstens 5 Jahre ab dem aktuellen Datum beträgt.
71
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 SQLAbfrage zusammenfassen. Zunächst werden zwei Summen gebildet. Die eine enthält
72
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.
(
U p(t) =
Close(t) − Close(t − 1)
0
(
Down(t) =
Close(t − 1) − Close(t)
0
für
Close(t) > Close(t − 1)
sonst
Close(t) < Close(t − 1)
für
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
X
U p(t − i) SD(t) =
i=0
AvgSU =
n−1
X
Down(t − i)
i=0
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 Berech-
nung 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
2
3
4
5
SELECT TKurs.ID,TKurs.n,TKurs.Date,
TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol,
100*(AVG(IIF(TK1.Close>TK2.Close,TK1.Close-TK2.Close,0))/
(AVG(IIF(TK1.Close>TK2.Close,TK1.Close-TK2.Close,0))+
AVG(IIF(TK1.Close<TK2.Close,TK2.Close-TK1.Close,0))))
73
5 Implementierung
6
7
8
9
10
11
12
13
14
15
16
AS Ind1
FROM (TKurs INNER JOIN TKurs AS TK1 ON (TKurs.ID=TK1.ID))
INNER JOIN Tkurs AS TK2 ON (TK1.ID=TK2.ID AND
TK1.n-1=TK2.n)
WHERE Tkurs.ID=spGetID() AND
Tkurs.n>spGetN() AND
TK1.n<=TKurs.n AND
TK1.n>=TKurs.n-spGetPar("Periodenvorgabe=14")
GROUP BY TKurs.ID,TKurs.n,TKurs.Date,
TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol
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.
5.4.3 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
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 SoftwarePaket, 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 bendet. 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 Handel-
speriode 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
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)
∗ 100
H(n) − L(n)
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
X
K(t − i), m = Berechnungsperiode
i=0
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.
S(t) =
o−1
X
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 StochastikIndikatoren 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
5.4 Umsetzung der Indikatorklassen in TInTo
1
2
3
4
5
6
7
8
9
10
11
SELECT TKurs.ID,TKurs.n,TKurs.Date,
TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol,
((Tkurs.Close-Min(TK1.Low))/
(Max(TK1.High)-Min(TK1.Low)))*100 AS Ind1
FROM TKurs INNER JOIN TKurs AS TK1 ON (TKurs.ID=TK1.ID)
WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN() AND
TK1.n<=TKurs.n AND
TK1.n>=TKurs.n-spGetPar("Periode K-Linie=10")
GROUP BY TKurs.ID,TKurs.n,TKurs.Date,
TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol
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
2
3
4
5
6
7
8
9
10
11
SELECT FSTOC0.ID,FSTOC0.n,FSTOC0.Date,
FSTOC0.High,FSTOC0.Low,FSTOC0.Open,FSTOC0.Close,FSTOC0.Vol,
FSTOC0.Ind1,AVG(FSTOC1.Ind1) AS Ind2
FROM FSTOC0 INNER JOIN FSTOC0 AS FSTOC1 ON
(FSTOC0.ID=FSTOC1.ID)
WHERE FSTOC1.n<=FSTOC0.n AND
FSTOC1.n>=FSTOC0.n-spGetPar("Periode D-Linie=3")
GROUP BY FSTOC0.ID,FSTOC0.n,FSTOC0.Date,
FSTOC0.High,FSTOC0.Low,FSTOC0.Open,FSTOC0.Close,FSTOC0.Vol,
FSTOC0.Ind1
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
2
3
4
5
6
7
8
SELECT FSTOC.ID,FSTOC.n,FSTOC.Date,
FSTOC.High,FSTOC.Low,FSTOC.Open,FSTOC.Close,FSTOC.Vol,
FSTOC.Ind2 AS Ind1,
AVG(FSTOC1.Ind2) AS Ind2
FROM FSTOC INNER JOIN FSTOC AS FSTOC1 ON (FSTOC.ID=FSTOC1.ID)
WHERE FSTOC1.n<=FSTOC.n AND
FSTOC1.n>=FSTOC.n-spGetPar("Periode Slow-D-Linie=3")
GROUP BY FSTOC.ID,FSTOC.n,FSTOC.Date,FSTOC.High,FSTOC.Low,
77
5 Implementierung
9
10
FSTOC.Open,FSTOC.Close,FSTOC.Vol,FSTOC.Ind2
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 schwingen-
de 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.
5.4.4 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 SQL92 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 denierten 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
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
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 glei-
tende Durchschnitte EMA nach der folgenden Formel berechnet:
EM A(t) = (Close(t) − EM A(t − 1)) ∗ Ew(t) + EM A(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.
M ACD(t) = EM A1(t) − EM A2(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
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
EMA1
v1 v2 v3
v1 v2 v3
v1 v2 v3
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
5 Implementierung
n-3
n-2
n-1
v1 v2 v3
v1 v2 v3
v1 v2 v3
v1 v2 v3
v1 v2 v3
~MACD
~MACD
v1 v2 v3
v1 v2 v3
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
2
3
UPDATE Tkurs
SET v1=Close, v2=Close
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
2
3
4
5
6
7
8
UPDATE Tkurs INNER JOIN Tkurs AS TK0 ON
(Tkurs.ID=TK0.ID AND (Tkurs.n-1)=TK0.n)
SET Tkurs.v1=((Tkurs.v1-TK0.v1)*2/(26+1))+TK0.v1,
Tkurs.v2=((Tkurs.v2-TK0.v2)*2/(12+1))+TK0.v2,
Tkurs.v3=((((Tkurs.v2-TK0.v2)*2/(12+1))+TK0.v2)(((Tkurs.v1-TK0.v1)*2/(26+1))+TK0.v1))
WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()-1
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
2
3
82
UPDATE Tkurs INNER JOIN Tkurs AS TK0 ON
(Tkurs.ID=TK0.ID AND (Tkurs.n-1)=TK0.n)
SET Tkurs.v3=((Tkurs.v3-TK0.v3)*2/(9+1))+TK0.v3
5.4 Umsetzung der Indikatorklassen in TInTo
4
5
WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()
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
2
3
4
5
6
SELECT TKurs.ID,TKurs.n,TKurs.Date,
TKurs.High,TKurs.Low,TKurs.Open,TKurs.Close,TKurs.Vol,
(v2-v1)-v3 AS Ind1,(v2-v1) AS Ind3,v3 AS Ind2
FROM TKurs
WHERE Tkurs.ID=spGetID() AND Tkurs.n>spGetN()
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
7
einfaches Moving-Average-Crossover-System . 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 3.7
83
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
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)
15
16
31
62
78
ADO
RSI
156
406
1328
4245
7640
SSTOC
546
1609
5622
23609
49407
16
16
31
47
48
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 mehrstuger 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
5 Implementierung
Berechnungsdauer Indikatoren
50000
45000
40000
35000
ADO
RSI
SSTOC
MACD
mSec
30000
25000
20000
15000
10000
5000
0
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
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
neu
=
alt
v0
0
- vn+v
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
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
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 not-
9
wendigen Parameter (als Platzhalter in der Abfrage) aus VBA
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 OceProgrammen entwickelt wurde.
89
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
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
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, Schluss-
kurs, 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 ChartDi-
rector 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ög-
lich. 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 ein-
bzw. 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 An-
zeigezeitraum 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
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
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 TInTo 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
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
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
1
Indikatorlinie schwarz (dies entspricht dem RGB-Wert h000000). . Der Wert h800080
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 ThresholdParameterblock, 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), h000000 (RGB(00,00,00)) entspricht dabei Schwarz, h (RGB(,, )) entspricht Weiÿ.
96
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
6 Beispielszenario für TInTo
als auch im Listenfeld des TInTo-Indikators. Die obere Indikatorkurve wurde durch die
ChartDirector-Komponente berechnet, die untere Kurve durch eine Abfrage in TInTo.
Abbildung 6.8: Kursverlauf der Sybase Inc. mit Aroon-Oszillator; oberer Indikator durch ChartDirector berechnet, unterer Indikator durch TInToAbfrage berechnet
Es fällt direkt auf, dass die beiden Verläufe ähnlich und bezogen auf die tendenzielle Richtung des Indikators angeglichen sind, jedoch sind sie nicht identisch. Dies liegt
an den Berechnungsvorschriften der Indikatoren, welche oft nicht eindeutig sind. Hier
zeigt sich direkt eine Stärke des TInTo-Ansatzes. Während der ChartDirector eine
feste Implementierung des Indikators verwendet, sind in TInTo jederzeit Anpassungen möglich. Auch ist die TInTo-Berechnung aufgrund der Parametrierung wesentlich
exibler. Die Berechnung im ChartDirector erfolgte hingegen mit einem festen Parameter.
98
7 Zusammenfassung
Ziel dieser Arbeit war der Entwurf und die Implementierung eines datenbankgestützten
Werkzeuges zur regelbasierten Analyse von Wertpapierkursen. Mit Hilfe des Programmes TInTo, dessen generischer Ansatz die Auswertung der verschiedensten technischen
Indikatoren ermöglichte, wurde gezeigt, dass die Berechnung dieser Indikatoren direkt
auf der Datenbank in Form von hierarchisch verschachtelten Sichten ezient möglich
ist. Dabei bietet TInTo die notwendige Flexibilität, um Indikatoren unterschiedlichster
Problemklassen zu berechnen. Diese Flexibilität zeigt sich beispielsweise sowohl in der
Unterstützung von Auswahl- und Aktionsabfragen als auch in der variablen Parametrierung von Abfragen und Visualisierung. Die notwendigen Kurs- und Umsatzdaten
werden dabei, für den Anwender vollkommen transparent, im Hintergrund über eine Internet-Schnittstelle per HTTP vom Finanzdienstleister Yahoo heruntergeladen,
geltert und in der Datenbank abgelegt.
Der enorme Vorteil dieses Ansatzes, und damit von TInTo im Speziellen, besteht
dabei einerseits in seiner Ezienz, andererseis in seiner groÿen Flexibilität. Durch die
Berechnung der technischen Indikatoren direkt per SQL-Sichten werden keine überüssigen Daten übertragen oder gepuert. Vielmehr werden die Kurs- und Umsatzdaten
gemeinsam mit den berechneten Indikatorwerten direkt zur Visualisierung übergeben.
Dieser Vorteil macht sich insbesondere in einer Client-Server-Umgebung bemerkbar, in
der keine überüssigen Daten zusätzlich über ein Netzwerk übertragen werden müssen. Andererseits ist die Formulierung der Berechnungsvorschriften der Indikatoren
als Abfrage äuÿerst exibel. Es bestehen keine Einschränkungen durch starre Analysewerkzeuge oder Skriptsprachen. Der volle Umfang der Datenbanksprache SQL steht
für die Berechnung zur Verfügung.
In dieser Arbeit wurden kapitelweise die folgenden Themen behandelt. Die theoretischen Grundlagen der Datenbanktechnologie wurden in Kapitel 2 eingeführt. TInTo
verwendet eine relationale Datenbank, welche auf dem hier eingeführten relationalen
Datenmodell basiert. Zur Berechnung der Indikatoren werden deduktive Regeln verwendet, die gemeinsam mit den aktiven und normativen Regeln im Rahmen der Regelkonzepte für Datenbanken vorgestellt wurden. Die zur Denition der Indikatorsichten
zur Anwendung kommende Datenbanksprache SQL wurde ebenfalls in Grundzügen
vorgestellt. Hier wurde bereits deutlich, dass viele SQL-Dialekte die zur Berechnung
einiger Indikatoren notwendigen Funktionalitäten, beispielsweise Rekursion, nicht bieten. In TInTo wurden daher entsprechende Workarounds implementiert.
99
7 Zusammenfassung
Im Kapitel 3 wurden die Grundlagen über Wertpapiere, den Handel an Börsen und
die fundamentale und technische Analyse vorgestellt. Der Schwerpunkt lag dabei auf
der technischen Analyse, speziell auf den in TInTo berechneten technischen Indikatoren. Die übliche Klassizierung in Trendfolgeindikatoren, Oszillatoren, Trendbestimmungsindikatoren und Volatilitätsindikatoren wurde jeweils anhand eines Indikators
beispielhaft erläutert. Das Kapitel endet mit einer Einführung in Handelssysteme,
welche auch den inhaltlichen Kontext für TInTo darstellen.
In Kapitel 4 wurden grundlegende Ideen des TInTo-Werkzeuges und seine Zielsetzung dargelegt. Zur regelbasierten Analyse von Wertpapieren sollte das System
auf realen Kursdaten möglichst exibel und ezient technische Indikatoren berechnen. Die Kursdaten sind dabei über eine geeignete Schnittstelle aus dem Internet
anzuladen und zu speichern. Die Berechnung der Indikatoren sollte dann über Abfragen direkt auf der Datenbank stattnden und anschliessend in geeigneter Weise dem
Anwender präsentiert werden. Das Kapitel enthält auÿerdem sowohl eine inhaltliche
Einordung in den Bereich der Handelssysteme, als auch eine akstrakte Einordnung in
die Problemklasse der Data Streams. Das Kapitel thematisiert ebenfalls die Entwurfsphase von TInTo. Im Anforderungsprol wurden notwendige Eigenschaften festgelegt.
In Use-Cases wurde die Interaktion mit dem Anwender speziziert. Das sich hieraus
ergebende Datenbankschema wurde über ER-Modellierung, logischem Entwurf und
Datendenition erarbeitet. Dabei wurden besonders Ezienzfragen berücksichtigt, da
die betrachteten Datenmengen von erheblichem Umfang sind. Ergebnis ist eine einfache Datenstruktur, auf der die notwendigen Berechnungen ezient ausführbar sind.
Neben der Datenstruktur wurde in diesem Kapitel auch die zu implementierende Softwarestruktur von TInTo, einschlieÿlich der Anforderungen an die Bedieneroberäche,
behandelt.
Die Implementierungsphase von TInTo wurde in Kapitel 5 beschrieben. Nach der
Auswahl der passenden Implementierungswerkzeuge Access und ChartDirector wurden
die Umsetzung des Datenbankschemas und die Erstellung des Systems erläutert. Da
die Indikatoren über SQL-Abfragen berechnet werden, ist deren Formulierung ebenfalls
als Teil der Implementierung anzusehen. Die im Finanzumfeld übliche Klassierung
ist im Bezug auf die Berechnungskomplexität jedoch ungeeignet. Daher wurden die
Indikatoren neu, abhängig von der Verwendung von Aggregaten und Rekursion in
ihrer Berechnungsvorschrift, klassiziert. Für diese neuen Komplexitätsklassen wurde
jeweils ein Indikator beispielhaft einschlieÿlich seiner Umsetzung in TInTo vorgestellt.
Anschlieÿend wurde eine Leistungsbewertung des Systems vorgenommen. Bis auf
die Indikatoren mit mehrstugen Aggregaten sind alle Berechnungen äuÿerst ezient
durchzuführen. Ein möglicher Lösungsansatz für diese problematischen Indikatoren,
deren Berechnungszeiten speziell mit verschachtelten Durchschnittsbildungen bei einer groÿen Anzahl von Kurs- und Umsatzdaten ansteigt, ergibt sich durch geschickte Materialisierung und Neuberechnung der Indikatorwerte. Abschiessend wurde eine
Vielzahl von bereits in der Implementierungsphase vorgenommenen Optimierungen
100
und Anpassungen besprochen.
In Kapitel 6 wurde das Bedienkonzept von TInTo, einschlieÿlich zahlreicher Screenshots, vorgestellt. Anhand eines Beispielszenarios wurde exemplarisch ein Ablauf von
der Auswahl des Wertpapieres, über die Denition eines neuen Indikators, bis hin zur
Darstellung im ChartDirector aufgezeigt.
Bei den in dieser Arbeit erarbeiteten und vorgestellten Lösungen wurden jedoch
auch Probleme oensichtlich, insbesondere bei der Berechnung von Indikatoren aus
der Gruppe der mehrstugen Aggregate (siehe auch Kapitel 5.5). Dabei kann vom
grundsätzlichen Verfahren der mehrstugen Berechnung aufgrund der Berechnungsvorschriften dieser Indikatoren nicht abgerückt werden. Dennoch konnte gezeigt werden,
dass durch geschickte Materialisierung der Daten noch Ezienzsteigerungen möglich
sind.
Zusätzlich sind Erweiterungen bei den Indikatoren der Gruppe der rekursiven In-
dikatoren möglich. Die im Rahmen dieser Arbeit vorgestellte Lösung ist nur in einer Einzelplatzumgebung anwendbar, da die verwendeten Hilfsfelder bei Anwendung
durch mehrere Benutzer inkonsistente Werte erhalten würden. In Kapitel 5.4.4 wurde
bereits eine Lösung dieses Problems durch Verwendung einer zusätzlichen Tabelle aufgezeigt. Die zur Berechnung notwendigen Hilfsfelder könnten dort anwenderabhängig
(und damit zwischen verschiedenen Anwendern kollisionsfrei) abgelegt werden.
Interessant ist auch die Unterstützung von Intraday (oder Realtime)-Kursdaten.
In TInTo werden Intraday-Kurse nicht betrachtet, obwohl die für TInTo erarbeiteten Berechnungsmethoden für Indikatoren ebenfalls auf Intradaykurse anwendbar
sind. Hierzu müsste einerseits das Einlesen der Kursinformation auf den Umgang mit
Intraday-Daten umgestellt werden, da diese Kursdaten mit höherer Datenrate eintreen. Dies würde entweder mit höherer Einlesefrequenz geschehen, oder die neuen
Intraday-Daten müssten ereignisgesteuert (in einer Art Push-Betrieb) in die Datenbank aufgenommen werden. Gleichzeitig müsste die Datenstruktur erweitert werden,
um sowohl EOD-, als auch Intraday-Daten, speichern zu können. Dies ist notwendig,
damit die Indikatorsichten nicht mehrfach deniert werden müssen.
In der Zukunft sollte TInTo entsprechend erweitert werden, um ein vollständiges
Handelssystem zu erhalten. Dies schliesst die Fähigkeit, mehrere Indikatoren gleichzeitig zu berechnen, ebenso ein, wie die Formulierung von Handelsstrategien in Abfragen. Hieraus ergeben sich dann für den Anwender enstprechende Vorschläge für Kaufoder Verkaufsentscheidungen. Denkbar wäre sogar ein vollständig autonomes System
für den selbstständigen, algorithmischen Handel an Börsenplätzen.
101
7 Zusammenfassung
102
A Module und Funktionen
Dieser Anhang enthält die in den Modulen implementierten Funktionen jeweils inklusive ihrer Parameter und Rückgabewerte sowie einer kurzen Funktionsbeschreibung
(siehe auch Kapitel 5.3).
Modul Yahoo
Public Function DataLoad(sSymbol As String) As Integer
Parameter
sSymbol: Wertpapier-Symbol
Rückgabewert
TInTo-ID des Wertpapieres, sonst 0
Beschreibung
Importiert Kurs- und Umsatzdaten von Yahoo
Function DataInitSymbol(sSymbol As String) As Long
Parameter
sSymbol: Wertpapier-Symbol
Rückgabewert
TInTo-ID des Wertpapieres, sonst 0
Beschreibung
neues Wertpapier in TInTo anlegen, Prüfung und Abgleich über Yahoo
Klassenmmodul clsHTTP
Public Sub ConnectToHTTPHost()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Stellt Verbindung zum zuvor angegebenen HTTP-Server (Host) her
Public Sub DialDefaultNumber()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Önet Internetverbindung über Windows-DFÜ-Netzwerk
Public Function WriteHTTPDataToString() As String
Parameter
keine
Rückgabewert
eingelesene Zeichenkette
Beschreibung
Schreibt gelesene Daten aus HTTP-Stream in Zeichenkette
Public Sub WriteHTTPDataToFile()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schreibt gelesene Daten aus HTTP-Stream in Datei
103
A Module und Funktionen
Private Sub Class_Initialize()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Initialisiert HTTP-Klasse
Private Sub Class_Terminate()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Terminiert HTTP-Klasse
Public Property Let HttpURL(ByVal strURL As String)
Parameter
strURL: URL Zieladresse
Rückgabewert
keiner
Beschreibung
Setzt URL der Zieladresse
Public Property Let hwnd(ByVal SourcehWnd As Long)
Parameter
SourcehWnd: Fensterhandle
Rückgabewert
keiner
Beschreibung
Setzt Fensterhandle für GDI-Handling
Public Property Get FileExists() As Boolean
Parameter
keine
Rückgabewert
Wahr, wenn Zieldatei mstrDestination existiert
Beschreibung
Prüft, ob Zieldatei mstrDestination bereits existiert
Public Property Let OverwriteTarget(ByVal blnOverWrite As Boolean)
Parameter
blnOverWrite: Datei überschreiben ja/nein
Rückgabewert
keiner
Beschreibung
Bestimmt, ob Dateiüberschreiben erlaubt
Public Property Let DestinationFile(ByVal strFilePath As String)
Parameter
strFilePath: Zieldatei
Rückgabewert
keiner
Beschreibung
Setzt Zieldatei mstrDestination
Public Property Get SpecifiedURL() As String
Parameter
keine
Rückgabewert
keiner
Beschreibung
Setzt SpeciedURL
Public Property Let PromptWithCommonDialog(blnYesNo As Boolean)
Parameter
blnYesNo: Rückfrage ja/nein
Rückgabewert
keiner
Beschreibung
Bestimmt, ob Dateiname abgefragt werden soll
Public Property Get SizeOfFile() As Long
Parameter
keine
Rückgabewert
Gröÿe der HTTP-Daten
Beschreibung
Liefert die Anzahl der Daten im HTTP-Stream
Public Property Get IsConnected() As Boolean
Parameter
keine
Rückgabewert
Wahr, wenn Verbindung besteht
Beschreibung
Liefert Verbindungsstatus
104
Private Function fParseURL(tURLInfo As URL_COMPONENTS,
ByVal strURL As String) As Boolean
Parameter
tURLInfo: Rahmendaten für Verbindungsaufbau
strURL: URL-Zeichenkette
Rückgabewert
Wahr, wenn Parsen erfolgreich
Beschreibung
Prüft eine vorhandene URL
Private Function fInetError(ByVal lngErrCode As Long) As String
Parameter
lngErrCode: Fehlercode
Rückgabewert
Fehler im Klartext als Zeichenkette
Beschreibung
Wandelt Fehlercode in Klartext um (API)
Private Function fGetHTTPErrCode(ByVal strError As String) As String
Parameter
strError: Fehlercode
Rückgabewert
Fehler im Klartext als Zeichenkette
Beschreibung
Wandelt Fehlercode in Klartext um (Klasse)
Private Function fTrimNull(ByVal strIn As String) As String
Parameter
strIn: Zeichenkette
Rückgabewert
Zeichenkette
Beschreibung
Schneidet Zeichenkette bei NULL ab
Private Function fGetNewFileName(strMsg As String,
hwnd As Long,
blnOpen As Boolean) As String
Parameter
strMsg: Messagetext
hwnd: Fensterhandle
blnOpen: Openag
Rückgabewert
Zeichenkette
Beschreibung
Fragt Dateinamen ab
Private Function fAPIErr(ByVal lngErr As Long) As String
Parameter
lngErr: System-Fehlercode
Rückgabewert
Zeichenkette
Beschreibung
Wandelt Systen-Fehlercode in Zeichenkette
Modul Chart
Public Function spGetID() As Long
Parameter
keine
Rückgabewert
keiner
Beschreibung
Liefert ID der akuell gewählten Wertpapieres zur Verwendung in Abfragen
Public Function spGetN() As Long
Parameter
keine
Rückgabewert
keiner
Beschreibung
Liefert Einschränkung für n zur Verwendung in Abfragen
Public Function spGetPar(p As String) As Double
Parameter
p: Parameter, ggf. inklusive Vorgabe
Rückgabewert
Eingegebener Parameter als Gleitkommazahl
Beschreibung
Frage Paremeter beim Anwender ab
105
A Module und Funktionen
Public Function ChartShow(ID As Long,
typ As Long,
Vol As Long,
Log As Long,
iv As Long,
band As Long,
sInd As String,
CDInd As Long) As Long
Parameter
ID: Wertpapier-ID
typ: Charttyp
Vol: Volumenbalken ja/nein
Log: Logarithmische Skala ja/nein
iv: Anzeigeintervall
band: Preisband
sInd: TInTo-Indikator
CDInd: ChartDirector-Indikator
Rückgabewert
Fehlercode
Beschreibung
Stellt Kurs-, Umsatz und Indikatordaten dar
Function ChartAddQuery(qName As String, qSQL As String) As Long
Parameter
qName: Abfragename
qSQL: SQL-Formulierung der Abfrage
Rückgabewert
Fehlercode
Beschreibung
Erzeugt Abfragen in Access; rekursiv
Function IndParSet(c As FinanceChart,
cxy As XYChart,
ll As LineLayer,
p As String)
Parameter
c: ChartDirector Haupt-Objekt
cxy: ChartDirector Chart-Objekt
ll: Indikator-Objekt
p: Parameter
Rückgabewert
keiner
Beschreibung
Setzt Indikator-Darstellungsparameter
Helper
Function APIGetComputerName() As String
Parameter
keine
Rückgabewert
Name des Computers
Beschreibung
Liefert aktuellen Computername
Public Function GetTwipsPerPixel(p As Long) As Long
Parameter
p: XY-Parameter
Rückgabewert
Twips pro Pixel
Beschreibung
Liefert für X- oder Y-Achse die Twips pro Pixel
106
Function GetSystemDir() As String
Parameter
keine
Rückgabewert
Systemverzeichnis
Beschreibung
Liefert das Windows-Systemverzeichnis
Public Function InitChartDir() As Long
Parameter
keine
Rückgabewert
Fehlercode
Beschreibung
Installiert/Registiert den ChartDirector
Public Function LicenseChartDir() As Long
Parameter
keine
Rückgabewert
Fehlercode
Beschreibung
Lizensiert den ChartDirector
Public Function ListElem(s As String, i As Long) As String
Parameter
s: Liste als Zeichenkette
i: Element
Rückgabewert
Zeichenkette
Beschreibung
Extrahiert das i-te Element einer Liste
Form_Main
Private Function ChartSet()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Ruft das aktuelle Chart auf
Private Sub About_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Önet Über...-Dialog
Private Sub CDIndSet_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Speichert gewählten ChartDirector-Indikator
Private Sub CTyp_Change()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Speichert gewählten Diagrammtyp
Private Sub Form_Load()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Initialisiert Variablen bei Laden von TInTo
Private Sub Form_Open(Cancel As Integer)
Parameter
Cancel: Abbruch
Rückgabewert
keiner
Beschreibung
Blendet Access-Fenster beim Önen von TInTo aus
107
A Module und Funktionen
Private Sub Form_Resize()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Ereignis beim Modizieren des TInTo-Formulares
Private Sub Form_Unload(Cancel As Integer)
Parameter
Cancel: Abbruch
Rückgabewert
keiner
Beschreibung
Entladen von TInTo: Access beenden
Private Sub IndDel_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Indikator löschen
Private Sub IndMod_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Indikator modizieren
Private Sub IndNew_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Neuer Indikator
Private Sub IndSet_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Indikator auswählen
Private Sub Iv01_MouseDown(Button As Integer,
X As Single, Y As
Private Sub Iv02_MouseDown(Button As Integer,
X As Single, Y As
Private Sub Iv03_MouseDown(Button As Integer,
X As Single, Y As
Private Sub Iv04_MouseDown(Button As Integer,
X As Single, Y As
Private Sub Iv05_MouseDown(Button As Integer,
X As Single, Y As
Parameter
Button: Schaltäche
Shift: Shift-Tastenstatus
X,Y: Mauskoordinaten
Rückgabewert
keiner
Beschreibung
Wählt neues Darstellungsintervall
Private Sub Log_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Logarithmische Skala ja/nein
108
Shift As
Single)
Shift As
Single)
Shift As
Single)
Shift As
Single)
Shift As
Single)
Integer,
Integer,
Integer,
Integer,
Integer,
Private Sub OK_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Wertpapier anzeigen
Private Sub PriceBand_Change()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Angezeigtes Preisband auswählen
Private Sub Quit_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
TInTo beenden
Private Sub Tabelle_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Werte in Tabellenansicht darstellen
Private Sub View_DblClick(Cancel As Integer)
Parameter
Cancel: Abbruch
Rückgabewert
keiner
Beschreibung
Doppelklick Liste: Indikator modizieren
Private Sub Vol_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Volumendaten ja/nein
Function GetTyp() As Long
Parameter
keine
Rückgabewert
Darstellungstyp
Beschreibung
Darstellungstyp ermitteln
Private Function IMod()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Dialog zum Bearbeiten eines Indikators aufrufen
Form_Symbol
Private Sub Cancel_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Wertpapierauswahl abbrechen
Private Sub Form_Load()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Wertpapierauswahl initialisieren
109
A Module und Funktionen
Private Sub Liste_DblClick(Cancel As Integer)
Parameter
Cancel: Abbruch
Rückgabewert
keiner
Beschreibung
Doppelklick Liste: Wertpapierauswahl bestätigen
Private Sub OK_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Wertpapierauswahl bestätigen
Form_Ind
Private Sub Cancel_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Indikatorbearbeitung abbrechen
Private Sub Form_Load()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Formular laden: Indikatorbearbeitung initialisieren
Private Sub Form_Unload(Cancel As Integer)
Parameter
Cancel: Abbruch
Rückgabewert
keiner
Beschreibung
Formular entladen: Ereignis zurücksetzen
Private Sub OK_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Schaltäche: Indikatorbearbeitung beenden und Modikationen speichern
Private Sub Tabelle_Click()
Parameter
keine
Rückgabewert
keiner
Beschreibung
Indikatordaten in Tabelle anzeigen
110
B Literaturverzeichnis
[AG06]
Aggarwal, Charu C., Data Streams: Models and Algorithms. Springer,
2006.
[BD00]
Bruegge, Bernd und Dutoit, Allen H., Object-Oriented Software Engi-
neering. Conquering Complex and Changing Systems. Prentice Hall,
2000.
[CTEC06]
http://www.charttec.com, Claus Lampert Finanzinformationen, Fasanenweg 2, 77694 Kehl
[CH76]
Peter Pin-Shan Chen, The Entity-Relationship ModelToward a Uni-
ed View of Data. http://bit.csc.lsu.edu/~chen/pdf/erd.pdf
[CD06]
http://www.comdirect.de, comdirect bank AG, 25449 Quickborn
[CO70]
Codd, Edgar F., A Relational Model of Data for Large Shared Data
Banks, in: Communications of the ACM. 6/13/Juni 1970, ACM Press,
New York, S. 377-387
[DA06]
Daeubner, Pierre M., Alles was Sie über Technische Analyse wissen
müssen. FinanzBuch Verlag, 2. Auage 2006.
[DD96]
Date, Chris J. und Darwen, Hugh, SQL - Der Standard. SQL/92
mit den Erweiterungen CLI und PSM. Addisson-Wesley-Longman.
4. Auage 1996.
[FTC06]
Die Erfolgsmessung technischer Handelsansätze: Forschung noch am
Anfang, www.ftc.at/display/id/11120, FTC Vermögensberatung Pomeranz und Partner GmbH, Schottenring 12, A-1010 Wien
[GE05]
Geppert, Alexander, Ein regelbasierter Ansatz zur Modellierung der
technischen Analyse von Wertpapierkursen, Diplomarbeit, Rheinische
Friedrich-Wilhelms-Universität Bonn, 2005.
[JE05]
Jeckle, Mario et al, UML 2 glasklar, Carl Hanser Verlag, 2005.
[KA01]
Kahn, Michael N., Technische Analyse. Financial Times Prentice
Hall, 2005.
111
B Literaturverzeichnis
[KE98]
Kelz, Andreas, Relationale Datenbanken - Eine Einführung, Hochschule der Medien (HdM) Stuttgart, 1998.
[KR04]
Krumme,
Andreas,
Objektorientierte
und
regelbasierte
Modellie-
rung von Wertpapieren und Kursverläufen, Diplomarbeit, Rheinische
Friedrich-Wilhelms-Universität Bonn, 2005.
[MT04]
Manthey, Rainer, Folien zur Vorlesung Deduktive Datenbanken, Sommersemester 2004, Rheinische Friedrich-Wilhelms-Universität Bonn,
2004.
[MA98]
Matthes, F. und Schmidt, J.W., Datenbankhandbuch: Datenbankmo-
delle und Datenbanksprachen, Technische Universität Harburg, 1998.
[MSACC03]
Microsoft-Oce Access Hilfe, Microsoft Access 2003.
[PI04]
Park, Cheol-Ho and Irwin, Scott H., The Protability of Technical
Analysis: A Review (October 2004). AgMAS Project Research Report No. 2004-04. http://ssrn.com/abstract=603481
[PI05]
Park, Cheol-Ho and Irwin, Scott H., The Protability of Techni-
cal Trading Rules in US Futures Markets: A Data Snooping Free
Test (May 2005). AgMAS Project Research Report No. 2005-04.
http://ssrn.com/abstract=722264
[STR06]
http://www-db.stanford.edu/stream, Stanford Stream Data Manager,
Stanford University, Stanford, CA 94305, USA
[TSIG06]
http://www.tradesignalonline.com, SystemSoft GmbH, Linzer Straÿe
11, 28359 Bremen
[WIKI06]
http://www.wikipedia.de, Wikipedia, Die freie Enzyklopädie. Wikimedia Foundation Inc., 200 2nd Ave. South 358, St. Petersburg, FL
33701-4313, USA
[XETRA06]
http://www.deutsche-boerse.com, Deutsche Börse AG, 60485 Frankfurt am Main
112
B Literaturverzeichnis
Erklärung gemäÿ Ÿ19(7) der Prüfungsordnung
Hiermit erkläre ich, dass ich diese Diplomarbeit selbstständig durchgeführt, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate als solche
kenntlich gemacht zu haben.
Meckenheim, den 19. Januar 2007
Christian Hübel
113