Finden von Assoziationsregeln

Transcription

Data Mining Verfahren zum
Finden von Assoziationsregeln
und Evaluierung durch das Werkzeug MISTRAL
Diplomarbeit von
Joachim Baumeister
Betreuer:
Dipl.–Inform. Ioannis Iglezakis
Prof. Dr. Frank Puppe
August 1998
Lehrstuhl für Künstliche Intelligenz
und Angewandte Informatik
Universität Würzburg
Erklärung
Ich erkläre hiermit, dass ich diese Arbeit selbstständig angefertigt habe und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Würzburg, 4. August 1998
Joachim Baumeister
Inhaltsverzeichnis
1 Einleitung
7
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.3
Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . .
9
2 Data Mining und das Finden von Informationen
11
2.1
Der KDD Prozess . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Verschiedene Data Mining Verfahren . . . . . . . . . . . . . . . .
13
2.2.1
Klassifikation . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.2
Clusteranalyse . . . . . . . . . . . . . . . . . . . . . . .
14
2.2.3
Regressionsverfahren . . . . . . . . . . . . . . . . . . . .
14
2.2.4
Assoziationsregeln . . . . . . . . . . . . . . . . . . . . .
15
2.2.5
Sequentielle Muster . . . . . . . . . . . . . . . . . . . .
15
2.2.6
Weitere Musterarten . . . . . . . . . . . . . . . . . . . .
15
Stand der Forschung . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3
3 Das Finden von Assoziationsregeln
3.1
19
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.1
19
Grundlegende Definitionen . . . . . . . . . . . . . . . . .
Inhaltsverzeichnis
4
3.2
3.3
3.4
3.5
4
3.1.2
Generischer Algorithmus . . . . . . . . . . . . . . . . . . 20
3.1.3
Arten von Assoziationsregeln . . . . . . . . . . . . . . . 22
Einfache boolsche Assoziationsregeln . . . . . . . . . . . . . . . 23
3.2.1
AIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2
SetM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3
Die Apriori–Klasse . . . . . . . . . . . . . . . . . . . . . 27
3.2.4
Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Generalisierte Assoziationsregeln
. . . . . . . . . . . . . . . . . 36
3.3.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2
Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3
Cumulate . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.4
EstMerge . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.5
Filtern der interessanten Regeln . . . . . . . . . . . . . . 43
Quantitative Assoziationsregeln . . . . . . . . . . . . . . . . . . 45
3.4.1
Problemstellung . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2
Grundlegende Definitionen . . . . . . . . . . . . . . . . . 46
3.4.3
Vorgehensweise beim Finden von quantitativen Assoziationsregeln . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.4
Partitionierung der quantitativen Attributwerte . . . . . . 48
3.4.5
Filtern der interessanten Regeln . . . . . . . . . . . . . . 52
3.4.6
Ergänzungen zum Algorithmus . . . . . . . . . . . . . . 53
Betrachtung der Komplexität . . . . . . . . . . . . . . . . . . . . 55
Implementierung des Werkzeugs M ISTRAL
59
4.1
Überlegungen zur Implementierung eines Data Mining Werkzeugs
59
4.2
Architektur von M ISTRAL . . . . . . . . . . . . . . . . . . . . . 60
4.2.1
Der Kern . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Inhaltsverzeichnis
4.3
5
4.2.2
Speicherbereiche . . . . . . . . . . . . . . . . . . . . . .
62
4.2.3
Speicherung der Artikel . . . . . . . . . . . . . . . . . .
64
4.2.4
Die Mistral-Komponenten . . . . . . . . . . . . . . . . .
65
Aspekte der Implementierung . . . . . . . . . . . . . . . . . . . .
68
5 Bedienungshinweise zu M ISTRAL
69
5.1
Aufbau eines Data Mining Laufes . . . . . . . . . . . . . . . . .
69
5.2
Menüstruktur von MISTRAL . . . . . . . . . . . . . . . . . . . .
71
5.3
Definition eines M ISTRAL Projekts . . . . . . . . . . . . . . . . .
72
5.4
Arbeiten mit M ISTRAL Komponenten . . . . . . . . . . . . . . .
72
5.4.1
Koppeln . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.4.2
Vorhandene Komponenten . . . . . . . . . . . . . . . . .
74
5.5
Das Tools Menü . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.6
Dateiformat: TextDataFetcher . . . . . . . . . . . . . . . . . . .
76
5.7
Dateiformat: Taxonomie-Definition . . . . . . . . . . . . . . . .
77
6 Auswertung der Daten und Ergebnisse
79
6.1
Synthetische Daten . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.2
Katalysator-Testfahrten der Degussa AG . . . . . . . . . . . . . .
83
6.2.1
Vorverarbeitung der Daten . . . . . . . . . . . . . . . . .
83
6.2.2
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . .
84
Die Warenwirtschaft der Firma Quitmann . . . . . . . . . . . . .
85
6.3.1
85
6.3.2
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . .
86
Pflanzenwissensbasis . . . . . . . . . . . . . . . . . . . . . . . .
88
6.4.1
88
6.4.2
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.3
6.4
Inhaltsverzeichnis
6
7
Regelfindung in diagnostischen Domänen
7.1
7.2
7.3
8
93
Clusterbildung unter Verwendung von Standardverfahren . . . . . 93
7.1.1
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . 94
7.1.2
Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . 95
Support in Intervallen (A PRIOR I NTERVALL ) . . . . . . . . . . . . 96
7.2.1
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . 96
7.2.2
Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . 98
Anmerkungen zum RX-Projekt . . . . . . . . . . . . . . . . . . . 98
Zusammenfassung und Ausblick
101
8.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Beschreibung der beigelegten CD–ROM
104
Danksagung
105
Literaturverzeichnis
107
1
Einleitung
Diese Arbeit untersucht mit dem Finden von Assoziationsregeln einen Bereich des
Data Minings. Zunächst werden Gründe angeführt, die Data Mining und speziell
Assoziationsregeln für Forschung und Wirtschaft interessant machen. Im Weiteren werden die Ziele dieser Arbeit näher umschrieben. Das Kapitel schließt mit
einer Übersicht über die vorliegende Arbeit.
1.1 Motivation
Beachtliche Fortschritte bei der Sammlung und Speicherung von Daten haben in
den letzten 10 Jahren zu einem rapiden Anstieg der Datenbestände geführt. Einen
nicht zu unterschätzenden Einfluss hatte hierbei auch die Einführung der BarcodeTechnologie: Da inzwischen nahezu jeder Artikel einen Barcode trägt, ist dieser
datentechnisch erfassbar. Zusätzlich wurde es den Unternehmen durch die preiswert zur Verfügung stehenden Massenspeicher möglich, weit mehr Daten zu speichern als dies noch vor einigen Jahren getan wurde. Diesen erheblichen Anstieg
ihrer Datenmenge wollen die Unternehmen nutzen, um dem weltweit zunehmenden Wettbewerbsdruck entgegentreten zu können. Der erste Schritt besteht darin,
die verschiedenen heterogenen Datenbestände des Unternehmens zentral und einheitlich verfügbar zu machen. Dieser Übergang zur Speicherung der Daten in sogenannten Data Warehouses ist heute meist schon vollzogen. Da die gesammelten
Datenbestände durch ihre Größe in der Regel unmöglich manuell analysiert werden können, besteht der nächste logische Schritt in der Nutzung von Data Mining
Technologien.
7
1. Einleitung
8
Data Mining beschreibt die Gewinnung von nützlichen Informationen aus bestehenden Datenbeständen. Nützliche Informationen können hierbei von mannigfaltiger Natur sein: Die Daten können anhand ihrer Eigenschaften in Blöcken
gruppiert oder klassifiziert worden sein. Oft ist es auch möglich, Beziehungen
zwischen den einzelnen Daten zu finden.
Diese Informationen wollen die Anwender nutzen, um ein besseres Verständnis
über Zusammenhang und Aufbau der Daten zu erlangen. Durch das Wissen von
Mustern und Abläufen in den gespeicherten Geschäftsprozessen erhofft man sich
schließlich eine intelligentere Entscheidungsunterstützung bei relevanten Problemfällen.
An Data Mining werden also große Hoffnungen und Wünsche geknüpft, die es
heute auch zum Teil schon erfüllen kann. Ermutigt werden diese Erwartungen
durch aufsehenerregende Meldungen aus der Wirtschaft, in denen einzelne Unternehmen durch den Einsatz von Data Mining spürbare Gewinne einfahren konnten. Als bekanntes Beispiel dient das weltgrößte Einzelhandelsunternehmen WalMart, das sich durch konsequenten Einsatz von Data Warehouse/Data Mining
Technologie von der Konkurrenz absetzen konnte.1
1.2 Zielsetzung
Data Mining bildet den zusammenfassenden Überbegriff für eine wachsende Anzahl verschiedener Technologien, die ihren Ursprung in der Statistik, der Datenbanktheorie und dem Maschinellen Lernen haben. Zu den bekanntesten Mining
Arten zählen Klassifikation, Clusterbildung, Regression und Assoziationsregeln.
In dieser Arbeit wird nur eine bestimmte Art von Data Mining Verfahren untersucht werden: Das Finden von Assoziationsregeln, welches erstmals in [AIS93]
vorgestellt wurde. Assoziationsregeln beschreiben Relationen zwischen häufig
auftretenden Datenausprägungen. Im Kontext eines Supermarktes, in welchem
man die Artikel A, B und C kaufen kann, könnte eine Assoziationsregel folgendermaßen lauten: “Wenn der Kunde Artikel A kauft, dann kauft er auch mit 80%
Wahrscheinlichkeit die Artikel B und C.” Für medizinische Diagnosen könnte eine Assoziationsregel so lauten: “Hat der Patient die Laborwertausprägungen L1
und L2 , dann spricht das mit 75% Wahrscheinlichkeit für Diagnose D.” Die vorliegende Arbeit beschreibt eine Anzahl von Verfahren zum Finden von boolschen,
generalisierten und quantitativen Assoziationsregeln. Durch die Implementierung
1
Für den Erfolg der Kette Wal-Mart sind aber sicherlich auch die mit dem Warehouse zusammenhängende Distributionslogistik und andere weitere Faktoren verantwortlich [Log98].
1.3. Struktur der Arbeit
9
mehrerer Verfahren werden später synthetische und reale Szenarien untersucht
werden. In den realen Szenarien sind sowohl transaktionelle als auch diagnostische Domänen vertreten.
1.3 Struktur der Arbeit
Die Arbeit gliedert sich in einen theoretischen und einen praktischen Teil. Die
einzelnen Kapitel sind in folgender Weise zu lesen:
Kapitel 2 gibt einen kurzen Überblick in das umfassende Gebiet des Data
Mining. Hierfür wird der Begriff des KDD-Prozesses (Knowledge Discovery in Databases) eingeführt, in welchen Data Mining integriert ist. Im Weiteren werden wichtige Data Mining Verfahren vorgestellt und kurz erläutert.
Kapitel 3 beschreibt das Finden von Assoziationsregeln. Zunächst wird auf
die Terminologie der Assoziationsregeln eingegangen, dann ein generischer
Algorithmus zum Finden von Assoziationsregeln gegeben und schließlich
werden die verschiedenen Arten von Assoziationsregeln abgegrenzt. Die
weiteren Abschnitte erläutern Verfahren zum Finden der einzelnen Regelarten. Am Ende des Kapitels wird die Komplexität des A PRIORI-Algorithmus
untersucht, der eine Grundlage für die meisten Verfahren darstellt.
Kapitel 4 geht auf die Implementierung des Data Mining Werkzeugs M I STRAL ein. M ISTRAL wurde im Rahmen dieser Diplomarbeit erstellt und
zeichnet sich durch einen modularen, erweiterbaren Kern aus. Wichtige
Aspekte der Implementierung werden genau untersucht und beschrieben.
Kapitel 5 zeigt, wie man mit dem Werkzeug M ISTRAL Data Mining Projekte anlegen und durchführen kann. Neben der Beschreibung der Programmbedienung werden auch die wesentlichen Dateiformate einiger Komponenten dargestellt.
Kapitel 6 beschreibt zunächst die Evaluierung von M ISTRAL und die
Durchführung von Performanzstudien. Hierfür werden synthetische Daten herangezogen, deren Charakteristika bekannt sind. Nach der Evaluierung werden reale Datenbanken der Firma Degussa AG und Quitmann auf
Assoziationsregeln untersucht. Nach der Analyse der Datensätze werden
die Ergebnisse der verschiedenen Data Mining Läufe dargestellt. Schließlich werden noch zwei unterschiedliche Assoziationsregel–Verfahren in Datensätzen mit diagnostischer Domäne angewandt. Hierzu dient eine Wis-
1. Einleitung
10
sensbasis zur Pflanzenerkennung, die aus dem Expertensystem D3 extrahiert wurde.
Kapitel 7 zeigt, warum der Einsatz von Standardverfahren zum Finden von
Assoziationsregeln in diagnostischen Domänen wenig erfolgreich war. Oftmals ist hier ein häufiges Auftreten der Regeln in der Wissenbasis weniger
wichtig. Ein hohes Vertrauen (Konfidenz) der Regeln spräche aber für eine
interessante Entdeckung. Es werden Ansätze besprochen, wie Regeln mit
dieser Charakteristik gefunden werden können.
Kapitel 8 schließlich fasst die Erkenntnisse und Ergebnisse der vorangegangenen Kapitel zusammen. Der Ausblick auf mögliche zukünftige Entwicklungen im Bereich Assoziationsregeln und zusätzliche Erweiterungen von
M ISTRAL bilden den Abschluss dieser Arbeit.
Diese Arbeit wurde in der neuen Rechtschreibung erstellt; als Textsystem diente
LATEX.
2
Data Mining und das Finden von
Informationen
Bevor diese Arbeit auf das Finden von Assoziationsregeln eingeht, sollen die Begriffe KDD (Knowledge Discovery in Databases) und Data Mining definiert werden. KDD gilt nämlich als der umschließende Prozess, in den Data Mining eingebettet wird. Verschiedene Data Mining Muster neben Assoziationsregeln, wie
Klassifikation, Clusteranalyse oder Sequentielle Muster, werden kurz angesprochen.
2.1 Der KDD Prozess
Data Mining als das Suchen nach Wissen in großen Datenbeständen darf nicht als
isolierter Arbeitsschritt gesehen werden. Vielmehr stellt es ein Teilstück in einem
umfassenden Prozess dar, dem Knowledge Discovery in Databases (KDD). Das
,,Wissen” wird hierbei in Form von Mustern repräsentiert. Laut der Definition in
[FPSSU96] definiert sich KDD wie folgt:
Knowledge Discovery in Databases is the non-trivial process of
identifying valid, novel, potentially usefull and ultimately understandable patterns in data.
KDD ist also ein Vorgang, der zur Gewinnung von Mustern (dem Wissen) dient.
Diese Muster sollten bestimmte Eigenschaften besitzen, wie Gültigkeit (valid),
11
12
2. Data Mining und das Finden von Informationen
Neuartigkeit (novel), Nützlichkeit (useful) und Verständlichkeit (understandable). Data Mining ist innerhalb dieses Prozesses für das Finden dieser Muster
zuständig. Abbildung 2.1 zeigt die einzelnen Komponenten im KDD Prozess.
Abbildung 2.1: Der KDD-Prozess
Man sieht, dass es einer Anzahl von Stufen bedarf, bis von den Daten ausgehend
der Data Mining Schritt angewendet wird.
Zu Beginn ist es wesentlich, dass der Anwender ein Verständnis für die Domäne
entwickelt und seine Ziele, die er mit KDD erreichen will, gebildet hat. Die zur
Verfügung stehende Datenbasis geht häufig auf ein Data Warehouse zurück und
speichert üblicherweise Daten im Giga– bis Terrabyte Bereich. Daher ist es wichtig, eine Auswahl aus dem verfügbaren Datenbestand zu treffen, die beispielsweise nur bestimmte Datensammlungen betrachtet oder aber nur spezielle Attribute berücksichtigt. Die anschließende Vorverarbeitung dieser Zielmenge dient
der Bereinigung der Daten. Hier muss entschieden werden, wie mit fehlerhaften
oder fehlenden Attributen zu verfahren ist. Die folgende Transformation bereitet die Daten für den Data Mining Algorithmus auf. Dabei können zum Beispiel
unwichtige Attribute gefiltert oder auch mehrere Datensätze zu einem neuen zusammengefasst werden. Die Auswahl des zu verwendenden Data Mining Algorithmus fordert vom Benutzer das meiste Wissen. Die zu findende Musterart muss
genau spezifiziert und der dazu passende Algorithmus ausgewählt werden. Nach
dem Data Mining Lauf werden die entdeckten Muster evaluiert. Unter Umständen
benötigt man hierfür weitere Daten aus der Datenbasis. Am Ende des Prozesses
stehen die Evaluation und Interpretation der gefundenen Muster. Entsprechend
ihrer Domäne kann aus den Resultaten des Data Mining Laufs Wissen gebildet
werden. Dieses Wissen ist das gewünschte Ziel des KDD Prozesses.
Man sollte sich bewußt machen, dass dieser Prozess immer vom Menschen mitbegleitet werden sollte. Die Resultate, welche man mit KDD erzielen kann, hängen
im Wesentlichen davon ab, wie interaktiv der Benutzer in den Prozess eingreifen
kann bzw. wie sich schon vorhandenes Wissen einbringen lässt. Die Möglichkeit,
den Nutzer interaktiv in den Prozess miteinzubeziehen, wird in [KMR+ 94] untersucht (siehe dazu auch Seite 22).
2.2. Verschiedene Data Mining Verfahren
13
2.2 Verschiedene Data Mining Verfahren
Eine Schlüsselstelle des KDD Prozesses ist die Auswahl des passenden Data Mining Verfahrens. Die übergeordneten Aufgaben von Data Mining sind Vorhersage
(prediction) und Beschreibung (description). Da die vielen einzelnen Verfahren
unterschiedliche Arten von Mustern finden, ist es sinnvoll, eine Gruppierung nach
der Art der zu findenden Muster vorzunehmen. Die vorliegende Arbeit hat ihren
Schwerpunkt im Finden von Assoziationsregeln als Musterart. Dennoch soll im
Folgenden ein kurzer Überblick über einige wichtige weitere Gruppen gegeben
werden.
2.2.1 Klassifikation
Die Klassifikation zählt zu den überwachten Lernverfahren und hat ihren Ursprung im Maschinellen Lernen. Klassifikation beschreibt dabei die Aufgabe, eine
ungeordnete Menge von Objekten in vorgegebene Klassen zu unterteilen. Diese
vorgegebenen Klassen beschreiben ein Klassifikationsmodell, welches durch eine
sogenannte Trainingsmenge erstellt wird. Die Klassenzugehörigkeit der Objekte
in der Trainingsmenge ist dabei bekannt. So verweisen die Attribute der einzelnen
Datensätze auf eine bestimmte Klasse. Nachdem das Klassenmodell mit der Trainingsmenge aufgebaut worden ist, kann es mit einer dazu disjunkten Testmenge
validiert werden. Anwendung finden Klassifikationsverfahren beispielsweise in
der medizinischen Diagnose, der Kreditvergabe im Bankwesen oder im Direktmarketing.
Zu den bekanntesten Klassifikationsalgorithmen zählen die Entscheidungsbaum
bildenden Verfahren, wie ID–3 von J. R. Quinlan [Qui86] und dessen Nachfolger
C4.5 [Qui93]. Dieser erweitert die Klassifikationsdomäne von kategorischen auf
nummerische Attribute und zeichnet sich durch spezielle pruning–Mechanismen
zur Vermeidung von übertrainierten Bäumen aus.
Ein weiterer Ansatz stellt die Klassifikation mit Hilfe der ILP (induktive Logikprogrammierung) dar. Als bekanntes Verfahren ist hier FOIL [Mit97] zu nennen,
welches Klassifikationsvorschriften in Form von Regeln lernt.
Neuronale Netze werden ebenfalls zur Klassifikation eingesetzt. Sie können von
realen, diskreten oder auch vektoriellen Attributwerten lernen. Als bekanntester
Algorithmus läßt sich hier BACKPROPAGATION [Mit97] nennen.
14
2.2.2 Clusteranalyse
Unter der Clusteranalyse versteht man die automatische Gruppierung einer ungeordneten Menge von Objekten. Die Clusteranalyse zählt zu den nicht–überwachten Lernverfahren und grenzt sich somit von der Klassifikation ab. Während
sich bei der Klassifikation die Objekte in festen Gruppen (Klassen) befinden, sind
die Clustergruppen vor dem Lauf einer Clusteranalyse unbekannt. Eine Funktion bestimmt dabei die Ähnlichkeit zwischen den einzelnen Objekten und ordnet
diese in gleichen oder verschiedenen Clustern an.
Die Clusteranalyse unterscheidet zwischen zwei Verfahrensweisen: Die klassischen Verfahren (nummerische Taxonomie) beschränken sich darauf, die gegebenen Objekte in Gruppen anzuordnen. Das Conceptual Clustering erweitert die
klassischen Verfahren. Der grundlegende Unterschied besteht in der Beschaffenheit der Ähnlichkeitsfunktion: Die nummerische Taxonomie bestimmt die Ähnlichkeit zweier Objekte durch den Wert einer nummerischen Funktion. Damit
besteht jedoch der Nachteil, dass die resultierenden Gruppierungen für den Anwender nicht mehr oder nur sehr schlecht nachvollziehbar sind. Das Conceptual
Clustering behebt diesen Umstand, indem es bei der Bildung der Gruppen auf
Begriffe achtet, welche die jeweiligen Cluster später charakterisieren können.
Zu den bekannten Conceptual Clustering Verfahren zählen die Algorithmen
COBWEB bzw. COBWEB/2 [Fis90].
2.2.3 Regressionsverfahren
Regressionsverfahren dienen zum Erlernen einer Funktion y = f (x)+, die jedem
Objekt x einen reellen Wert y zuordnet. Mit Hilfe von Punkten x im Objektraum
soll also eine Funktion approximiert werden. Die Funktion f kann dabei aus linearen, aber auch aus nichtlinearen Intervallen bestehen. Die Konstante stellt
einen Fehler dar, der beispielsweise durch verrauschte Daten entstehen kann. Gemeinhin wird = 0 angenommen.
Anwendung finden Regressionsverfahren in der Prognose, wie zum Beispiel bei
der Vorherbestimmung von Aktienkursen oder Geschäftsverläufen. Auch in der
medizinischen Domäne können Regressionsverfahren zur Vorhersage von Symptom/Diagnose Kombinationen genutzt werden.
Als bekanntes Regressionsverfahren ist MARS (Multivariate Adaptive Regression Splines) [Fri91] zu nennen.
2.2. Verschiedene Data Mining Verfahren
15
2.2.4 Assoziationsregeln
Assoziationsregeln beschreiben Zusammenhänge zwischen Attributen. Die vorliegende Arbeit beschäftigt sich in den folgenden Kapiteln eingehend mit dem
Finden von Assoziationsregeln. Kapitel 3 beschreibt die einzelnen Arten von Assoziationsregeln und stellt entsprechende Algorithmen vor. Das Kapitel 7 erläutert
die Problematik, Assoziationsregeln in diagnostischen Domänen zu finden, und
zeigt mögliche Verfahren auf.
2.2.5 Sequentielle Muster
Das Finden von sequentiellen Mustern (sequential patterns) ist eng mit dem Finden von Assoziationsregeln verknüpft. Als zu untersuchende Datenbasis wird hier
eine Menge von Datensequenzen (data sequences) herangezogen. Eine Datensequenz stellt eine Menge zusammengehöriger Transaktionen dar. Jede Transaktion
ist durch einen Zeitstempel gekennzeichnet und beinhaltet eine Menge von Artikeln.
Im Kontext einer medizinischen Domäne wäre eine Datensequenz eine sortierte
Sammlung von Arztbesuchen eines bestimmten Patienten, in welcher beispielsweise Symptome und Diagnosen gespeichert sind. Sequentielle Muster könnten
hier helfen, Symptome und Diagnosen zu finden, die anderen Diagnosen (zeitlich)
vorangehen.
Das in [AS94c] vorgestellte A PRIORI A LL–Verfahren dient zum Finden von sequentiellen Mustern. Die Erweiterung GSP (Generalized Sequentual Patterns)
stellt R. Srikant in seiner Dissertation [Sri96] vor. GSP verfügt über die Möglichkeit, Taxonomien und zeitliche Constraints in den sequentiellen Mustern zu
berücksichtigen. Dabei geht das Verfahren ähnlich zu dem auf Seite 28 besprochenen A PRIORI–Algorithmus vor. Er generiert sukzessive zuerst häufige 1er Sequenzen, dann daraus 2er Sequenzen, usw. Die häufigen k–Sequenzen werden
durch Bildung und anschließende Bewertung dieser Kandidaten ermittelt. Der
Unterschied der Verfahren besteht in der Art der Kandidatengenerierung und der
anschließenden Bewertung der Kandidaten.
2.2.6 Weitere Musterarten
Neben den oben vorgestellten gibt es noch weitere Musterarten: Die Aggregierung
(Summariziation) versucht, kompakte Beschreibungen von Untermengen der Da-
16
ten zu finden. Häufig werden diese Methoden bei der interaktiven Datenanlyse
eingesetzt. Das Entdecken von Veränderungen und Abweichungen (Change and
Derivation Detection) sucht die auffälligsten Veränderungen in den Daten und
wird häufig bei der Datenreinigung (Data Cleaning) genutzt. Der Text Retrievel sucht nach Texten, die einem vorgegebenen Text oder angegebenen Attributen
ähnlich sind. Diese Art von Data Mining wird besonders aufgrund der raschen
Vergrößerung des Internets (WWW, News) und den darin enthaltenen (unstrukturierten) Dokumenten an Bedeutung gewinnen. Eine empfehlenswerten Überblick
über diese und weitere Musterarten gibt [CHY96].
2.3 Stand der Forschung
Obwohl Data Mining und inzwischen auch Assoziationsregeln in der Industrie
als Technologien anerkannt und auch angewendet werden, stellen sich an die
Forschung noch viele Herausforderungen: Momentan bestehen die meisten Data Mining Anwendungen aus isolierten Programmen. Heikki Mannila vertritt in
[Man96] sogar die These, dass Data Mining heute auf dem gleichen Stand ist, wie
es das Data Management in den 1960er Jahren war. Nur das relationale Datenmodell und mächtige Datenbankabfragesprachen (wie SQL) konnten damals einen
spürbaren Fortschritt bringen. Mannila schließt daraus, dass auch Data Mining
ein solches theoretisches Framework benötigt, um der gesamten Forschungsrichtung einen Impuls geben zu können.
Jiawei Han beschreibt in seinem Ausblick [Han97] folgende Punkte, die in den
nächsten Jahren Ziel der Data Mining Forschung sein werden:
Integration in Data Warehouse und OLAP Technologien
Schon heute bestehen in vielen Anwendungsbereichen Data Warehouse Implementierungen, die mit Erfolg eingesetzt werden. Das Gleiche gilt für
zahlreiche OLAP Werkzeuge, die man als Vorstufe zu Data Mining Anwendungen sehen kann. Durch die Integration von Data Mining Verfahren
in bestehende Data Warehouse oder OLAP Installationen würde man die
Nützlichkeit und Mächtigkeit aller Technologien merklich anheben können.
Herausbilden neuer Wissensarten
Es ist denkbar, dass neben den bekannten Wissensarten durchaus weitere Muster entwickelt werden könnten. So könnten beispielsweise neben
Klassifikation, Clusteranalyse oder auch Assoziationsverfahren neue Muster, wie Charakterisierung, Vergleich oder zeitabhängige Muster, entste-
2.3. Stand der Forschung
17
hen. Viele dieser Musterarten sind nicht oder noch nicht ausreichend erforscht.
Entwicklung einer Data Mining Hochsprache
Wie schon zuvor angesprochen, kann die Entwicklung einer Data Mining
Hochsprache merkliche Fortschritte bringen. Eine solche Sprache würde es
Nutzern erlauben, ad-hoc Data Mining Verfahren oder Muster zu beschreiben. Darüber hinaus könnte die interaktive und Muster-gerichtete Suche
effizienter und flexibler umgesetzt werden.
Umgang mit immer komplexeren Daten
Momentan beschränkt sich das Finden von Mustern hauptsächlich auf Domänen, denen relationale oder transaktionelle Daten zu Grunde liegen.
Trotzdem wird in Zukunft das Finden von Mustern auf unstrukturierten oder
halb-strukturierten Daten, wie Hypertext oder Multimedia-Daten, immer interessanter werden.
Hocheffizientes Data Mining
Durch die steigenden Datenmengen werden effizientere Verfahren im Zielpunkt der Forschung stehen. So beschäftigen sich verschiedene Richtungen
mit parallelem [SON95], verteiltem oder auch inkrementellem Data Mining
[CHNW96].
Visualisierung
Nicht nur die richtige und verständliche Visualisierung der gefundenen Muster ist für den Erfolg eines Data Mining Projekts von entscheidender Bedeutung. Schon eine hilfreiche Darstellung der bestehenden Daten mit interaktiven Visualisierungs-Werkzeugen kann die Auswahl einer sinnvollen
Quellmenge bzw. des benötigten Data Mining Verfahrens erheblich vereinfachen.
Anwendungen
Neben den Fragen nach der technischen Realisierung stehen auch Fragen
nach der Verwendung der gefundenen Muster offen: Wie können die gefundenen Muster erfolgreich in die geschäfts– oder entscheidungsfindenden
Bereiche eingebracht werden? Wie integriert man das erarbeitete Wissen in
bestehende Wissensbasen oder Expertensysteme?
18
3
Das Finden von
Assoziationsregeln
Dieses Kapitel schafft die theoretischen Grundlagen, die zum Verständnis von Assoziationsregeln nötig sind. Zunächst werden allgemeingültige Definitionen und
ein generischer Algorithmus zum Finden von Assoziationsregeln beschrieben. In
den folgenden Abschnitten werden Algorithmen zum Finden von boolschen Assoziationsregeln (Seite 23), generalisierten Assoziationsregeln (Seite 36) und quantitativen Assoziationsregeln (Seite 45) vorgestellt.
3.1 Einführung
Das Finden von Assoziationsregeln stützt sich auf eine kleine Anzahl von Begriffen, die nun erläutert werden. Danach wird ein generischer Algorithmus zum
Finden von Assoziationsregeln skizziert und ein einfacher Algorithmus zum Generieren von Assoziationsregeln aus häufigen Artikelmengen präsentiert.
3.1.1 Grundlegende Definitionen
Assoziationsregeln beschreiben Korrelationen zwischen gemeinsam auftretenden
Dingen [Bol96]. ,,Dinge” können in diesem Zusammenhang sehr unterschiedlicher Natur sein: Im Kontext eines Kaufhauses würde es sich um Waren, wie zum
Beispiel ,,Schokolade” oder ,,Brot” handeln. Im Rahmen der medizinischen Diagnose kann man aber auch verschiedene Symptome als ,,Dinge” bezeichnen, die
19
20
3. Das Finden von Assoziationsregeln
gemeinsam mit einer bestimmten Diagnose auftreten.
Formal betrachtet lassen sich Assoziationsregeln wie folgt definieren [AS94a]:
Assoziationsregeln Sei I = fI1; I2; : : :; Im g eine Menge von Attributen, die man
als Artikel (items) bezeichnet. Eine Transaktion T besteht aus einer Menge von
Artikeln, so dass T I gilt. D sei als die Datenbank gegeben, in der alle Transaktionen gespeichert sind. Mit jDj wird die Größe der Datenbank als Anzahl der
Transaktionen definiert. Eine Transaktion T unterstützt (supportet) X , eine Menge einiger Artikel aus I , wenn X T gilt. Eine Assoziationsregel ist dann eine
Implikation der Form X ) Y , wenn X I , Y I und X \ Y = ; gilt.
Eine k-Erweiterung E einer Artikelmenge X 2 I und X = fi1; : : :; in g ist eine
Obermenge von X und E hat folgende Eigenschaft:
E = fi1; : : : ; in; in+1; : : :; in+k g, so dass gilt X \ fin+1; : : :; in+k g = ; und
in+1; : : :; in+k 2 I .
Support und Konfidenz Eine Regel X ) Y hat einen Support (support) von s
Prozent, wenn s Prozent der Transaktionen aus D die Artikel die X [ Y enthalten.
Formal ausgedrückt definiert sich also der Support der Regel X ) Y :
X [ Y ) tgj
support(X ) Y ) = jft 2 D j (jDj
(3.1)
Eine Regel X ) Y besitzt eine Konfidenz (confidence) von c Prozent, wenn c
Prozent der Transaktionen in D, die X enthalten, auch Y enthalten. Die formale
Definition der Konfidenz erschließt sich also wie folgt:
(X ) Y )
confidence(X ) Y ) = jft jf2tD2jD(Xj X[ Y)tgj tgj = support
support(X )
(3.2)
Eine Artikelmenge wird als häufig (frequent, large, strong) bezeichnet, wenn sie
einen vom Benutzer vorgegebenen Supportwert (min support) überschreitet.
3.1.2 Generischer Algorithmus
Das Problem des Findens von Assoziationsregeln lässt sich nun als das Problem
beschreiben, in D alle Implikationen der Form X ) Y zu finden, deren Support
und Konfidenz größer als die vom Benutzer vorgegebenen Schranken sind.
Alle Verfahren folgen dabei der gleichen Struktur, die in Algorithmus 3.1.1 wiedergegeben ist:
3.1. Einführung
21
Algorithmus 3.1.1 Generischer Algorithmus zum Finden von Assoziationsregeln
(1) Finde alle ,,häufigen Artikelmengen” in der Datenbasis D.
(2) Generiere aus diesen Mengen die Regeln,
welche die vorgegebene Konfidenz erfüllen.
(3) Filtere die Regeln nach Interesse des Benutzers.
Die drei Unterpunkte sollen nun näher betrachtet werden:
(1) Finden der häufigen Artikelmengen Die Feststellung der häufigen Artikelmengen bildet den Kern aller Verfahren. Hier treten die wesentlichen Unterschiede zwischen den einzelnen Algorithmen auf. Eine genaue Beschreibung verschiedener Vorgehensweisen folgt in den nächsten Abschnitten.
(2) Generierung der Regeln Nachdem die häufigen Artikelmengen mit Hilfe der
Algorithmen gefunden wurden, können die Regeln gebildet werden. Algorithmus
3.1.2 stellt das ad–hoc Verfahren aus [AS94b] zur Generierung von Regeln vor.
Dabei sei Lk die Menge der häufigen Artikelmengen mit der Größe k .
Algorithmus 3.1.2 Ad–hoc Algorithmus zur Regelgenerierung
forall (Lk , k > 2) f
call genrules(lk , lk );
g
procedure genrules(lk : frequent k –itemset, am : frequent m–itemset)
f
A = f(m , 1)–itemsets am, j am, amg;
forall (am, 2 A) f
conf = support(lk) / support(am, );
if (conf minconf ) f
produceRule(am, ) (lk , am, ));
with confidence = conf and support = support(lk )
if (m , 1 > 1)
genrules(lk , am, );
1
1
1
1
1
g
g
g
1
1
(3) Filtern der Regeln Die Assoziationsregelverfahren generieren meist eine
große Anzahl von Regeln, welche für den Benutzer schwer überschaubar sind.
Folglich ist es angebracht, die Regeln nach ihrem ,,Interessegrad” zu filtern. Dieser Interessegrad kann von sehr unterschiedlicher Natur sein. So bietet es sich
22
beispielsweise an, die Regeln nach ihrem Konfidenzwert zu sortieren. Bei generalisierten bzw. quantitativen Assoziationsregeln kann man Regeln verwerfen,
wenn sie von anderen Regeln bereits mitabgedeckt werden. Der Verlust von
möglicherweise interessantem Detailwissen wird dabei allerdings in Kauf genommen. Eine detaillierte Beschreibung dieser Filtermethoden wird in 3.3.5 und 3.4.5
gegeben.
Ein alternativer Ansatz, die für den Benutzer interessanten Regeln zu finden, wird
in [KMR+ 94] beschrieben: Dort kann der Nutzer mit Hilfe von Templates interessante Regeln umschreiben, welche dann in den bestehenden Regeln gesucht
werden. Nachteilig ist hier jedoch, dass vor der Selektion zunächst alle Regeln erzeugt werden müssen. Eine Filterung schon während der Regelgenerierung wäre
weitaus kosteneffizienter. So untersuchen Srikant et al. in ihrem Aufsatz [SVA97],
inwieweit sich Contraints über die An- oder Abwesenheit von Artikelkombinationen in den Generierungsprozess integrieren lassen.
Die visuelle Unterstützung bei der Filterung der Regeln und dem allgemeinen
Überblick der Ergebnisse hat sich in vielen Data Mining Werkzeugen als sehr
hilfreich herausgestellt. In [KMR+ 94] wird beschrieben, wie man Regeln in Hypergraphen visualisieren kann. Ebenso unterstützen Darstellungen statistischer
Werte (Regelgrößen und –häufigkeiten) den Benutzer beim Finden interessanter
Muster.
3.1.3 Arten von Assoziationsregeln
Es ist sinnvoll, Assoziationsregeln nach den Attributarten, über denen sie erzeugt
werden, zu unterteilen. Regeln, die über boolschen Attributwerten gebildet werden (der Artikel ist in der Transaktion enthalten oder nicht), nennt man boolsche
Assoziationsregeln. Auf verschiedene Verfahren zur Bildung dieser Regeln wird
in Abschnitt 3.2 eingegangen. Oftmals ist es interessant zwischen den einzelnen Artikeln hierarchische Verwandtschaftsbeziehungen zu definieren. Solche
Taxonomien helfen in vielen Fällen bisher unentdeckte Regeln zu finden. Auf
einige Ansätze zur Generierung solcher generalisierten Assoziationsregeln wird
in Abschnitt 3.3 eingegangen. In der Praxis sind die Attributwerte jedoch meist
nicht von boolscher Natur. Regeln über quantitativen oder kategorischen Attributausprägungen bezeichnet man als quantitative Assoziationsregeln. Sie werden in
Abschnitt 3.4 vorgestellt.
3.2. Einfache boolsche Assoziationsregeln
23
3.2 Einfache boolsche Assoziationsregeln
Verfahren für boolsche Assoziationsregeln bilden Regeln über boolschen Attributausprägungen. Es wird also geprüft, ob der jeweilige Artikel in den Transaktionen
enthalten ist oder nicht. Verschiedene Verfahren zum Finden von boolschen Assoziationsregeln beschreiben die folgenden Abschnitte.
3.2.1 AIS
Das AIS–Verfahren wurde erstmals 1993 in [AIS93] vorgestellt und wird als einer
der ersten Algorithmen zum Finden von Assoziationsregeln betrachtet. Algorithmus 3.2.1 zeigt das Grundgerüst des Verfahrens.
Das Verfahren läuft so lange in einer Schleife, bis das frontier set keine Mengen
mehr enthält. Dem frontier set kommt hierbei eine besondere Rolle zu: Während
der Algorithmus die Datenbasis komplett durchläuft, wird jedes Tupel t einzeln
herausgenommen.
Nun wird für jede Menge f aus dem frontier set geprüft, ob sie in t enthalten
ist. Ist dies der Fall, so werden Erweiterungen von f generiert und in die Kandidatenmenge Cf eingefügt. Die Generierung dieser Kandidaten cf wird in einem
gesonderten Abschnitt besprochen. Die Häufigkeit jedes einzelnen Kandidaten
wird gezählt, damit diejenigen, die den min support erreichen, in die Menge L
der häufigen Artikelmengen aufgenommen werden können.
Am Ende eines jeden Durchgangs wird die Entscheidung getroffen, welche dieser Kandidaten in das frontier set des nächsten Durchgangs aufgenommen werden. Die Voraussetzungen, welche zur Bildung des neuen frontier sets zutreffen
müssen, werden später geklärt.
Generierung der Kandidaten cf 2 Cf
Bei der Generierung der Kandidaten geht das Verfahren nach der rekursiven Prozedur Extend vor. Die Sortierung nach Ij vermeidet dabei eine mehrfache Erzeugung derselben Artikelmengen.
Insgesamt werden also alle Artikelkombinationen in die Kandidatenmenge Cf
aufgenommen, die als häufig angenommen werden, so wie auch die rekursiven
Erweiterungen dieser Kandidaten. ,,Nicht häufig” geschätzte Artikelmengen werden zwar aufgenommen, aber nicht weiter expandiert. Sollten sich diese als ,,nicht
häufige” Artikelkombinationen angenommenen Mengen später doch als häufig erweisen, so wird ein weiterer Durchgang durch die Datenbasis nötig sein (dies wird
24
Algorithmus 3.2.1 Das AIS–Verfahren
L = ;; // the frequent itemsets
F = f;g; // the frontier set
while (F 6= ;) f
C = ;; // the candidate set
forall (t 2 D) f
forall (f 2 F ) f
if (f t) f
Cf = candidates that are extensions of f (contained in t)
forall (cf 2 Cf ) f
if (cf 2 C )
cf :count = cf :count + 1;
else f
cf :count = 0;
C = C + cf ;
g
g
g
F = ;;
forall (c 2 C ) f
if ( c:count
jDj > min support)
L = L + c;
if (c should be used as a frontier in the next pass)
F =F +c
g
g
in der Bestimmung des frontier sets näher untersucht).
Eine wichtige Frage stellt die Schätzfunktion dar, mit der man festlegt, ob eine
Artikelkombination als häufig angenommen werden soll.
Agrawal, Imielinsky und Swami benutzen in [AIS93] zur Schätzung die statistische Unabhängigkeitsannahme: Nimmt man an, dass die Menge X + Y eine
Erweiterung des frontier sets X ist und weiterhin Y = I1 ; I2; : : :; IK gegeben ist,
so berechnet sich der erwartete Support s wie folgt:
, c)
s = f (I ) f (I ) : : : f (Ik ) (xjDj
1
2
(3.3)
25
Prozedur 3.2.1 Extend
procedure Extend(X : itemset, t: tuple)
f
g
let Ij be such that 8Il 2 X; Ij Il
forall (Ik 2 t; Ik > Ij ) f
Add XIk to Cf .
if (XIK ) is expected to be frequent
Extend(XIk , t)
g
f (Ik ) kennzeichnet hier die relative Häufigkeit des Artikels Ik in der Datenbank
D. Die Variable x gibt die absolute Anzahl der Tupel in D an, die X enthalten. In
c ist die relative Tupelzahl enthalten, die im aktuellen Durchgang schon untersucht
wurde und X enthielt (aber noch nicht X + Y ).
,c als den aktuellen Support von X in der verbliebenen Datenbasis
Man kann xjDj
(
)
bezeichnen. Unter der Annahme statistischer Unabhängigkeit folgert man nun,
dass sich der erwartete Support für X + Y aus dem Produkt zwischen dem Support
von X und den einzelnen relativen Häufigkeiten der Artikel aus Y ergibt. X + Y
wird als häufig angenommen, wenn s den min support erreicht.
Bestimmung des frontier sets F
Am Ende eines jeden Laufes wird das frontier set für den nächsten Durchgang
bestimmt. Hier müssen nur diejenigen Mengen in das neue frontier set aufgenommen werden, die zwar als ,,nicht häufig” angenommen wurden, sich aber später
bei der Überprüfung doch als häufig erwiesen.
Dies begründet sich folgendermaßen: Wurde eine Menge X als ,,nicht häufig”
angenommen, wurden auch keine Erweiterungen X + Ik von X gebildet. Folglich
konnte auch keine Erweiterung X + Ik auf Häufigkeit überprüft werden. Trotzdem
können bestimmte Erweiterungen von X auch wieder häufig sein, da sich ja X
als häufig herausgestellt hat. Aus diesem Grund wird X in das frontier set F
eingefügt.
Mengen, die als ,,nicht häufig” angenommen wurden und sich bei der
Überprüfung auch als ,,nicht häufig” erwiesen, müssen nicht weiter untersucht
werden, da Erweiterungen X + Ik einer ,,nicht häufigen” Menge X keinen
größeren Support haben können als X selbst.
Andererseits muss auch keine Menge X eingefügt werden, die im letzten Durchgang als häufig angenommen wurde, da schon X und alle Erweiterungen von
26
X im letzten Durchgang überprüft wurden.
Dies wird durch die Prozedur 3.2.1
(EXTEND) gesichert.
Daher reicht es aus, nur diejenigen Mengen in das frontier set F aufzunehmen,
die zuvor als ,,nicht häufig” angenommen, aber bei der Überprüfung als häufig
erkannt wurden.
Beispiel Ein Beispiel soll die Generierung der Kandidaten und den Schätzprozess
verdeutlichen: Sei die Menge der verfügbaren Items I = fA; B; C; D; E; F g in
alphabetischer Weise sortiert und das frontier set bestehe momentan nur aus der
Artikelmenge F = fAB g. Für ein Tupel t = ABCDF aus der Datenbank werden die folgenden Artikelmengen generiert:
Menge
ABC
ABCD
ABCF
ABD
ABF
Erwartung
häufig
nicht häufig
häufig
nicht häufig
häufig
Aktion
expandiere weiter
nicht weiter expandieren
weitere Expansion nicht möglich
nicht weiter expandieren
weitere Expansion nicht möglich
Die Mengen ABCF und ABF wurden zwar als häufig angenommen, konnten
aber nicht weiter erweitert werden, da sich kein Artikel in t befindet, der größer
als F ist. Die Kombinationen ABCE und ABE wurden nicht untersucht, da der
Artikel E nicht in t enthalten ist. Die Kombination ABCDF (wie auch ABDF )
wurde nicht generiert, da ABCD (ABD) als “nicht häufig” geschätzt wurde. Aus
diesem Grund erzeugte die Expand-Prozedur keine Erweiterungen.
3.2.2 SetM
Das in [HS93] vorgestellte S ET M–Verfahren zeigt den Ansatz, das Finden von
Assoziationsregeln eng mit der Datenbanksprache SQL zu koppeln. So lässt sich
der komplette Algorithmus mit SQL–Befehlen beschreiben. [HS93] präsentiert
daher den Algorithmus auch in SQL. Um eine einheitliche Darstellung in dieser Arbeit zu gewährleisten, wird der das S ET M–Verfahren in Algorithmus 3.2.2
durch Pseudocode notiert.
Im Gegensatz zu AIS trennt S ET M die Generierung der Kandidaten von der
Berechnung des Supports. In jedem Durchgang sucht er pro Transaktion die
häufigen Artikelmengen aus dem vorherigen Durchlauf und generiert daraus die
1–Erweiterungen. Diese werden in Ct gespeichert. Analog dazu werden in C k die
27
Algorithmus 3.2.2 S ET M
L1 = ffrequent 1-itemsetsg;
L1 = ffrequent 1-itemsets together with the TIDs
in which they appear, sorted on TIDg;
k = 2;
while (Lk,1 6= ;) f
C k = ;;
forall (T 2 D) f
Lt = fl 2 Lk,1 j l:TID = t:TIDg; // frequent (k , 1)-itemsets in T
forall (lt 2 Lt ) f
Ct = 1-extensions of Lt contained in T ; // candidates in T
C k = C k + f< t:TID; c > j c 2 Ctg;
g
g
g
Sort C k on itemsets;
Delete all itemsets c 2 C k for which c:count < min support giving Lk ;
Lk = f< l:itemset; count of l in Lk > j l 2 Lk g; // with previous step
Sort Lk on itemsets;
k = k + 1;
S
Result = k Lk
Kandidaten plus ihrer zugehörigen TID (Transaktionsidentifikation) mitgeführt.
Später wird das Zählen des Supports durch das Sortieren und Zusammenfassen
dieser Struktur ermöglicht.
Offensichtlich liegt der Nachteil dieses Verfahrens in der Größe der Kandidatenmenge C k , da jeder Kandidat aus C k so viele Einträge enthält, wie es Transaktionen mit dieser Artikelmenge gibt. Das Sortieren der Mengen Lk und C k bedeutet
ein weiteres Performanzproblem, da es in jedem Durchgang ausgeführt werden
muss.
Auf der anderen Seite kann S ET M einfach (in SQL) implementiert werden. Auf
diese Weise lässt sich relativ schnell ein Assoziationsregel–Verfahren in SQLDatenbanken implementieren.
3.2.3 Die Apriori–Klasse
Den Algorithmen der A PRIORI–Klasse liegt allen die gleiche Idee zu Grunde, die
erstmals in [AS94a] vorgestellt wurde. Hier sollen zuerst das Orginalverfahren
28
und dann seine Modifikationen beschrieben werden.
3.2.3.1 Apriori
Ähnlich zu S ET M berechnet der A PRIORI–Algorithmus [AS94a] sukzessive die
häufigen Artikelmengen mit 1; 2; 3; : : : n Artikeln.
Algorithmus 3.2.3 A PRIORI
k = 2;
while (Lk,1 6= ;) f
Ck = new candidates of size k generated from Lk,1 ;
forall (T 2 D) f
Ct = subset(Ck ; t);
forall (candidates c 2 Ct) f
c.count++;
g
g
g
Lk = all candidates in Ck with minimum support;
k = k + 1;
S
Result = k Lk
Dabei geht das Verfahren nach einem einfachen Schema vor: Zunächst werden
die häufigen Einzelartikel bestimmt. In jedem weiteren k –ten Durchgang werden dann Kandidaten für die k -elementigen häufigen Artikelmengen Lk generiert.
Hierfür dienen die schon berechneten (k , 1)-elementigen häufigen Artikelmengen Lk,1 . Im Anschluss daran wird der Support der Kandidaten in einem kompletten Durchlauf durch D gezählt. Diejenigen Kandidaten, die den min support
erreichen, werden in Lk aufgenommen.
Generierung der Kandidaten
Die Prozedur aprioriGeneration beschreibt die Bildung der Kandidaten im k -ten
Schritt: Wie man sieht, erzeugt die Prozedur aus Lk,1 eine Obermenge von Lk .
Die Korrektheit wird im Folgenden bewiesen.
Beispiel Es seien die häufigen Artikelmengen L3 gegeben: f(Milch Brot Cola)
(Milch Brot Fanta) (Milch Cola Fanta) (Milch Cola Twix) (Brot Cola Fanta)g.
Nach dem Join enthält die Kandidatenmenge C4 die beiden Elemente f(Milch
Brot Cola Fanta) (Milch Cola Fanta Twix)g. Da die Teilmenge (Milch Fanta
Twix) nicht in L3 enthalten ist, wird (Milch Cola Fanta Twix) im Prune-Schritt
29
Prozedur 3.2.2 aprioriGeneration
procedure aprioriGeneration (Lk,1 )
f
g
// join Lk,1 ./ Lk,1 so that each (k-1)–subset I 0 I is contained in Lk,1
Ck = ffi1; i2; : : :; ik g j 81 j k : fi1; i2; : : :; ik g , ij 2 Lk,1 g
wieder entfernt. Somit bleibt nur (Milch Brot Cola Fanta) in der Kandidatenmenge erhalten.
Korrektheit des Algorithmus
Der A PRIORI–Algorithmus arbeitet korrekt, wenn alle häufigen Itemmengen Lk
berechnet werden. Dies hängt aber unmittelbar davon ab, ob die Berechnung der
Kandidatenmenge richtig erfolgt. Zu zeigen ist also, dass Ck Lk gilt.
Zum Beweis nützt man die Eigenschaft, dass jede Teilmenge einer häufigen Itemmenge wieder eine häufige Itemmenge sein muss. Nun erweitert man jede Itemmenge aus Lk,1 um ein Item. Iteriert man die Expansion dieser Itemmenge für
jedes mögliche Item, so erhält man für jede Itemmenge aus Lk,1 eine Menge
k–elementiger Obermengen. Aus diesen Obermengen können dann diejenigen
Itemmengen gelöscht werden, deren beliebige (k , 1)-Teilmengen nicht in Lk,1
liegen. Die Obermengen-Eigenschaft von Lk bleibt dabei erhalten, da keine Menge gelöscht wird, die in Lk liegen könnte.
Genau diese Vorgehensweise beschreibt der Algorithmus aprioriGeneration: Der
Join-Schritt entspricht der Expansion der Itemmengen um alle weiteren möglichen
Items. Die Bedingung pk,1 < qk,1 sichert lediglich die Vermeidung von redundanten Duplikaten. Das Entfernen der Itemmengen, welche keine (k , 1)elementigen Teilmengen in Lk besitzen, wird im Prune-Schritt beschrieben. Folglich liefert aprioriGeneration eine Obermenge von Lk und es gilt Ck Lk .
3.2.3.2 AprioriTID
Der komplette Datenbankdurchlauf pro Iteration stellt sich im APRIORI–
Verfahren als sehr aufwendig heraus. Um dieses Problem zu umgehen, verwendet A PRIORI TID [AS94a] eine alternative Datenstruktur bei der Berechnung der
häufigen Artikelmengen: Nachdem die Kandidaten wie bei A PRIORI generiert
wurden, benutzt man nun die Menge C k zur Berechnung des Supports. Diese
Menge wird zu Anfang des Algorithmus mit Hilfe eines Datenbankscans aufgebaut und pro Iteration an die Entwicklung angepaßt. Dabei ist C k eine Men-
30
ge mit Tupeln von der Form < TID; fXk g >, so dass jedes einzelne Xk eine
möglicherweise häufige k-Artikelmenge ist, die in der Transaktion mit der Nummer TID enthalten ist.
Beispiel Sei die Datenbank D = f[1: A C D], [2: B C E], [3: A B C E], [4: B
E]g gegeben. Die erste Zahl jedes Eintrags symbolisiert die TID. Der minimale
Support liegt bei 2 Transaktionen. Für k = 1 enthält C 1 also die vollständige
Datenbank D in einer alternativen Speicherstruktur. Mit steigendem k schrumpft
jedoch die Größe von C k . Folglich ist C 1 und C 2 wie in Tabelle 3.1 gegeben. Die
Generierung von C j (j > 2) erfolgt analog.
TID
1
2
3
4
C
1
Einträge
fAg, fCg, fDg
fBg, fCg, fEg
fAg, fBg, fCg, fEg
fBg, fEg
TID
1
2
3
4
C
2
Einträge
fA Cg
fB Cg, fB Eg, fC Eg
fA Bg, fA Cg, fA Eg
fB Cg, fB Eg, fC Eg
fB Eg
Abbildung 3.1: Beispiel für C 1 und C 2
In Algorithmus 3.2.4 ist eine detaillierte Darstellung des Verfahrens gegeben.
3.2.3.3 AprioriHybrid
Während der A PRIORI–Algorithmus durch die Datenbankläufe in jeder Iteration
Performanzschwächen aufweist, benötigt A PRIORI TID in der Anfangsphase extrem viel Arbeitsspeicher. Das A PRIORI H YBIRD–Verfahren [AS94a] kombiniert
nun beide Ansätze mit dem Ziel, die gegenseitigen Schwächen auszugleichen.
Es ist nämlich nicht zwingend erforderlich, denselben Algorithmus für den vollständigen Data Mining Prozess einzusetzen. A PRIORI und A PRIORI TID verwenden die gleiche Prozedur zur Kandidatengenerierung und arbeiten daher mit den
gleichen Artikelmengen. Dies macht es möglich, im Lauf “on-the-fly” zwischen
den beiden Verfahren zu wechseln.
In der Anfangsphase ist es sinnvoll, den speicher–sparsamen A PRIORI zur Generierung der häufigen Artikelmengen Lk einzusetzen. Sobald die Struktur C k aber
in den Arbeitsspeicher paßt, erweist sich ein Umschalten auf den A PRIORI TID
als erfolgversprechend. Am Ende eines jeden Durchlaufs wird mit Formel 3.4
geschätzt, ob C k in den Arbeitsspeicher gepasst hätte.
31
Algorithmus 3.2.4 A PRIORI TID
C 1 = database D;
k = 2;
while (Lk,1 6= ;) f
Ck = new candidates of size k generated from Lk,1;
C k = ;;
forall (T 2 C k,1 ) f
// determine candidate itemsets in Ck contained in
// the transaction with identifier T:TID
Ct = fc 2 Ck j (c , c[k]) 2 t.set-of-itemsets ^
(c , c[k , 1]) 2 t.set-of-itemsetsg;
Increment the count of all candidates in Ct;
if (Ct 6= ;)
C k = C k + < t:TID; Ct >;
g
g
k = k + 1;
S
Result = k Lk
2
3
X
4
support(c)5 +
c2Ck
number of transactions
(3.4)
Wenn in der aktuellen Iteration weniger häufige Artikelmengen erzeugt wurden
als in der vorherigen und die Menge C k nach dem obigen Schätzwert in den Speicher gepasst hätte, dann wird in den A PRIORI TID gewechselt. Die zusätzliche
Addierung der Transaktionenzahl (number of transactions) soll einen Wechsel
vermeiden, wenn C k im aktuellen Durchlauf in den Speicher gepaßt hätte, aber
C k+1 in der nächsten Iteration nicht.
Es ist allerdings zu beachten, dass der Wechsel zwischen A PRIORI und A PRIO RI TID teuer ist, da hierfür die komplette Datenstruktur C k erzeugt werden muss.
3.2.3.4 OCD
Das OCD–Verfahren [MTV94] entstand relativ gleichzeitig mit dem APRIORI–
Algorithmus und beschreibt grundsätzlich die gleiche Vorgehensweise. OCD eli-
32
miniert ebenfalls unmögliche Kandidaten vor dem Datenbankdurchlauf, die apriori nicht häufig sein können.
Der Unterschied liegt im Wesentlichen in den Feinheiten der Kandidatengenerierung: So definieren sich die (k+1)–Artikelmengen, welche als Kandidaten in
Frage kommen, wie folgt:
Ck
+1
=
fX I j jX j = k + 1 ^ X includes s + 1 members of Lk g
(3.5)
Da hier zu viele Artikelmengen generiert werden, bieten die Autoren in [MTV94]
eine kleinere Kandidatenmenge Ck0 +1 an:
Ck0
+1
=
fX [ X 0 j X; X 0 2 Lk ^ jX \ X 0 j = k , 1g
(3.6)
Es wird also eine Obermenge von Kandidaten zu der oben vorgestellten A PRIORI–
Kandidatengenerierung erzeugt.
Beipiel Sei L3 = fABC; ABD; ACD; ACE; BCDg gegeben. A PRIORI würde
nur C4 = fABCDg als Kandidaten erzeugen, während OCD die Kandidatenmenge C40 = fABCD; ABCE; ACDE g generieren würde.
Als eine Optimierung ihres Verfahrens schlagen Mannila et al. in [MTV94] vor,
Kandidaten verschiedener Größen zusammen zu generieren und diese dann gemeinsam in einem einzigen Datenbankdurchlauf zu überprüfen. So wird die zeitintensive Anzahl der Datenbankdurchläufe minimiert. Bei der Generierung der
Kandidaten verfolgt OCD dabei einen weiteren Ansatz:
Es sei die häufige Artikelmenge Fs gegeben. Anstelle jede Kandidatengruppe
+j einzeln aus der vorherigen Kandidatengruppe Cs+j ,1 zu generieren, werden alle Mengen Cs0 +1 ; : : :; Cs0 +c gleichzeitig aus Vereinigungen von Cs –Paaren
berechnet. Die Kandidatenmenge Cs+j berechnet sich aus Cs0 +j , indem für je des X 2 Cs0 +j getestet wird, ob es genau s+s j Mengen aus Ls enthält. Diese
Methode wird von den Autoren [MTV94] als c-extension bezeichnet.
Cs
Beispiel Sei L2 = fAB; AC; BC; AD; BD; CD; AE; FG; BGg als häufige 2er–
Artikelmenge
gegeben. Es lässt sich nun leicht errechnen, dass L5 = ; sein muss,
5
da 2 = 10 und damit größer als jL2 j = 9 ist. Damit lassen sich keine Kandidaten
für L5 generieren, da jedes X 2 C5 in 10 Artikelmengen von L2 enthalten sein
müsste.
Es ist leicht ersichtlich, dass diese Methode für kleine Kandidatengruppen sehr
vorteilhaft ist, da durch die Zusammenfassung Datenbankdurchläufe eingespart
werden können.
33
3.2.4 Partition
Das PARTITION –Verfahren [SON95] verfolgt den Ansatz, die Anzahl der kompletten Datenbankdurchläufe zu minimieren. So kann es garantieren, dass zum
Finden aller häufigen Artikelmengen nicht mehr als zwei vollständige Datenbankscans nötig sind. Dabei teilt sich der Algorithmus in zwei Phasen auf:
1. Phase In der ersten Phase wird die gesamte Datenbasis D in etwa gleich große
logische Partitionen aufgeteilt. Diese Partitionen dürfen sich nicht überlappen und
beinhalten Transaktionen aus D. Auf diese Weise wird D komplett durch die Partitionen abgedeckt. Nun werden für jede einzelne Partition die dafür häufigen Artikelmengen generiert. Die im Kontext dieser Partition häufigen Artikelmengen
werden als lokal häufige Artikelmengen bezeichnet. Am Ende der ersten Phase
werden die lokal häufigen Artikelmengen aller Partitionen miteinander vermischt.
Die daraus resultierende Gesamtmenge markiert die Kandidaten für den Berechnungslauf in der zweiten Phase.
2. Phase Mit den in der ersten Phase gewonnenen Kandidaten kann die zweite
Phase begonnen werden. Ein weiterer Datenbankdurchlauf klärt, welche der Kandidaten den min support erreichen und welche nicht. Im Kontext der gesamten
Datenbank spricht man dann von global häufigen Artikelmengen. Die grundlegende Idee dieses Verfahrens besteht also darin, dass jede global häufige Artikelmenge in mindestens einer Partition lokal häufig sein muss.
Prozedur 3.2.3 generateCount(C G: globalCandidateSet, p: databasePartition)
procedure generateCount(C G: globalCandidateSet, p: databasePartition)
f
g
forall (1-itemsets)
generate the TID-list
for (k = 2; CkG 6= ;; k ++) f
forall (k -itemset c 2 CkG ) f
templist = c[1]:tidlist \ c[2]:tidlist \
c:count = c:count + jtemplistj;
g
: : : c[k]:tidlist;
g
Wahl der Partitionsgröße
Von entscheidender Bedeutung ist die richtige Wahl der Partitionsgröße. Arbeitet man mit großen Partitionen, so verringern sich die Datenbankzugriffe und der
Mischaufwand in der 1. Phase. Allerdings ist mit einem vermehrten Swap-Zugriff
34
zu rechnen, wenn die Partition nicht mehr in den Arbeitsspeicher passt. Zu kleine
Partitionen erhöhen aber wieder unötig den Zugriff auf die Datenbank. Folglich
sollte der Umfang einer Partition gerade so groß gewählt werden, dass sie komplett im Arbeitsspeicher untergebracht werden kann.
Algorithmus 3.2.5 PARTITION
P = partition the Database(D);
n = number of partitions;
// Phase 1
for (i = 1; i n; i++) f
readPartition(pi 2 P );
Li = generateFrequentItemsets(pi);
g
// now merge
for (i = 2; Li 6= ;; j = 1; 2; : : : ; n; i++)
CiG = Sj=1;2;:::;n Lji ;
// Phase 2
for (i = 1; i n; i++) f
readPartition(pi 2 P );
forall (candidates c 2 C G )
generateCount(c; pi);
g
g
Result = fc 2 C G jc:count min
supportg;
Die globale Kandidatenmenge
Vor Eintritt in die 2. Phase wird eine globale Kandidatenmenge durch das Mischen der lokal häufigen Artikelmengen erzeugt. Die Größe dieser Menge ist sehr
wichtig für die Effizienz des Algorithmus, da sie vollständig während der 2. Phase
benötigt wird. Dennoch lassen sich keine genauen Aussagen treffen. Die jeweiligen Charakteristika der Daten und der benutzerdefinierte Support haben nämlich
einen großen Einfluss auf die Generierung. Als obere Schranke lässt sich jedoch
Gleichung 3.7 angeben.
Die Anzahl der Partitionen ist hier mit n gegeben und jcj als die Anzahl der Elemente in der Artikelmenge c. Versuche in [SON95] haben jedoch gezeigt, dass
die resultierende Kandidatenmenge erheblich kleiner ausfällt.
j globalCandidates j n maxfjcj j c 2 localCandidatesg
(3.7)
35
Die verwendeten Notationen sind wie folgt zu verstehen: CiG sind die Kandidaten
für die global häufigen i–Artikelmengen. Lji sind die lokal häufigen Artikelmengen in der Partition pj und C G ist die Menge der globalen Kandidaten.
Die Prozedur generateFrequentItemsets(pi ) erzeugt die lokal häufigen Artikelmengen. Hierfür kann ein beliebiger Algorithmus, wie zum Beispiel A PRIORI
benutzt werden.
36
3.3 Generalisierte Assoziationsregeln
Oftmals lassen sich Artikel logisch gruppieren oder auch Beziehungen zwischen
einzelnen Artikeln definieren. Die Verwendung von Taxonomien kann zu wesentlich interessanteren Ergebnissen führen.
3.3.1 Einführung
Eine Taxonomie kennzeichnet eine ist–ein–Beziehung zwischen zwei Artikeln.
Abbildung 3.2 zeigt den Ausschnitt einer Taxonomie im Kontext eines Kaufhauses. Hier gilt beispielsweise: H–Milch ist–eine Milch oder Brot ist–ein Lebensmittel.
Lebensmittel
Milch
H-Milch
Brot
Vollmilch
Weißbrot
Vollkornbrot
Elektronik
Computer
Apple Mac
HiFi
PC
CD-Player
Receiver
Abbildung 3.2: Beispiele für Kaufhaus-Taxonomien
In der realen Welt ist meist eine Vielzahl von Taxonomien zwischen Artikeln gegeben. So können Taxonomien über Preiskategorien (billig, teuer, Sonderangebote, : : :) oder auch Warengruppen (Lebensmittel, Kleidung, : : :) gebildet werden. Multiple Taxonomien werden in der Regel als gerichtete, azyklische Graphen
(DAG) modelliert.
Selbstverständlich bedeutet die Erstellung solcher Strukturen einen Mehraufwand
3.3. Generalisierte Assoziationsregeln
37
für den Benutzer, der diese Beziehungen zuerst manuell definieren muss. Trotzdem kann die Einbeziehung von Taxonomien in den Data Mining Prozess vorteilhaft sein:
Bei einer großen Anzahl von Artikeln können viele Artikel den min support
nicht mehr erreichen, wenn es zu wenig Transaktionen gibt, die diese unterstützen. Dies wäre aber sehr wohl möglich, wenn man die vorhandenen
Artikel hierarchisch gruppieren würde.
Beispiel: [H–Milch ) Weißbrot] erreicht den min support nicht mehr, aber
[Milch ) Weißbrot], da [Vollmilch ) Weißbrot] ausreichend häufig vorhanden ist.
Taxonomien können auf einfache Weise zum Filtern von redundanten und
uninteressanten Regeln benutzt werden. Auf die Filterung wird in Abschnitt
3.3.5 eingegangen werden.
Definition
Sei I = fi1; i2 ; : : :; im g eine Menge von Literalen, auch Artikel (items) genannt.
Sei weiter T ein gerichteter azyklischer Graph auf diesen Literalen. Eine Kante
in T repräsentiert eine ist-ein–Beziehung, so dass T die Menge der Taxonomien
repräsentiert. Gibt es in T eine Kante von p nach c, so nennt man p den Vater
(parent) von c und c ein Kind (child) von p. Weiter nennt man x^ einen Vorfahren
(ancestor) von x, wenn es einen Pfad von x^ nach x gibt. x^ ist ein direkter Vorfahre
(close ancestor) von x, wenn es keinen weiteren Artikel y gibt, so dass gilt: y ist
Vorfahre von x und x^ ist Vorfahre von y . Vorfahren haben generell die gleiche
Anzahl von Artikeln wie ihre Kinder.
Sei D die Menge der zu untersuchenden Transaktionen T (T I ). Eine Transaktion supportet einen Artikel x 2 I , wenn x in T enthalten ist oder ein Vorfahre
von x. Folglich supportet T eine Artikelmenge X I , wenn T jeden Artikel aus
x supportet.
Eine generalisierte Assoziationsregel (generalized association rule) ist eine Implikation der Form X ) Y (X I , Y I , X \ Y = ;), so dass kein Artikel
aus Y ein Vorfahre eines Artikel aus X ist.
Anmerkungen zu Support und Konfidenz
Wenn eine Menge fx; y g den minimalen Support erreicht, dann wird ersichtlicherweise auch der min support von fx; y^g; fx
^; y g und fx
^; y^g gehalten. Andererseits gilt dies nicht generell für die Konfidenz: Erreicht eine Regel X ) Y den
min support und die min conf, so kann man weiter die minimale Konfidenz nur
für X ) Y^ garantieren.
38
Ebenso ist es wichtig anzumerken, dass sich der Support eines Artikels nicht aus
der Summe seiner Kinder berechnen lässt. Mehrere Kindartikel können in einer einzelnen Transaktion enthalten sein und so den Support für den Vaterartikel
beeinflussen. Aus diesem Grund ist es auch nicht möglich, den Support in den
oberen Hierarchieebenen aus dem Support der Artikel in den Blättern zu berechnen.
Die Abschnitte 3.3.2, 3.3.3 und 3.3.4 stellen Verfahren zur Berechnung häufiger
Artikelmengen über Taxonomien vor. Aus diesen Mengen können dann, analog zu
den einfachen Assoziationsregeln, die Regeln generiert werden. Durch die mannigfaltigen Verwandtschaftsbeziehungen werden viele redundante und uninteressante Regeln generiert. Abschnitt 3.3.5 zeigt, wie man mit Hilfe von Taxonomien
uninteressante Regeln filtern kann.
3.3.2 Basic
Die zentrale Fragestellung beim Finden von häufigen Artikelmengen ist, ob eine
Transaktion einen Artikel supportet oder nicht. Um die Existenz von Taxonomien
erweitert, ergibt sich nun die Frage, ob eine Transaktion einen Artikel oder einen
Vorfahren des Artikels supportet.
Folglich liegt es nahe, jede Transaktion T um die Vorfahren der Artikel in T zu
erweitern. Dann lässt sich, leicht verändert, der bekannte A PRIORI–Algorithmus
zum Finden von generalisierten Assoziationsregeln verwenden. Dies ist der Ansatz des BASIC-Verfahrens [SA95] in Algorithmus 3.3.1.
Algorithmus 3.3.1 BASIC
L1 = frequent 1-itemsets; // includes items at any level
k = 2;
while (Lk,1 6= ;) f
forall (T 2 D) f
Add all ancestors of each item in T to T , removing duplicates;
Increment the count of all candidates in Ck that are contained in T ;
g
g
k = k + 1;
S
Result = k Lk ;
Zu Beginn werden die häufigen 1-Artikelmengen berechnet. Zu beachten ist, dass
39
diese Artikel aus jeder beliebigen Hierarchiestufe stammen können.
Danach folgt BASIC der Grundstruktur des A PRIORI–Verfahrens: Iterativ werden
zuerst die Kandidaten aus den häufigen Artikelmengen des vorherigen Durchgangs berechnet. Zur Bestimmung, welche Kandidaten wirklich häufig sind, wird
danach jede Transaktion der Datenbank, erweitert durch die Vorfahren, durchlaufen. Sobald keine häufigen Artikelmengen mehr gefunden werden können, bricht
der Algorithmus ab.
3.3.3 Cumulate
Das C UMULATE–Verfahren [SA95] entsteht im Wesentlichen aus am BASIC–Algorithmus, nimmt jedoch einige Optimierungen vor.
1. Filtern der Vorfahren: Der Transaktion werden nur bestimmte Vorfahren
der Artikel zugefügt. So müssen nur Vorfahren in die Transaktion eingefügt
werden, die in mindestens einer Kandidatenmenge enthalten sind.
Darüber hinaus ist es nicht nötig, die ursprünglichen Artikel in einer Transaktion zu behalten, wenn sie nicht in der Kandidatenmenge enthalten sind.
Beispiel: Sei eine Taxonomie wie in Abbildung 3.2 gegeben und fMilch,
Weißbrotg die einzige zu überprüfende Kandidatenmenge. Nun kann man
im Taxonomiebaum die Artikel H–Milch und Vollmilch durch den übergeordneten Artikel Milch austauschen. Folglich wird den Transaktionen nur
noch Milch hinzugefügt. Die Artikel Vollmilch und H–Milch würden aus
den Transaktionen entfernt werden.
2. Vorberechnung der Vorfahren: Anstatt jedesmal den Taxonomiegraphen
zu durchwandern, können zur Ermittlung der Vorfahren auch im Voraus berechnete Tabellen benutzt werden. In diesen Tabellen stehen nur Vorfahren,
die auch benötigt werden (siehe Optimierung 1).
3. Wegstreichen von Mengen, die einen Artikel und seinen Vorfahren enthalten: Die beiden folgenden Lemmas zeigen die Korrektheit dieser Optimierung:
Lemma 1 Der Support für eine Artikelmenge X , die sowohl den Artikel x
als auch seinen Vorfahren x^ enthält, ist der gleiche wie der Support für die
Artikelmenge X , fx^g.
40
Beweis Es ist leicht ersichtlich, dass jede Transaktion, die X supportet,
auch X , x
^ unterstützt, da X , x
^ X ist. Nach Definition supportet jede
Transaktion, die x unterstützt, auch x^. Folglich supportet jede Transaktion,
die X , x^ unterstützt, auch X .
Lemma 2 Wenn Lk , eine Menge von häufigen k –Artikelmengen, keine
Menge enthält, die sowohl den Artikel, wie auch seinen Vorfahren enthält,
dann wird die Kandidatengenerierung (siehe Seite 29) keine Menge produzieren, die sowohl den Artikel als auch den Vorfahren beinhaltet.
Beweis Man nehme an, dass die Prozedur zur Kandidatengenerierung doch
einen Kandidaten X erzeugt, der sowohl x als auch seinen Vorfahren x^
enthält. Sei X 0 eine Teilmenge von X mit k Artikeln, die x und x^ enthält.
Da X 0 nicht im Prune–Vorgang der Kandidatengenerierung entfernt worden
ist, muss X 0 in Lk enthalten sein. Dies ist aber ein Widerspruch zu der
Behauptung, dass keine Artikelmenge in Lk sowohl x als auch x^ enthält.
Das erste Lemma zeigt, dass keine Mengen gezählt werden müssen, die
den Artikel und seinen Vorfahren zusammen enthalten. Diese Erkenntnis
wird im Algorithmus beim Löschen aller 2er Mengen, die Artikel und Vorfahre beeinhalten, verwendet. Im zweiten Lemma wird gezeigt, wie dieser Schritt das Generieren von Kandidatenmengen mit Artikel–Vorfahren–
Kombination im weiteren Iterationslauf des Algorithmus verhindert. Die
Folge ist offensichtlich eine Reduktion der Kandidatenanzahl, ohne die
Vollständigkeit zu verlieren.
Die oben genannten Optimierungen sind im Algorithmus 3.3.2 mit Kommentaren
gekennzeichnet.
3.3.4 EstMerge
Der EST M ERGE –Algorithmus [SA95] basiert auf dem vorgestellten CUMULATE –
Verfahren, weist jedoch wesentliche Optimierungen auf. Folgende Überlegungen
sollen diese Optimierungen motivieren:
Stratifizierung
Man nehme eine Taxonomie wie in Abbildung 3.2 an. Es sei also Lebensmittel
ein Vater von Milch und Milch wiederum ein direkter Vorfahre von Vollmilch. Errechnet man nun, dass fLebensmittel, Computerg den min support nicht erreicht,
dann kann man daraus schließen, dass fMilch, Computerg oder fVollmilch, Computerg den min support ebenfalls nicht erfüllen können. Aus diesem Grund ist es
Algorithmus 3.3.2 C UMULATE
Compute T , the set of ancestors of each item, from T ;
k = 2;
while (Lk,1 6= ;) f
if (k = 2) f
Delete any candidates in C2 that consists of
an item and its ancestor;
// Opt. 3
41
// Opt. 2
g
Delete all items in T that are not present in any
of the candidates in Ck ;
// Opt. 1
forall (T 2 D) f
forall (x 2 T )
Add all ancestors of x in T to T ;
Remove any duplicates from T ;
Increment the count of all candidates in Ck that are contained in T ;
g
g
k = k + 1;
S
Result = k Lk ;
geschickt, zunächst die Supportberechnung in höheren Hierarchien durchzuführen
und die Erkenntnisse über den Support in die tieferen Ebenen zu propagieren.
Eine Ad–hoc–Implementierung dieser stratifizierenden Vorgehensweise würde also zuerst im Taxonomiegraphen die Artikel der Tiefe 0 (Artikel ohne Vorfahren)
berechnen. Die Nachfahren derjenigen Artikel, die keinen minimalen Support
besitzen, würde man dann entfernen, da sie den minsupport ebenfalls nicht erreichen können. Iterativ müsste der Algorithmus nun die Artikel der Tiefe 1; 2; : : :
in gleicher Weise betrachten. Um die Datenbankzugriffe zu minimieren, könnte
man Artikel mehrerer Hierarchiestufen zusammenfassen und in einem Durchgang
berechnen. Srikant und Agrawal beschreiben diese Implementierung in dem Algorithmus S TRATIFY [SA95].
Schätzen des Support
Eine weitere Idee zur Optimierung der Artikelmengenberechnung stellt das Schätzen der Kandidaten dar. Mit Hilfe einer Beispielmenge DS D wird geschätzt,
ob die Kandidaten im aktuellen Durchgang den Support erreichen. Die als häufig
geschätzten Artikelmengen werden ebenso gezählt wie diejenigen Mengen Ck0 , die
42
zwar nicht als häufig geschätzt wurden, aber deren Eltern häufig sind. Allerdings
schließt man die Nachfahren der Mengen aus Ck0 von der Supportberechnung aus.
Sollten sich später einige Mengen aus Ck0 doch als häufig herausstellen, so werden
die Nachfahren dieser Mengen in Ck00 gesammelt und in einem extra Durchgang
überprüft. Dadurch bleibt die Vollständigkeit erhalten.
Beispiel Es sei die Taxonomie wie in Abbildung 3.2 gegeben und der minimale
Support liege bei 6%. Die Tabelle in Abbildung 3.3 zeigt den Support einiger
Kandidaten.
Support aus DS
Kandidaten
fLebensmittel, Computerg
fBrot, Computerg
fWeißbrot, Computerg
8%
5%
1%
wirklicher Support aus D
Szenario A Szenario B
7%
9%
5%
8%
Abbildung 3.3: Beispiele Supportschätzung
Man kann erkennen, dass nur die Artikelmenge fLebensmittel, Computerg als
häufig geschätzt wird. Trotzdem muss zusätzlich noch fBrot, Computerg in
die Kandidatenmenge aufgenommen werden, da zu diesem Zeitpunkt nicht sicher ist, ob fLebensmittel, Computerg häufig ist (Brot ist direkter Nachfahre
von Lebensmittel). In Szenario A erweist sich zwar fLebensmittel, Computerg
als häufig, aber fBrot, Computerg nicht. Daher muss fWeißbrot, Computerg
nicht in einem extra Durchlauf berechnet werden, wie es in Szenario B der Fall
wäre. Hier erreicht fBrot, Computerg nämlich den minimalen Support; folglich
wird fWeißbrot, Computer g der Menge Ck00 zugefügt und im extra Durchgang
berücksichtigt.
Anstelle die Kandidaten aus Ck00 in einem separaten Durchgang zu zählen, ist es
sinnvoller, diese mit den Kandidaten Ck+1 im nächsten Iterationsschritt zu untersuchen. Da man dann allerdings noch nicht weiß, welche Artikelmengen aus Ck00
häufig sind (diese werden nämlich bei der Generierung von Ck+1 benötigt), nimmt
man zur Erzeugung von Ck+1 einfach alle Mengen aus Ck00 als häufig an.
Die Zusammenführung der oben genannten Optimierungen wird im Verfahren
EST M ERGE (Algorithmus 3.3.3) dargestellt. Die Modifikationen in C UMULA TE können hier ebenfalls eingesetzt werden, auch wenn sie aufgrund der Übersichtlichkeit weggelassen wurden.
43
Algorithmus 3.3.3 EST M ERGE
Generate DS , a sample of the database, in the first pass;
k = 2;
C100 = ;;
while (Lk,1 6= ; or Ck00,1 6= ;) f
Ck = new candidates of size k generated from Lk,1 [ Ck00,1;
Estimate the support of the candidates in Ck by making a pass over DS ;
Ck0 = candidates in Ck that are expected to have min support and
candidates all of whose parents are expected to have min support;
Find the support of the candidates in Ck0 [ Ck00,1 by making a pass over D;
Delete all candidates in Ck whose ancestors (in Ck0 ) do not have min support;
Ck00 = remaining candidates i Ck that are not in Ck0 ;
Lk = all candidates in Ck0 with min support;
Add all candidates in Ck00,1 with min support to Lk,1
k = k + 1;
g
S
Result = k Lk ;
3.3.5 Filtern der interessanten Regeln
Die generierten Regeln können nach einem in [SA96] vorgestellten Interessemaß
eingeteilt und somit gefiltert werden. Die Vorgehensweise soll mit Hilfe eines
kleinen Beispiels eingeführt werden:
Beispiel Es sei die Regel Lebensmittel ) Computer (Support 8%, Konfidenz
70%) gegeben. Nach dem Taxonomiegraphen in Abbildung 3.2 ist Lebensmittel
Vater von Brot. Nimmt man an, dass Brot etwa 1=4 des gesamten Lebensmittelverkaufs ausmacht, so würde man erwarten, dass die Regel Brot ) Computer
2% Support und 70% Konfidenz innehält. Wenn also die Werte des Supports
und der Konfidenz nahe bei diesen Werten liegen, so kann die Regel Brot )
Computer als uninteressant betrachtet werden.
Im Weiteren wird eine formale Definition des Interessemaßes gegeben, mit dessen
Hilfe der Benutzer Regeln filtern kann. Ein einzustellender Parameter R steuert
dabei die Stärke der zu filternden Regeln.
Erwarteter Support
Sei die Regel X ) Y und Z = X [ Y gegeben. Sei mit EZ^ [Pr(Z )] der erwartete
Support von Z definiert, wenn der Support Pr(Z^ ) des Vorfahrens Z^ bekannt ist.
Weiter sei Z = fz1; : : : ; zn g und
44
g f
j n, so dass z^i ein Vorfahre von zi ist.
= z^1 ; : : :; z^j ; z^j +1 ; : : :; z^n , 1
Dann definiert sich der erwartete Support von Z bzgl. des bekannten Supports
von Z^ wie folgt:
Z^
(z )
Pr(zj ) Pr(Z^)
EZ [Pr(Z )] = Pr
:
:
:
Pr(^z )
Pr(^z )
^
1
j
1
(3.8)
Erwartete Konfidenz
Zum erwarteten Support kann analog die erwartete Konfidenz EX^ )Y^ [Pr(Y jX )]
der Regel X ) Y definiert werden. Sei Y = fy1 ; : : :; yn g und
Y^ = fy^1; : : : ; y^j ; yj+1; : : :; yng, 1 j n, so dass y^i ein Vorfahre von yi ist.
Dann definiert sich die erwartete Konfidenz von X ) Y bzgl. der bekannten
^ ) Y^ wie folgt:
Regel X
(y )
Pr(yj ) Pr(Y^ jX^ )
EX )Y [Pr(Y jX )] = Pr
:
:
:
Pr(^y )
Pr(^y )
^
^
1
1
j
(3.9)
^ ) gilt.
Man sollte beachten, dass EX^ )Y [Pr(Y jX )] = Pr(Y jX
Nun kann man eine Regel X ) Y als R-interessant bzgl. ihres Vorfahrens
X^ ) Y^ nennen, wenn entweder der Support von X ) Y das R-fache des erwar^ ) Y^ ist, oder die Konfidenz das R-fache der erwarteten
teten Supports bzgl. X
^ ) Y^ beträgt.
Konfidenz bzgl. X
Interessante Regel
Sei eine Menge S von Regeln und ein Minimalinteresse R gegeben. Eine Regel
X ) Y ist interessant (in S ), wenn sie keine Vorfahren in S besitzt oder sie
R–interessant bzgl. ihrer direkten Vorfahren ist. Die Regel X ) Y ist teilweise
interessant (in S ), wenn sie keine Vorfahren in S besitzt oder sie R–interessant
bzgl. mindestens eines direkten Vorfahrens ist.
3.4. Quantitative Assoziationsregeln
45
3.4 Quantitative Assoziationsregeln
Die bisher besprochenen Verfahren beschreiben das Finden von Assoziationsregeln mit boolscher Aussagekraft. Es wird also geprüft, ob ein Artikel in einer
Transaktion vorhanden ist oder nicht.
In der Realität werden allerdings viel häufiger quantitative oder kategorische Aussagen über Artikel getroffen und sie sind daher sehr wichtig für die Bildung von
Assoziationsregeln. Im Kontext eines Kaufhauses wäre eine solche quantitative
Assoziationsregel: ,,Wer 3 mal Artikel A kauft, erwirbt mit 90% Wahrscheinlichkeit 2 mal Artikel B .” Im Rahmen einer medizinischen Diagnosedatenbank
könnte eine quantitative Assoziationsregel so aussehen: ,,Der Patient hat sehr
starken Husten und Laborwert A-20, dann ist er mit 96% Wahrscheinlichkeit ein
starker Raucher.”
3.4.1 Problemstellung
Das Gebiet der quantitativen Assoziationsregeln ist noch relativ neu und daher
gibt es nur wenige Literaturstellen, die sich mit dem Finden solcher Regeln beschäftigen. Das von Srikant und Agrawal [SA96] vorgestellte Verfahren soll hier
ausführlich diskutiert werden:
Da das Problem der boolschen Assoziationsregeln schon sehr gut untersucht wurde, ist es zunächst interessant, inwieweit das Finden von quantitativen Assoziationsregeln auf das Finden von boolschen Assoziationsregeln abgebildet werden
kann: Der einfachste Weg wäre, für jeden Artikel i die möglichen Ausprägungen
zu untersuchen und für jede Ausprägung einen neuen Artikel ik zu generieren. Ein Artikel i mit 10 verschiedenen Ausprägungen würde also die Menge
i0 = fi1; : : :; i10g erzeugen. Für Artikelgruppen mit sehr vielen (oder kontinuierlichen und damit unendlich vielen) Ausprägungen schlägt diese Methode aber
offensichtlich fehl. Hier bietet es sich an, Intervalle über eine Menge von zusammenhängenden Werten zu bilden und mit diesen Intervallen die neuen Artikel zu
generieren.
Das catch–22 Problem
Die Wahl der Intervallgrenzen ist kein triviales Problem. Srikant et al. [SA96] beschreiben den Trade–Off zwischen großen und kleinen Intervallen als das catch–
22 Problem:
1. Zu geringer Support: Teilt man den Wertebereich der einzelnen Attribute
46
in zu viele Intervalle auf, so finden sich zu wenige Transaktionen, die diese
einzelnen Intervallbereiche unterstützen. Viele Bereiche erreichen somit
nicht mehr den minimalen Support.
2. Zu geringe Konfidenz: Als Reaktion auf den Supportverlust könnte man
die Intervallbereiche größer wählen. Werden aber zu große Wertebereiche
in Intervallen vereint, so erreichen einige Regeln die minimale Konfidenz
nicht mehr. Diese Erkenntnis ergibt sich aus der Definition der Konfidenz.
Zusammenfassend lässt sich das catch–22 Problem also folgendermaßen beschreiben: Sind die Intervalle zu klein, so erreichen einige Regeln den min support
nicht; werden die Intervalle zu groß, so ist die Konfidenz für einige Regeln zu
klein.
Eine mögliche Lösung des Problems wäre die Aufspaltung der einzelnen Wertebereiche in möglichst viele denkbare Intervalle, in der Weise, dass sich einige Intervalle auch überlappen. Wenn man also beispielsweise die Intervalle [1..10], [11..20], [21..30] betrachten würde, könnte man auch die Intervalle
[1..20], [11..30] oder [1..30] miteinbeziehen. In dieser Hinsicht ließen sich die
Probleme des zu geringen Supports und Konfidenz umgehen. Allerdings entstehen durch die Bildung der vielen (redundanten) Intervalle zwei neue Probleme:
1. Ausführungszeit: Hat ein Wert n verschiedene Wertausprägungen, so gibt
es durchschnittlich O(n2 ) mögliche Intervallbereiche. Daraus folgt, dass
durch den rapiden Anstieg der Intervallanzahl auch die Ausführungszeit
drastisch steigt.
2. Zu viele Regeln: Erreicht ein Attributwert den minimalen Support, so erreicht ihn auch jedes Intervall, in dem dieser Attributwert vertreten ist.
Hieraus folgt, dass die Anzahl der erzeugten Regeln mit der Anzahl der
verfügbaren Intervalle steigt.
Es ist noch zu bemerken, dass es in der Regel nicht sinnvoll ist, über kategorischen Attributen Intervalle zu bilden. Sind jedoch Taxonomien über diesen kategorischen Attributen möglich, so könnten diese zur Intervallbildung dienen.
3.4.2 Grundlegende Definitionen
Zunächst ist es hilfreich, quantitative und kategorische Attribute in einem Terminus abzubilden. Die Werte der kategorischen Attribute werden in fortlaufenden
47
Zahlen abgebildet ebenso wie die Werte der quantitativen Attribute, die nicht in
Intervalle aufgeteilt wurden. Quantitative Attribute, die in Intervalle unterteilt
wurden, werden ihren Intervallen entsprechend ebenfalls in fortlaufenden Zahlen abgebildet, ohne dabei die Ordnung der Werte zu verlieren. Auf diese Weise lässt sich jeder Datensatz der Datenbank in ein Tupel (Attribut, Zahlenwert)
überführen.
Abbildung der Attribute
Sei I = fi1; i2; : : : ; im g die Menge der Attribute und P eine Menge von positiven
Zahlen. Man bezeichne mit IV die Menge I P und ein Tupel (x; v ) 2 IV
bedeute das mit dem Wert v verbundene Attribut x.
Sei IR die Menge f(x; l; u) 2 I P P j l u, für x quantitativ; l = u, für
x kategorischg. Auf diese Weise stellt also das Tripel (x; l; u) 2 IR entweder
ein quantitatives Attribut mit dem Intervallbereich [l; u] oder ein kategorisches
Attribut mit dem Wert l dar. Weiter gelte für alle X IR :
attributes(X ) = fx j (x; l; u) 2 X g
Quantitative Assoziationsregel
Eine Artikelmenge R IR supported ein X , wenn gilt: [8(x; l; u) 2
X ] [9(x; q) 2 R], so dass l q u gilt. Eine quantitative Assoziationsregel ist eine Implikation der Form X ) Y mit X IR , Y IR und
attributes(X ) \ attributes(Y ) = ;. Eine Regel X ) Y hat die Konfidenz
c, wenn c Prozent der Transaktionen in D die X supporten auch Y supporten.
Entsprechend hat die Regel X ) Y einen Support von s, wenn s Prozent der
Transaktionen in D die Menge X [ Y unterstützen.
Generalisierung und Spezialisierung
^ als eine Generalisierung von X , wenn gilt: attributes(X ) =
Man bezeichnet X
attributes(X^ ) und 8x 2 attributes(X ) : [(x; l; u) 2 X ^ (x; l0; u0) 2 X^ ) l0 l u u0]. X ist dann eine Spezialisierung von X^ . In diesem Kontext spricht
man bei Generalisierungen oft auch von Vorfahren. Beispielsweise wäre f(Milch
1..8), (Brot 1..2)g eine Generalisierung von f(Milch 1..5), (Brot 1..2)g .
3.4.3 Vorgehensweise beim Finden von quantitativen
Assoziationsregeln
Das Finden von quantitativen Assoziationsregeln lässt sich in 5 Teilschritte untergliedern, auf die im Weiteren näher eingegangen werden soll:
1. Partitionierung der quantitativen Attributwerte Für jedes quantitative
48
Attribut werden die sinnvollen Intervalle bestimmt, in welche der Wertebereich unterteilt werden soll. Für kategorische Wertebereiche ist eine Partitionierung in der Regel nicht sinnvoll.
2. Harmonisierung der Attributwerte Bei kategorischen Attributen werden
die Wertausprägungen in fortlaufenden Ziffern abgebildet. In entsprechender Weise werden quantitative Attribute, die nicht partitioniert wurden, in
fortlaufenden Ziffern abgebildet. Die Ordnung zwischen den Wertausprägungen darf dabei nicht verloren gehen. Wurden quantitative Attribute in
Intervalle partitioniert, so werden diese Intervalle ebenfalls in fortlaufenden
Ziffern abgebildet. Auch hier soll die Ordnung erhalten bleiben.
Von nun an kennt das Verfahren nur Werte für quantitative Attribute. Die
Intervalle oder Kategorien, die hinter diesen Ziffern stehen, bleiben für den
Algorithmus transparent.
3. Supportberechnung Es wird der Support für die quantitativen und kategorischen Attribute berechnet. Zusätzlich werden für die quantitativen
Attribute noch so lange benachbarte Werte miteinander verschmolzen und
der resultierende Support bestimmt, bis ein benutzerdefinierter, maximaler (!) Support überschritten wird. Artikel, die den minimalen Support
überschreiten, ergeben die Menge der häufigen Einzelartikel.
4. Verwendung eines boolschen Assoziationsregel–Verfahren Nach der
Vorarbeit ist es nun möglich, ein um leichte Modifikationen erweitertes boolsches Assoziationsregel–Verfahren zu benutzen. Der Apriori–
Algorithmus wird dafür von [SA96] vorgeschlagen. Auf die nötigen
Ergänzungen wird in Abschnitt 3.4.6 eingegangen.
5. Filtern der interessanten Regeln Beim Generierungsprozess entstehen
viele uninteressante und redundante Regeln. In Abschnitt 3.4.5 wird ein
Maß vorgestellt, welches das Interesse und den Informationswert einer Regel bestimmt.
3.4.4 Partitionierung der quantitativen Attributwerte
Wie schon in der Einleitung ersichtlich wurde, stellt die Partitionierung der Wertebereiche ein wesentliches Problem des Verfahrens dar. Dieses besteht darin, dass jede Partitionierung einen gewissen Informationsverlust mit sich führt.
Um diesen Informationsverlust bewerten zu können, wird zunächst ein Teilvollständigkeitsmaß über Artikelmengen eingeführt.
49
K–Vollständigkeit
(K–complete) Sei C die Menge aller häufigen Artikelmengen in D und sei weiter
K 1 reell. Dann heißt P K–vollständig bzgl. C , wenn gilt:
1.
2.
3.
PC
X 2 P ^ X0 X ) X0 2 P
^ 2 P] :
[8X 2 C ][9C
^ ) K support(X )
^ ist eine Generalisierung von X und support(X
(a) X
und
^ ]: Y^ ist eine Generalisierung von Y und
(b) [8Y X ][9Y^ X
support(Y^ ) K support(Y ).
Die beiden ersten Bedingungen 1. und 2. sichern , dass P nur häufige Artikelmengen enthält und somit zur Generierung von Regeln geeignet ist. Der erste Teil der
dritten Bedingung sagt, dass es für jede Artikelmenge X in C eine Generalisierung gibt, deren Support höchstens K mal größer ist. Im zweiten Teil der dritten
Bedingung sieht man, dass diese Eigenschaft auch für Teilmengen von X zutrifft.
Bei näherer Betrachtung wird klar, dass P für K = 1 mit C identisch ist.
Beispiel Zur Verdeutlichung seien die in Abbildung 3.4 häufigen Artikelmengen
gegeben. Die Artikelmengen 2, 3, 5 und 7 sind eine 1,5–vollständige Menge M,
da für jede Artikelmenge X 2 M, entweder 2, 3, 5 oder 7 eine Generalisierung darstellt, deren Support mindestens das 1,5 fache des Supports von X ist.
Demgegenüber ist zwar Artikelmenge 2 eine Generalisierung von Artikelmenge
1, aber der Support von Artikelmenge 2 ist nur das 1,2 fache des Supports von
Artikelmenge 1.
No. Artikelmenge
Support
1 f(Alter: 20..30)g
5%
2 f(Alter: 20..40)g
6%
3 f(Alter: 20..50)g
8%
4 f(BDruck: 1..2)g
5%
5 f(BDruck: 1..3)g
6%
6 f(Alter: 20..30) (BDruck: 1..2)g
4%
7 f(Alter: 20..40) (BDruck: 1..3)g
5%
Abbildung 3.4: Beispiel Teilvollständigkeit
Mit Hilfe eines Lemmas zeigen [SA96] folgende interessante Beobachtung:
50
Lemma 3 Sei P K–vollständig bzgl. der Menge der häufigen Artikelmengen C
und RC die Menge der aus C generierten Regeln, welche die minimale Konfidenz
erfüllen. Weiter sei RP die Menge der aus P generierten Regeln, deren Konfidenz
min conf erfüllt. Für jede Regel A ) B aus R gibt es dann eine Regel A^ ) B
^,
C
K
so dass gilt:
A^ und B^ sind Generalisierungen von A und B .
A^ ) B^ hat höchstens den K–fachen Support von A ) B .
Die Konfidenz von A^ ) B^ ist mindestens das K –fache und höchstens das
K –fache der Konfidenz von A ) B .
1
Zwei weitere Lemmata zeigen Eigenschaften, die zur Partitionierung der Wertebereiche wichtig sind. Folgendes Lemma untersucht die Partitionen eines einzelnen
Attributs:
Lemma 4 Sei x ein quantitatives Attribut und K > 1 reell. Nun wird x in Intervalle (sogenannte Basisintervalle) partitioniert, so dass für jedes dieser Basisintervalle B gilt:
support(B ) < min support K,
“B ist Einzelwert”
1
2
oder
Wenn man nun mit P die Menge aller Kombinationen von Basisintervallen bezeichnet, die den min support erreichen, dann ist P K–vollständig bzgl. der Menge aller möglichen Bereiche über x mit min support.
Das anschließende Lemma verallgemeinert diese Eigenschaft auf n Attribute:
Lemma 5 Sei eine Menge von n quantitativen Attributen und ein reelles K > 1
gegeben. Man nehme an, dass jedes einzelne Attribut derart in Basisintervalle B
partitioniert wird, dass entweder
support(B ) < min support K,n
“B ist Einzelwert”
2
1
oder
gilt. Wenn P die Menge aller häufigen Artikelmengen über diesen partitionierten
Attributen ist, dann ist P K–vollständig bzgl. der Menge aller häufigen Artikelmengen (die ohne Partitionierung gewonnen wurden).
51
Aufgrund der Lemmatas kann man nun für eine beliebig gegebene Partition den
Grad der Teilvollständigkeit bestimmen. Hier soll dies zunächst nur für ein einzelnes Attribut gezeigt werden:
Nachdem man die Partition mit dem größten Support gefunden hat, dient die Formel
s = min support K 2, 1
(3.10)
zum Finden des Grades der Teilvollständigkeit. Nach einfacher Umformung ergibt sich
2s
K =1+
(3.11)
min support
Für n Attribute dient die entsprechende Formel
ns
K = 1 + min2 support
(3.12)
In [SA96] wird weiter gezeigt, dass gleichgroßes Partitionieren den Grad der
Teilvollständigkeit minimiert. Folglich minimiert für einen gegebenen Grad der
Teilvollständigkeit gleichgroßes Partitionieren die Anzahl der Intervalle, die zur
Erfüllung dieses Grades benötigt werden.
Zusammenfassend betrachtet lässt sich also leicht bei einem gegebenen Teilvollständigkeitsgrad und einem gegebenen min support die Anzahl der benötigten
Partitionen berechnen. Um einen Grad K der Teilvollständigkeit zu erreichen,
darf der Support einer Partition (mit mehr als einem Wert) min support k2,n1
nicht überschreiten, wobei n die Anzahl der quantitativen Attribute ist.
Nimmt man weiter an, dass gleichgroßes Partitionieren den Support gleichverteilt
(Partitionen mit nur einem Wert werden hierbei nicht betrachtet, da sie die Teilvollständigkeit nicht beeinflussen), so entstehen 1s Partitionen, die jeweils ihren
Support unter s halten.
Hieraus ergibt sich folgende Formel:
Intervallzahl = m 2(K n, 1)
(3.13)
(n: Anzahl der quantitativen Attribute, m: minimaler Support, K: Grad der Teilvollständigkeit)
52
3.4.5 Filtern der interessanten Regeln
Bei der Generierung der quantitativen Assoziationsregeln werden sehr viele redundante und damit uninteressante Regeln erzeugt. Ein Ansatz, diese Korrelationen zu filtern, soll hier vorgestellt werden. Zunächst betrachte man zwei Regeln
der Art:
(Milch 1..10)
(Milch 1..5)
)
)
(Brot 2..4)
(Brot 2..4)
8% Support, 70% Konfidenz
2% Support, 70% Konfidenz
Folgt man nun der Annahme, dass 14 der Transaktionen, in denen (Milch 1..10)
liegt, auch (Milch 1..5) enthalten ist, so kann die zweite Regel als redundant angesehen werden, da sie gleiche Konfidenz und die erwarteten 25% der Supports
der ersten Regel hält. Eine Regel erscheint also erst dann interessant, wenn sie
einen größeren Wert als erwartet hält. Dieses “greater–than–expected–value”–
Kriterium wird nun formal definiert:
Erwartungswert
Sei EPr(Z^) [Pr(Z )] der erwartete Wert des Supports von Z (Pr(Z )), basierend
auf Pr(Z^ ), wobei Z^ Generalisierung von Z ist). Sei weiter die Artikelmenge
Z = f(z1; l1; u1); : : :; (zn; ln; un)g und Z^ = f(z1; l10 ; u01); : : : ; (zn; ln0 ; u0n)g. Dann
ist
((z ; l ; u ))
Pr((zn ; ln; un )) Pr(Z^ )
:
:
:
EPr Z [Pr(Z )] = Pr
0
0
Pr((z ; l ; u ))
Pr((z ; l0 ; u0 ))
( ^)
1
1
1
1
1
1
n n n
(3.14)
In gleicher Weise lässt sich der Erwartungswert für die Konfidenz der Regel X )
Y definieren, wenn Y = f(y1; l1; u1); : : :; (yn; ln; un)g und Y^ = f(y1; l10 ; u01); : : :;
(yn ; ln0 ; u0n )g:
((y ; l ; u ))
Pr((yn ; ln; un )) Pr(Y^ jX^ )
EPr Y jX [Pr(Y jX )] = Pr
:
:
:
0
0
Pr((y ; l ; u ))
Pr((y ; l0 ; u0 ))
(^ ^)
1
1
1
1
1
1
n n n
(3.15)
Leider ist es nicht ausreichend, eine Artikelmenge als interessant bzgl. ihres Vorgängers zu bezeichnen, sobald der Support größer oder gleich dem R–fachen des
erwarteten Supports ist. Auf Grund dieser Bedingung werden immer noch viele
Intervalle fälschlicherweise als interessant angesehen. Vielmehr ist es wichtig,
53
auch Spezialisierungen der Artikelmengen zu betrachten. So werden Spezialisierungen der Artikelmenge gesucht, die interessanter als die eigentliche Menge sind.
Ist dies der Fall, so wird die Spezialisierung von der Menge abgetrennt und untersucht, ob die Differenz daraus noch interessant ist. Wird keine Spezialisierung
mit dieser Eigenschaft gefunden, so behält man die Artikelmenge als interessant.
R–interessant
Eine Artikelmenge X ist R–interessant bzgl. X^ , wenn der Support von X größer
^ ) und
oder gleich dem R–fachen des erwarteten Supports ist (basierend auf X
0
0
wenn jede Spezialisierung X mit der Eigenschaft “X hat min support” und
X , X 0 IR, die Differenz X , X 0 ist R–interessant bzgl. X^ .
3.4.6 Ergänzungen zum Algorithmus
Die Vorgehensweise des Algorithmus zum Finden quantitativer Assoziationsregeln wurde bereits besprochen. In den vorliegenden Abschnitten wurde beschrieben, wie die Attributwerte partitioniert werden sollten und wie interessante Artikelmengen herausgefiltert werden können. Damit ist die wichtigste Vorarbeit für
den Algorithmus schon geleistet. Der Fokus soll nun auf den Kern des Prozesses
gerichtet werden: Dem Finden der häufigen Artikelmengen.
Zum Finden der häufigen Artikelmengen schlagen [SA95] einen leicht modifizierten Apriori–Algorithmus vor. Mit häufigen Einzelartikeln beginnend werden
sukzessive häufige, mehrelementige Artikelmengen gebildet. Die Generierung
der Kandidatenmenge und die Bestimmung des Supports benötigen jedoch eine
Anpassung an die Aufgabenstellung.
Kandidatengenerierung
Ausgehend von einer (k -1)–elementigen häufigen Artikelmenge
diese Prozedur eine k -elementige Kandidatenmenge Lk .
Lk,
1
generiert
Während die beiden ersten Schritte dem Grundalgorithmus entsprechen, stellt der
dritte Schritt die eigentliche Erweiterung dar:
1. Join–Phase Ein Join wird auf Lk,1 mit sich selbst ausgeführt, so dass die
k , 2 ersten Elemente geordnet sind und sich die beiden letzten Attribute
unterscheiden.
2. Prune–Phase Alle resultierenden Artikelmengen werden untersucht. Liegt
eine (k , 1)-elementige Teilmenge vor, die nicht in Lk,1 liegt, so wird die
entsprechende k –elementige Artikelmenge entfernt.
54
3. Prunen nach Interesse Gibt der Benutzer ein Interessemaß an, so wird
dieses Maß zum Prunen der Artikelmengen benutzt.
Supportbestimmung der Kandidaten
Für die Bestimmung des Supports aller Kandidaten wird ein kompletter Datenbankdurchlauf benötigt. Die Datenbasis wird tupelweise ausgelesen und jedes
Tupel (Transaktion) wird mit der Kandidatenmenge verglichen.
Zum effizienteren Vergleich können die Kandidaten in Gruppen organisiert werden, so dass gleiche kategorische Attributwerte und gleiche quantitative Attribute
in einer Gruppe versammelt sind. Jede Kandidaten–Gruppe wird durch einen sogenannten Super–Kandidaten ersetzt. Dieser Super–Kandidat besteht aus zwei
Teilen: Den gemeinsamen kategorischen Attributwerten und einer Datenstruktur,
welche die unterschiedlichen quantitativen Attributwerte abbildet.
Beispiel
Seien beispielsweise folgende drei Kandidaten generiert worden:
f(Kreditkarte Ja),
f(Kreditkarte Ja),
f(Kreditkarte Ja),
(Milch 1..5),
(Milch 1..8),
(Milch 3..4),
(Brot 1..2)g,
(Brot 2..4)g,
(Brot 4..6)g
Alle drei Kandidaten besitzen die gleichen Attribute und haben für das einzige,
kategorische Attribut Kreditkarte den gleichen Wert “Ja”. Daher lassen sie sich
zu einem Super–Kandidaten zusammenfassen.
Kreditkarte
Milch
1..5
1..8
3..4
Ja
Brot
1..2
2..4
4..6
Die Supportberechnung untergliedert sich folglich in zwei Aufgaben:
1. Finden und Generieren der Super–Kandidaten
2. Tupelweises Durchlaufen der Datenbank. Sobald eine Transaktion die kategorischen Werte eines Super–Kandidaten enthält, müssen in diesem Super–
Kandidaten diejenigen Kandidaten gefunden werden, welche die Transaktion unterstützen.
3.5. Betrachtung der Komplexität
55
3.5 Betrachtung der Komplexität
Die einzelnen Autoren führen in ihren Aufsätzen ausführliche Tests mit synthetischen und realen Datensätzen durch. So beschreiben sie bei verschiedenen Datencharakteristika die unterschiedlichen Verhaltensweisen der vorgestellten Algorithmen. Dennoch vermisst man theoretische Überlegungen bezüglich
der Komplexität der einzelnen Algorithmen. Han et al. stellen jedoch in [HP96]
Überlegungen zur Komplexitätsberechnung von Assoziationsregelverfahren an.
Das A PRIORI–Verfahren bildet für die meisten Algorithmen die Grundlage in der
Generierung der häufigen Artikelmengen. So bauen beispielsweise auch Modifikationen, wie Verfahren zum Finden von generalisierten Assoziationsregeln
(C UMULATE) auf dem A PRIORI–Algorithmus auf. Aus diesem Grund wird hier
eine fundierte Untersuchung dieses Verfahrens gegeben. Leichte Modifikationen
verändern die Grundkomplexität nicht entscheidend.
Zunächst ist es wichtig, Obergrenzen für die zu untersuchenden Artikelmengen
zu finden. Die Anzahl aller k –Artikelmengen über der Menge aller Artikel I mit
jIj = N ist
!
N
jAk j =
(3.16)
k
Folglich gilt jAk j 2 O(N k ). Eine Überprüfung aller Artikelmengen Ak im k –ten
Schritt ist also zu aufwendig. Aus diesem Grund wählen die A PRIORI–Verfahren
in sogenannten Kandidatenmengen Ck Artikelmengen aus, die überhaupt für die
Bildung der häufigen Artikelmengen Lk in Frage kommen.
Von Interesse ist zunächst die Komplexität dieser Artikelmengen Lk . Die einfachste Möglichkeit wäre, eine Wahrscheinlichkeitsverteilung Pt (n) über den Daten
anzunehmen (n sei die Transaktionsgröße). Sind keine weiteren Informationen
verfügbar, so müssen alle k –Artikelmengen gleichwahrscheinlich angenommen
werden, also gilt Ck = Ak . Sinnvoller ist es Korrelationen über der Datenbasis D
anzunehmen und diese näher zu betrachten.
Um diese Korrelationen näher beschreiben zu können, wird der Begriff Cluster
eingeführt. Ein Cluster ist eine größtmögliche, häufige Artikelmenge, so dass
jede Teilmenge zwar häufig, aber jede Erweiterung des Clusters nicht mehr häufig
wäre. Üblicherweise kann davon ausgegangen werden, dass die zu untersuchende
Datenbank über eine Anzahl von Clustern verfügt. Sei daher mit C die Menge der
Cluster über D gegeben und es gilt C = f1; 2 ; 3 ; : : :g.
Komplexität von Lk Die Größe von Lk ist einfach zu errechnen, wenn alle Cluster
56
disjunkt sind. Dann ist jede Teilmenge
des
jeweiligen Clusters i eine häufige
j
ij
Artikelmenge und es gibt pro Cluster k häufige Artikelmengen. Folglich gilt
P ji j
ist.
insgesamt, dass jLk j =
i k
Gewöhnlicherweise überlappen sich die einzelnen Cluster jedoch und es gilt dann:
!
!
!
X ji j
X ji \ j j
X ji \ j \ l j
jLk j =
+
, : : : (3.17)
k , i;j
k
k
i
i;j;l
P ji j
P ji j
,
kann
hier
als
obere
Grenze
und
der
Term
Die erste Summe
i k
i k
P ji \j j
als untere Grenze gesehen werden.
k
i;j
Mit dem Wissen um die Größen von Lk lassen sich nun die Kosten des A PRIORI–
Verfahrens in Algorithmus 3.2.3 (Seite 28) schätzen.
In der ersten Zeile werden die häufigen Einzelartikel ermittelt. Die Kosten für die
Festplattenzugriffe lassen sich auf einen gesamten Durchlauf durch die Datenbank
festsetzen. Mit einer passenden Hashfunktion wird das Generieren und Zählen
der 1-Artikelmengen in konstanter Zeit erledigt. Seien cd die Kosten für einen
Festplattenzugriff (Lesen/Schreiben). Dann sind die Kosten für die Generierung
der häufigen 1-Artikelmengen O(jjDjj) und die Zugriffskosten belaufen sich auf
O(cd jjDjj).
Die nun startende Hauptschleife wird von zwei Prozeduren bestimmt: Die Generierung der Kandidaten und das anschließende Zählen derselben. Die Kandidatengenerierung ist in Prozedur 3.2.2 (Seite 29) abgebildet. Der beginnende JoinSchritt benötigt im schlimmsten Fall O(jLk,1 j2 ) Operationen. Das anschließende
Prunen verarbeitet O(k jCk j jLk,1 j) Operationen. Insgesamt verbraucht die
Kandidatengenerierung also Kosten in Höhe von
O(jLk, j
1
2
+k
jCk j jLk, j)
1
(3.18)
Im Anschluss daran wird die Datenbank komplett durchlaufen und die Präsenz
der generierten Kandidaten in der Transaktionen gezählt. Die Kosten für diesen
Datenbankdurchlauf betragen
O(fs jDj + jCtj jDj)
(3.19)
Hier seien fs die Kosten für die Bildung der Teilmengen Ct von Ck , die in der
aktuellen Transaktion enthalten sind (siehe A PRIORI–Verfahren auf Seite 28).
3.5. Betrachtung der Komplexität
57
Die Kosten fs sind sehr individuell von Ck und der jeweils aktuellen Transaktion t abhängig. Eine ad–hoc–Implementation der Teilmengenbildung würde
O(m jCk j t) kosten, wobei m die Anzahl der Ck für ein bestimmtes k ist.
Zusammenfassend belaufen sich die Gesamtkosten der Hauptschleife auf
!
X
2
O
jLk j + k jCk j jLk,1j + fs jDj + jCtj jDj
(3.20)
k
Da jede Iteration der Schleife einen Datenbankdurchgang erfordert, belaufen sich
die Gesamtkosten der Plattenzugriffe auf
O(K cd jjDjj)
(3.21)
wobei K die Anzahl der nötigen Iterationen ist. Es gilt für K
K maxfjtj j t 2 Dg
Da D in der Regel sehr groß ist, sind fs
Terme in Gleichung 3.20.
(3.22)
jDj und jCtj jDj die bestimmenden
58
4
Implementierung des Werkzeugs
M ISTRAL
Zu Beginn dieses Kapitels werden die wichtigsten Eigenschaften eines Data Mining Werkzeugs erörtert. Danach folgt eine detaillierte Besprechung der
Schlüsselkomponenten, die diese Eigenschaften in MISTRAL implementieren.
Dabei werden die verwendeten Entwurfsmuster genannt und zentrale Stellen in
UML skizziert.
4.1 Überlegungen zur Implementierung eines
Data Mining Werkzeugs
Im Rahmen dieser Arbeit wurde das Data Mining Werkzeug M ISTRAL (MIning
System Targeting Rules, Associations and Links) implementiert. Dieses Toolkit besteht im Wesentlichen aus einem Kern und daran gekoppelten Komponenten. Diese Komponenten implementieren Algorithmen (Algorithm), Datenverbindungen (DataFetcher) oder auch spezielle Darstellungen der Ergebnisse (Viewer). Um eine gewisse Grundfunktionalität zu erreichen, wurden Komponenten
programmiert, die es nun, von beliebigen Datenbanken ausgehend, ermöglichen
häufige Artikelmengen, Artikelverteilungen und (generalisierte) Assoziationsregeln zu berechnen. Darüber hinaus ist es leicht möglich, weitere Algorithmen,
DataFetcher und Viewer an den Kern zu koppeln.
Der Kern bewerkstelligt den Data Mining Lauf in einer 3er Kette: Holen der Daten, Verarbeiten durch einen Algorithmus und Darstellen der Ergebnisse.
59
60
4. Implementierung des Werkzeugs M ISTRAL
Die wichtigsten Eigenschaften eines Kerns sind dabei:
1. Modularität
Durch die modulare Architektur des Kerns und der Komponenten ist es problemlos möglich, das Werkzeug durch neue Komponenten zu erweitern.
Die objektorientierte Architektur im Verbund mit dem Einsatz von Entwurfsmustern wird im folgenden Absatz näher beschrieben.
2. Effiziente Datenbearbeitung
Da Data Mining Verfahren in der Regel mit (sehr) großen Datenmengen arbeiten, ist es für das Programm von entscheidender Bedeutung, Datenoperationen, wie das Auslesen oder Bearbeiten von Datensätzen, in effizienter
Weise durchzuführen.
4.2 Architektur von M ISTRAL
Die wichtigsten Stellen im Programm, welche die Modularisierbarkeit von MI STRAL garantieren (Kern, Speicherbereich, Komponentenentwurf) und solche, die
den Speicherbedarf eingrenzen (Speicherung der Artikel) sollen nun genannt werden.
4.2.1 Der Kern
Das Klassendiagramm in Abbildung 4.1 zeigt nur die wichtigsten Strukturen des
Kerndesigns. Im Zentrum des Entwurfs steht die Klasse MKernel, welche die
administrativen und operativen Aufgaben des Kerns übernimmt.
Zu den administrativen Aufgaben gehören:
1. Verwaltung der verfügbaren Komponenten
Viewer, Algorithmen und DataFetcher können hinzugefügt oder gelöscht
werden. Ebenso ist es möglich, für jede Komponente einen beschreibenden
Text anzeigen zu lassen.
2. Erstellen eines Data Mining Projekts
Definition der zu verwendenden Komponenten. Hier können eine Liste von
einem (oder mehreren) Viewern, ein Algorithmus und ein DataFetcher ausgewählt werden.
4.2. Architektur von M ISTRAL
61
3. Festlegen der Benutzerschnittstelle
An den Kern sollte eine Benutzerschnittstelle zur einfachen Bedienung gekoppelt werden. Es stehen eine kommandozeilenorientierte und eine fensterorientierte Shell zur Verfügung.
4. Speichern und Laden der Programmkonfiguration und Projektdefinition.
MComponent
setKernel
run
fine
toString
getAbout
getComponentID
equals
MKernel
AlgorithmList
DataFetcherList
ViewerList
configuration
DataFetcher 1
Algorithm
1
1
VIewer
1
*
1
run
fine
setUsedAlgorithm
setUsedViewer
setUsedDataFetcher
save/loadProject
closeKernel
add/removeAlgorithm
add/removeDataFetcher
add/removeVIewer
set/getShell
1
2
Memory
1
1
MistralShell
JMistral
MistralBatch
Abbildung 4.1: Mistral–Kern (UML)
Die operativen Aufgaben des Kerns umfassen:
1. Vorbereitung des Data Mining Projekts
Hier ist das Anlegen von Speicherbereichen und der Test auf Korrektheit
der eingestellten Parameter für jede Komponente wichtig.
62
2. Durchführung des Projekts
Jede Komponente wird in einem eigenen Thread gestartet. Danach kann der
Status des Projekts jederzeit erfragt werden.
3. Nachbereitung
Nach dem Lauf wird das Logfile geschrieben und der verwendete Speicherbereich bereinigt.
Im Ausschnitt des Klassendiagramms sind im Wesentlichen nur die operativen
Aufgaben wiederzufinden, da diese von größerem Interesse sind. Zur Bereitstellung von Speicherbereichen dient die Klasse Memory, bei deren Entwurf die Muster Strategie und Observer [Gam96] Verwendung fanden. Eine nähere
Betrachtung von Memory folgt in Abschnitt 4.2.2.
Das Strategie Muster wurde ebenfalls bei der Benutzerkopplung eingesetzt.
Theoretisch kann so jede Klasse, die das Interface MistralShell implementiert, als Benutzerschnittstelle des Kerns dienen. Die optionale Verwendung eines kommandozeilenorientierten (MistralBatch) oder eines fensterorientierten (JMistral) Programms mit dem gleichen Kern belegt dies.
Weiterhin sind die drei Hauptkomponenten Viewer, DataFetcher und Algorithm in Form von gleichnamigen Klassen an den Kern gekoppelt. Der Entwurf dieser Klassen wird in Abschnitt 4.2.4 näher untersucht.
4.2.2 Speicherbereiche
Das UML Klassendiagramm in Abbildung 4.2 zeigt nur die grundsätzliche Funktionalität. Der Kernel verwaltet standardmäßig zwei Speicherbereiche: Der erste
dient zur Speicherung der Ausgangsdaten (dataSet), während der zweite die berechneten Ergebnisse sammelt (resultSet).
Dem Strategie Muster [Gam96] folgend wurde die Grundklasse Memory implementiert, um konkrete Implementierungen austauschbar zu machen. Als konkrete Strategie wurde eine vollständig auf dem Arbeitsspeicher basierende Lösung
(RAMMemory) und eine dateibasierte Speicherstruktur (FileMemory) implementiert.
Eng verknüpft mit der Memory Klasse sind die Klassen DataFetcher, Algorithm und Viewer. Diese Klassen dienen als Schnittstellen zu den konkreten Implementierungen von Datenanbindungen, Algorithmen und Darstellungskomponenten für die Ergebnisse. Diese Komponenten sollten jederzeit über die
63
Observer
Subject
1
observers
*
update
notifyObservers
subscribe
unsubscribe
Memory
2
reset
close
getNextElement
getElementAt
getChange
getSize
1
1
1
Algorithm
Viewer
MComponent
RAMMemory
FileMemory
setKernel
run
fine
toString
getAbout
getComponentID
equals
Abbildung 4.2: Speicherbereich (UML)
Veränderung in einem Speicherbereich informiert sein. So können die meisten Algorithmen erst dann starten, wenn alle Daten im dataSet versammelt sind. Im
Gegensatz dazu kann eine Darstellungskomponente (Viewer) immer die aktuell
berechneten Ergebnisse darstellen.
Um diese Funktionalität zu erreichen,
wurde das Observer
(Publisher-Subscriber) Muster [Gam96] umgesetzt.
Memory erweitert hierbei die Klasse Subjekt, welche Beobachter verwalten und
benachrichtigen kann. Die Klassen Algorithm und Viewer wiederum
implementieren das Interface Observer, welches vom Subjekt benachrichtigt
wird. DataFetcher wurde nicht um das Interface Observer erweitert, da
diese Komponenten üblicherweise in einem sequentiellen Lauf die Daten holen
und im Speicherbereich ablegen. Eine Benachrichtigung macht hier wenig Sinn.
64
4.2.3 Speicherung der Artikel
Bei der Durchführung eines Data Mining Projekts muss häufig mit mehreren hunderttausend Artikeln umgegangen werden. Daher ist die effiziente und trotzdem
Speicher minimierende Implementierung einer Artikelklasse von großem Interesse.
ConcreteFlyweight
ItemFactory
value
iid
*
1
ConcreteFlyweightList
add
removeAllIems
elementAt
getSize
setName
getName
setID
getID
equals
toString
Item
id
toString
equals
Abbildung 4.3: Verwaltung der Artikel (UML)
Die Klasse Item lehnt sich an das in [Gam96] vorgestellte Flyweight Muster
an. So kann dieser Terminologie folgend die Klasse Item als Klient, die Klasse
ItemFactory als FliegengewichtFabrik und ConcreteFlyweight als Implementierung von konkretesFliegengewicht verstanden werden.
Zur näheren Erläuterung der Funktionsweise hier ein kleines Beispiel: Es wird
während des Programmlaufes eine neue Instanz von Item mit einem entsprechenden Artikelnamen gebildet. Daraufhin fragt der Konstruktor von Item bei
ItemFactory nach einer Referenz, die dem Artikelnamen entspricht. Wurde der Artikelname noch nicht verwendet, so erzeugt ItemFactory ein neues
konkretes Fliegengewicht, speichert es intern ab und liefert eine Referenz darauf
zurück. Ist diese Artikelausprägung schon vorhanden, so wird die entsprechende
Referenz zurückgeliefert. Die Klasse Item muss also nur eine Referenz speichern, während die Klasse ItemFactory die komplette Information der jeweiligen Artikelreferenzen in konkreten Fliegengewichten speichert.
Auf diese Weise muss die komplette Information jeder Artikelausprägung nur einmal gespeichert werden. Die Klienten verwalten nur Referenzen. Der damit verbundene Speicher- und Laufzeitgewinn ist leicht nachvollziehbar.
65
4.2.4 Die Mistral-Komponenten
Wie schon vorher beschrieben verwirklicht der Kern nur administrative und operative Projektaufgaben. Die eigentliche Arbeit wird von den Mistral Komponenten
übernommen. Hier unterscheidet man zwischen drei Typen:
1. Verbindungen zu Datenquellen (DataFetcher)
Diese stellen eine Verbindung zu einer spezifizierten Datenquelle her,
wie zum Beispiel einer Textdatei (TEXT DATA F ETCHER) oder einer
JDBC/ODBC Datenbank (DBCDATA F ETCHER). Von dort holen sie die
angeforderten Daten in den Kern.
2. Data Mining Algorithmen (Algorithm)
Diese Komponenten sind für die Musterfindung aus den bereitgestellten Daten zuständig. Dazu kann das Finden von (generalisierten) Assoziationsregeln (Komponente Cumulate) oder von häufigen Artikelmengen (Komponente FrequentSets) zählen. Ebenso kann die Verteilung der Einzelartikel berechnet werden (I TEMD ISTRIBUTION). Der Algorithmus A PRIOR I NTERVALL findet Assoziationsregeln in einem speziellen Supportintervall.
3. Darstellungskomponenten (Viewer)
Viewer dienen zum Darstellen oder Sichern der Ergebnisse des Data Mining Prozesses.
So schreibt beispielsweise die Komponente
TextfileViewer die Ergebnisse in eine Textdatei. TAB TEXT V IEWER
und M ISTRAL F ILE V IEWER sind Spezialisierungen von TEXTFILE V IEWER
und schreiben die Ergebnisse in bestimmte Dateiformate. W INDOW V IEWER zeigt die Ergebnisse in einem Programmfenster an.
Damit die Anbindung der Komponenten an den Kern problemlos vollzogen werden kann, sind einige Voraussetzungen zu beachten.
Zunächst einmal muss jede Komponente das Interface MComponent implementieren, welches die nötigsten Methoden vordefiniert. Die wichtigsten Methoden
dieses Interface sind fine() und run(). Während die Methode fine() die
Korrektheit der eingegebenen Komponentenparameter prüft, aktiviert die Methode run() den Lebenszyklus der Komponente. Dabei startet der Kern jede Komponente als einen eigenen Thread.
Weiterhin muss jede Komponente eine der drei Vaterklassen DataFetcher,
Algorithm oder Viewer erweitern. Durch die Erweiterung der eigenen Klasse
durch eine dieser drei Klassen wird der Typ der Komponente festgelegt. Darüber
66
hinaus kann eine neue Komponente auch von einer Klasse abgeleitet sein, die
früher von DataFetcher, Algorithm oder Viewer geerbt hat. Abbildung
4.4 (Seite 66) zeigt die Architektur der MISTRAL Komponenten in UML–Notation. TAB TEXT V IEWER beispielsweise unterscheidet sich nur im Ausgabeformat
der Resultate und kann so problemlos von TEXTFILE V IEWER erben. Trotzdem
wird TAB TEXT V IEWER ohne Weiteres von M ISTRAL als Komponente akzeptiert.
MComponent
Observer
fine
run
setKernel
getComponentID
getAbout
toString
equals
update
DataFetcher
Algorithm
Viewer
url
moldel
source
destination
state
model
setModel
setURL
getURL
setModel
setSource
setDestination
DBCDateFetcher
uid
passwd
sqlCommand
dbDriver
setUID
getUID
setPassWD
getPassWd
setSQLCommand
getSQLCommand
setDBDriver
getDBDriver
DummyAlgorithm
ItemDistribution
TextDataFetcher
WindowViewer
FrequentSets
getNextTransaction
hasMoreTransactions
reload
TextFileViewer
url
setSupport
getSupport
setTaxonomyURL
getTaxonomyURL
generateCandidates
setURL
getURL
Cumulate
MistralFileViewer
TabTextViewer
setConfidence
getConfidence
setInterestMeasure
getInterestMeasure
ApriorInterval
setMaxSupport
getMaxSupport
Abbildung 4.4: Mistral–Komponenten (UML)
Als wichtiger Punkt sollen noch die Eigenschaften von Komponenten betrachtet werden: Aus der geforderten Variabilität können Komponenten eine unterschiedliche Art und Anzahl von Eigenschaften besitzen. Der Terminologie der
JavaBeans Technologie folgend werden Parameter von Komponenten, die verändert werden können, als Eigenschaften (Properties) bezeichnet. Entsprechend
67
der JavaBeans Konvention [Fla97] wird auch in Mistral auf diese Eigenschaften mit get- und set-Methoden zugegriffen. Dabei akzeptiert Mistral nur Eigenschaften mit Vollzugriff, also nur solche mit get- und set-Methoden. Als
Übergabeparameter dient standardmäßig ein String–Objekt, welches innerhalb
der Methode konvertiert werden muss.
Wie in Abbildung 4.4 schön zu sehen ist, besitzt beispielsweise die C UMULA TE Komponente die Eigenschaften Confidence (die Konfidenz) und InterestMeasure (das Interessemaß). Die Eigenschaften Support (der Support) und TaxonomyURL (die URL der Taxonmiendatei) erbt die Komponente von F REQUENTS ETS. Keine Eigenschaften besitzen die Komponenten D UMMYA LGORITHM und
I TEMD ISTRIBUTION. Der Algorithmus I TEMD ISTRIBUTON berechnet die Verteilung der Einzelartikel, während D UMMYA LGORITHM die gelesenen Daten unverändert durch den Kern reicht. Beide Komponenten benötigen also keine von
außen zugänglichen Eigenschaften.
Abbildung 4.5: Beispiel: JavaDoc zu A PRIOR I NTERVAL
Die gesamte Implementierung in Java wurde unter Berücksichtigung des JAVA D OC–Syntax kommentiert. JAVA D OC gehört zum Standardumfang des JDKs
68
(Java Developer Kit) von Sun und generiert aus den Programmkommentaren automatisch verzeigerte HTML–Seiten. Die so erstellte Dokumentation kann auf der
beigelegten CD mit einem beliebigen HTML–Browser betrachtet werden. Abbildung 4.5 zeigt einen Ausschnitt aus der Dokumentation zur Algorithm Komponente A PRIOR I NTERVAL .
4.3 Aspekte der Implementierung
Das Werkzeug M ISTRAL wurde komplett in Java (Version 1.1.x mit JFC) implementiert. Diese Entscheidung brachte einige Vorteile, aber auch Nachteile mit
sich, welche hier kurz erörtert werden sollen.
Vorteile Einer der geforderten Aspekte von M ISTRAL sollte die Modularität und
Erweiterbarkeit sein. Beliebige neue Komponenten sollen problemlos an den Kern
gehängt werden können, ohne eine Neukompilation oder Modifikation der übrigen
Programmkomponenten zu erfordern. Durch die interpretierte Ausführung des Java Bytecodes in einer virtuellen Maschine (JVM) und der JAVA B EANS Technologie wurde es sogar möglich, während des Programmlaufs neue Komponenten einzuhängen oder zu bearbeiten. Aufgrund des strengen objektorientierten Aufbaus
und Sprachgebrauchs von Java war es sehr einfach, die verwendeten Entwurfsmuster (siehe 4.2) zu implementieren.
Der plattformübergreifende Bytecode von Java ermöglichte das Laufen von M I STRAL unter verschiedenen Betriebssystemen. So wurden beispielsweise erste
Testläufe mit Daten unter Solaris 2.5.2 (Sun JDK 1.1.6) durchgeführt. Die meisten Läufe wurden jedoch unter MS–Windows NT 4 (SR3) absolviert, da sich
hier die JVM (Symantec JIT 300.009) am schnellsten erwies. Das Programm lief
ebenfalls unter Linux (Kernel 2.0.32 JDK 1.1.4) und MacOS 8.1 (Apple MRJ 2.2).
Nachteile Die Performanz eines Java Programms ist stark von der verwendeten
JVM abhängig. So zeigte sich, dass die virtuellen Maschinen für die jeweiligen
Betriebssysteme äußerst unterschiedlich implementiert waren. Beste Ergebnisse konnten mit einem JIT (Just–In–Time Compilern) unter MS–Windows erreicht
werden. Ein JIT kompiliert Programmteile während des Laufs (just–in–time) vom
Bytecode in den jeweiligen plattformabhängigen Bitcode und führt diesen dann
aus. Dies bringt — verglichen mit einer der interpretierten Ausführung — erhebliche Geschwindigkeitsvorteile. So war der JIT (Version i300.009) von Symantec unter MS–Windows NT um den Faktor 5 schneller als der Orginalinterpreter
von Sun. Trotzdem muss davon ausgegangen werden, dass Implementierungen in
C++ um den Faktor 3-4 schneller sind.
5
Bedienungshinweise zu M ISTRAL
Im folgenden Kapitel wird das Programm M ISTRAL beschrieben. Zunächst wird
der Aufbau eines Data Mining Laufes erläutert. Im Weiteren wird gezeigt, wie
sich mit M ISTRAL Data Mining Projekte definieren und durchführen lassen. Die
Ankopplung und Bearbeitung neuer Komponenten wird ebenso beschrieben. Weiter werden die Anwendungszwecke der M ISTRAL Werkzeuge (Taxonomies und
CheckSupport) und gezeigt. Den Abschluss bildet die Definition der benutzten
Dateiformate.
5.1 Aufbau eines Data Mining Laufes
Die Durchführung eines Data Mining Laufes teilt sich in folgende Schritte auf:
1. Transformation der Datenbasis
2. Voranalyse der Daten
3. Definition eines Projekts
4. Projektdurchführung
5. Sichten und Interpretieren der Ergebnisse
Im momentanen Entwicklungsstadium unterstützt M ISTRAL nur den 3. und
4. Punkt dieser Aufzählung. Die restlichen Punkte müssen also von externen
69
70
5. Bedienungshinweise zu M ISTRAL
Programmen erledigt werden. Durch die Implementierung weiterer M ISTRAL –
Komponenten sind diese Aufgaben aber auch in M ISTRAL integrierbar.
Transformation der Datenbasis
Nach dem Verständnis der Domäne wird zunächst einmal eine Auswahl aus der
Datenbasis getroffen. Diese Selektion kann Teilmenge der vorhandenen Transaktionen bedeuten oder aber auch nur bestimmte Attribute der Transaktionen betrachten. Nicht immer liegen die Daten in einem M ISTRAL kompatiblen Format
vor. Es ist also eine Transformation in ein Format nötig, das eine gekoppelte
DataFetcher-Komponente lesen kann.
Abbildung 5.1: Das Programm M ISTRAL
Voranalyse der Daten
Bevor man mit dem eigentlichen Data Mining beginnt, ist es häufig sinnvoll, in
einer Voranalyse die Daten zu untersuchen. Dabei betreibt man das angestrebte
Projekt auf einer kleinen Testmenge der Datenbasis, die zufällig bestimmt werden
sollte. Gefundene Grenzwerte — also zum Beispiel besonders starke oder besonders schwache Regeln — sollten überprüft werden. Zur Überprüfung häufiger
Artikelmengen bietet sich zum Beispiel das in M ISTRAL integrierte Werkzeug
M ISTRAL C HECK an. Anhand dieser Ergebnisse kann abgeschätzt werden, wie
das tatsächliche Projekt resultieren wird.
Definition eines Projekts
Um ein Data Mining Projekt zu definieren, müssen bestimmte Komponenten ausgewählt werden: Eine DataFetcher Komponente, welche die Daten bereitstellt,
5.2. Menüstruktur von M ISTRAL
71
ein Algorithmus, der die Daten verarbeitet, und eine Anzahl von Viewer Komponenten zur Darstellung und Speicherung der Ergebnisse. Die Definition eines
Projekts wird in Abschnitt 5.3 näher besprochen.
Projektdurchführung
Nachdem die Komponenten für das Projekt bestimmt worden sind, kann das Projekt gestartet werden. Zuvor bietet es sich jedoch an, die Definitionen in einer
Projektdatei zu speichern. Hierfür dient die Menüoption File/Save....
Sobald das Projekt gestartet ist, kann man unter Project/Summary den aktuellen Status des Projektlaufs abfragen. Hier sind auch die eingestellten Parameter
der einzelnen Projektkomponenten einsehbar. Der Data Mining Lauf ist beendet,
sobald in der Statusleiste die Meldung Project finished. angezeigt wird.
Sichten und Interpretieren der Ergebnisse
Nachdem das Projekt abgeschlossen ist, müssen die Ergebnisse gesichtet und interpretiert werden. Es bietet sich an, als Viewer auch den Textfile Viewer
(Tabulator Style) zu verwenden. Hier werden die erzeugten Regeln spaltenweise in eine Textdatei geschrieben. Dadurch ist ein späterer Import in eine
Tabellenkalkulation wie zum Beispiel MS-Excel problemlos möglich.
Die aufbereitete Präsentierung der Regeln vereinfacht die Interpretation durch den
Anwender.
5.2 Menüstruktur von M ISTRAL
Die einzelnen Menüs von M ISTRAL gliedern sich logisch in folgende Unterpunkte:
File Hier kann ein neues Projekt erstellt (New), ein bereits erstelltes Projekt
geladen (Open) oder gespeichert werden (Save). Der Menüpunkt Exit
speichert alle getroffenen Einstellungen und beendet das Programm.
Project Dieses Menü dient zur Erstellung eines neuen Projektes. Ein bereits definiertes Projekt kann hier ebenso verändert werden. Der Project
Wizard führt durch die komplette Definition eines Data Mining Projekts
und ist Anfängern zu empfehlen. Manuell können die zu verwendenden
Komponenten in den Menüpunkten DataFetcher, Algorithm und
Viewer erreicht werden. Der Menüpunkt Summary gibt eine Zusammenfassung über die getätigten Projekteinstellungen und Run schließlich startet
das aktuelle Projekt.
72
Components Hier können die MISTRAL Komponenten an– oder abgekoppelt werden. Jede Art von MISTRAL Komponente ist hier mit einem eigenen
Menüpunkt vertreten.
Tools Das Tools Menü beinhaltet verschiedene Werkzeuge, die während
eines Data Mining Prozesses nützlich sind. So zeigt Taxonomies die
Baumstruktur von Taxonomien an. Check Support wiederum berechnet den Support von bestimmten Artikelmengen in zu spezifizierenden Datensätzen. Auf das Tools–Menü wird in 5.5 detaillierter eingegangen.
Help Das Help Menü bietet momentan nur einen About Dialog an, der
die Version und das Logo von M ISTRAL zeigt.
5.3 Definition eines M ISTRAL Projekts
Zur Definition eines M ISTRAL Projekts müssen die drei Schlüsselkomponenten
bestimmt werden: DATA F ETCHER, A LGORITHM und V IEWER. Die Festlegung
der gewünschten Komponenten kann im Menü Project durchgeführt werden.
Die Abbildung 5.2 zeigt die Definition einer Algorithmus Komponente.
Um eine andere Komponente festzulegen, wählt man den Select Schalter. Die
Komponenten DATA F ETCHER und A LGORITHM erlauben hierbei nur Einfachauswahl, während bei der Definition der V IEWER Komponente Mehrfachauswahl
möglich ist. So können zum Beispiel die Ergebnisse durch einen W INDOW V IEWER in einem Fenster dargestellt werden. Gleichzeitig schreibt ein T EXTFILE V IEWER die Ergebnisse in eine Datei.
Hinweis Durch die Implementierung in Java treten zwei Besonderheiten bei der
Bedienung auf: Werden in den Textfeldern Eingaben getätigt, so müssen diese
immer mit ENTER bestätigt werden. Weiter dient der forward-slash / als einheitliches Trennzeichen für Dateipfade (also D:/Daten anstelle von D:nDaten).
5.4 Arbeiten mit M ISTRAL Komponenten
M ISTRAL Komponenten bestimmen die wesentliche Funktionalität des Data Mining Werkzeugs. Durch das einfache An– und Abkoppeln der Komponenten in
M ISTRAL ist diese Funktionalität sehr flexibel an ein bestehendes Data Mining
Problem anpassbar.
5.4. Arbeiten mit M ISTRAL Komponenten
73
Abbildung 5.2: Projektdefintion (DBCDataFetcher)
5.4.1 Koppeln
M ISTRAL kann problemlos weitere Komponenten aus den Bereichen DATA F ETCHER , A LGORITHM und V IEWER aufnehmen. Wie neue Komponenten aufgebaut
sein sollten, kann in Abschnitt 4.2.4 detailliert nachgelesen werden. Zur Ankopplung und Bearbeitung der vorhandenen Komponenten dient das Components
Menü.
Die Abbildung 5.3 zeigt das Bearbeitungsfenster der A LGORITHM Komponente.
Allgemein lassen sich in den Bearbeitungsfenstern neue Komponenten ankoppeln
(Add), vorhandene Komponenten aus M ISTRAL löschen (Remove) und Informationen über die gerade angewählte Komponente anzeigen (About).
Soll eine neue Komponente in M ISTRAL aufgenommen werden, so muss der Add
Schalter in einer der Components Menüs gedrückt werden. Ein Eingabefenster
fragt nach der URL der anzukoppelnden Komponente. Diese URL entspricht dem
Klassennamen, dem sein Paketname vorausgeht.
Beispiel Wollte man etwa die neue Komponente A PRIOR I NTERVAL mit gleichem Klassennamen und Paketzugehörigkeit M ISTRAL C OMPONENTS in M I STRAL einhängen, so müsste die URL MistralComponents.ApriorInterval lauten. Es wird davon ausgegangen, dass die Klasse in einem erreichbaren Java–
Klassenpfad untergebracht ist.
74
Abbildung 5.3: Bearbeiten von M ISTRAL Komponenten
5.4.2 Vorhandene Komponenten
Die Eigenschaften der schon in M ISTRAL integrierten Komponenten soll hier kurz
vorgestellt werden:
DataFetcher
– TextDataFetcher Damit können flache Textdateien eingelesen werden. Eine detaillierte Beschreibung des verwendeten Dateiformats
wird in Abschnitt 5.6 gegeben.
– DBCDatafetcher Diese Komponente bietet eine Anbindung an Datenbanken mit JDBC/ODBC Schnittstelle. Durch Angabe des installierten Datenbanktreibers und der Datenbankquelle (URL) kann jede
JDBC/ODBC Datenbank an M ISTRAL gekoppelt werden. Ein zu spezifizierender SQL Befehl steuert hierbei das Auslesen der Daten.
Algorithmen
– Cumulate Ein Algorithmus zum Finden von (generalisierten) Assoziationsregeln. Er wurde erstmals in [SA95] vorgestellt.
– ApriorInterval Im Wesentlichen dem C UMULATE–Verfahren gleich.
Zusätzlich kann hier eine obere Support–Schranke angegeben wer-
5.5. Das Tools Menü
75
den, welche die häufigen Artikelmengen bzw. Regeln einschränkt.
Näheres hierzu in Abschnitt 7.2 (Seite 96).
– FrequentSets Ein Verfahren zur Bestimmung häufiger (generalisierter) Artikelmengen.
– ItemDistribution Dieser Algorithmus liest die komplette Datenbank
ein und berechnet die Häufigkeit aller vorhandenen Einzelartikel.
– DummyAlgorithm Dieser Algorithmus bewirkt nichts. Er schleust
die Daten, die er von der DataFetcher Komponente geliefert bekommt,
gleich an den Viewer weiter. D UMMYA LGORITHM kann in Verbindung mit der TEXTFILE V IEWER (M ISTRAL S TYLE ) Komponente dazu genutzt werden, Daten aus fremden Datenquellen in eine flache,
DataFetcher kompatible, Textdatei zu konvertieren.
Viewer
– WindowViewer Dieser Viewer gibt die Ergebnisse in einem Fenster
aus. Allerdings empfiehlt sich die Benutzung von WindowViewer nur
bei kleinen Resultatmengen.
– TextfileViewer Hier werden die Verbalisierungen der möglichen Resultate (wie Regeln oder häufige Artikelmengen) in eine einfache Textdatei geschrieben.
– TextfileViewer (Mistral Style) Wenn Resultate Transaktionen sind,
dann werden diese im TextDataFetcher Format geschrieben. Ansonsten wie bei TextfileViewer.
– TextfileViewer (Tabulator Style) Wenn die Resultate Regeln sind,
dann werden diese in einem tabellenähnlichen Format geschrieben.
Ansonsten wie bei TextfileViewer.
5.5 Das Tools Menü
Zum Verständnis der Daten hält M ISTRAL einige Werkzeuge bereit, die direkt aus
dem Programm gestartet werden können:
Taxonomies
Zwischen Artikeln können Hierarchien, sogenannte Taxonomien, gebildet werden. Milchprodukte ist dann z. B. eine Übergruppe von Milch, welche ihrerseits
wieder eine Übergruppe von H–Milch ist. Solche Taxonomien werden mit Hilfe einer Taxonomiedatei bei einigen Algorithmen (z.B. C UMULATE ) angegeben.
76
Um einen Überblick über die definierten Hierarchien zu gewinnen, können die
Taxonomiebäume mit dem Tool TAXONOMIES angezeigt werden.
Abbildung 5.4: Tool Taxonomies
Check Support
Zur Voranalyse oder auch zur Kontrolle der Ergebnisse kann das Tool C HECK
S UPPORT dienen. Hier wird eine im TextDataFetcher Format gespeicherte Datei
als Datenbasis angegeben. Eine spezifizierte Artikelmenge wird daraufhin von
diesem Tool in der Datenbasis gesucht. Nach dem erfolgreichen Lauf durch die
Daten wird der Support der angegebenen Artikelmenge berechnet und ausgegeben. Auf diese Weise lassen sich einzeln häufige Artikelmengen und Konfidenzen
von Regeln berechnen bzw. überprüfen.
5.6 Dateiformat: TextDataFetcher
Oftmals ist es nötig, die Daten aus einem proprietären Datensystem in eine flache
Textdatei zu überführen. Dadurch wird die folgende Transformation der Daten
meist erst ermöglicht oder zumindest vereinfacht. Die Komponente TEXT DATA F ETCHER bildet das Bindeglied zwischen solchen Textdateien und dem M ISTRAL
Kern. Das Format ist denkbar einfach:
Jede Zeile besteht aus genau einer Transaktion. Die Einträge in dieser Zeile sind
durch Tabulatoren getrennt. Dabei wird der erste Eintrag als Transaktionsidentifikation (TID) interpretiert. Die folgenden Einträge stellen die verschiedenen
Artikel dar.
5.7. Dateiformat: Taxonomie-Definition
77
TID1 [<--TAB]Artikel1 [<--TAB]Artikel2
TID2 [<--TAB]Artikel2 [<--TAB]Artikel3
TID3 [<--TAB]Artikel1
..
.
Abbildung 5.5: Format TextDataFetcher
5.7 Dateiformat: Taxonomie-Definition
Taxonomien werden in Dateien definiert. Dabei muss der komplette Hierarchiewald in einer Datei abgelegt sein. Die einzelnen Bäume werden durch eine Zeile
getrennt, die den Bezeichner [NEWTREE] enthält. Auch die letzte Baumdefinition in der Datei sollte mit dieser Zeile enden.
Zwischen zwei [NEWTREE] wird der eigentliche Baum definiert: Jede Zeile
enthält genau einen Ursprungs- und einen Endknoten, die beide durch einen Tabulator getrennt sind. Der erste Knoten einer Baumdefinition kennzeichnet dabei
die Wurzel. Sonst gilt folgende Grundregel: Jeder Knoten auf der linken Seite
muss zuvor (in einer vorhergehenden Zeile) schon einmal als Endknoten auf der
rechten Seite definiert worden sein. Der Baum aus Abbildung 5.4 müsste also so
beginnen:
[NEWTREE]
Milchprodukte
Milchprodukte
Milch
Milch
H–Milch
H–Milch
Jogurt
Jogurt
..
.
[<--TAB]
[<--TAB]
[<--TAB]
[<--TAB]
[<--TAB]
[<--TAB]
[<--TAB]
[<--TAB]
Milch
Jogurt
Fit–Milch
H–Milch
H–Milch1.5%
H–Milch0.2%
JogurtNatur
JogurtGeschmack
[NEWTREE]
Abbildung 5.6: Format Taxonomie Definition
78
6
Auswertung der Daten und
Ergebnisse
Um die Korrektheit und Leistungsfähigkeit von MISTRAL zu zeigen, wurden die
ersten Programmläufe mit synthetisch erzeugten Daten durchgeführt. Dabei handelte es sich um künstlich generierte Transaktionen aus der Warenkorbdomaine.
Später wurden Daten aus zwei realen Anwendungsbereichen untersucht. Beide ließen sich ebenfalls auf die Transaktionsebene transformieren. Eine Datenbank beinhaltete Ergebnisse von Abgas–Katalysatortests der Firma Degussa AG
(Hanau–Wolfgang), während die andere Datenbank aus der Warenwirtschaft der
Firma Quitmann (Hagen) stammte. Beide Datenbanken sind unterschiedlich dimensioniert und verfügen über entgegengesetzte Datencharakteristika.
Von besonderem Interesse war auch die Frage, inwieweit sich die Standardverfahren auf eine diagnostische Domäne anwenden lassen. Hierfür wurden Fälle aus
einer Wissensbasis zur Pflanzenerkennung herangezogen.
6.1 Synthetische Daten
Die Evaluation des Data Mining Programms M ISTRAL wurde mit synthetischen
Daten durchgeführt. So wurden Datensätze mit unterschiedlicher Größe, aber
gleicher Charakteristik generiert. Als Charakteristik konnte der Support einiger
ausgezeichneter Artikelmengen bestimmt werden. Alle übrigen freien Artikelpositionen wurden in der Datenbank durch Dummy-Artikel aufgefüllt. Durch die
Festlegung des Supports konnte auch die Konfidenz von Regeln vordefiniert wer79
80
6. Auswertung der Daten und Ergebnisse
den. Denn die Konfidenz einer Regel A ) B berechnet sich aus dem Support der
Artikelmengen fAg und fA; B g.
Baum
Tiefe Blätter
Milchprodukte
3
15
Gemüse
2
5
Obst
2
6
Brot
2
6
Süsswaren
2
8
Wurst
2
3
Nudel
1
4
Frühstück
2
5
Getränke
4
10
Abbildung 6.1: Taxonomiebäume der synthetischen Daten
Die Transaktionsgröße wurde sowohl poissionverteilt (mit Mittelwert = 10)
als auch gleichverteilt (pro Transaktion 10 Artikel) gewählt. Für jede Verteilung
entstanden jeweils fünf Datensätze zu 1000 (1K), 5000 (5K), 10000 (10K), 50000
(50K) und 100000 (100K) Transaktionen. Jeder Datensatz verfügte über 1055 verschiedene Einzelartikel, 55 ausgezeichnete und 1000 zufällige Füllartikel. Die 55
ausgezeichneten Artikel wurden mit Namen aus der Warenkorbdomäne beschriftet.
Transaktionen Verteilung Artikelzahl Trans.größe
gleich
10000
10.0000
1K
poisson
9908
9.9080
gleich
50000
10.0000
5K
poisson
49900
9.9800
gleich
100000
10.0000
10K
poisson
99897
9.9897
gleich
500000
10.0000
50K
poisson
499951
9.9990
gleich
1000000
10.0000
100K
poisson
999902
9.9990
Abbildung 6.2: Größe der synthetischen Daten
Abbildung 6.2 zeigt für jeden Datensatz die Anzahl der darin enthaltenen Artikel.
6.1. Synthetische Daten
81
Die durchschnittliche Transaktionsgröße definiert sich aus dem Quotienten der
Transaktionenanzahl und der Artikelanzahl.
Transaktionen Verteilung
gleich
1K
poisson
gleich
5K
poisson
gleich
10K
poisson
gleich
50K
poisson
gleich
100K
poisson
Dateigröße Zeit (m. Tax.) Zeit (o. Tax.)
75 548 Byte
20,17 min.
1,27 min.
71 968 Byte
22,71 min.
1,31 min.
378 246 Byte
32,36 min.
4,76 min.
367 749 Byte
30,75 min.
4,57 min.
756 658 Byte
43,53 min.
10,27 min.
744 270 Byte
43,76 min.
10,04 min.
3 782 862 Byte
152,63 min.
45,42 min.
3 733 776 Byte
152,63 min.
44,02 min.
7 565 725 Byte
338,33 min.
95,18 min.
7 467 553 Byte
320,30 min.
88,06 min.
Abbildung 6.3: Performanz von M ISTRAL mit synthetischen Daten (Tabelle)
Zusätzlich wurden für die 55 ausgezeichneten Artikel noch Generalisierungen
in Form von neun Taxonomiebäumen verfügbar gemacht. Die Tiefe und der
Blätterbestand der einzelnen Bäume ist in Abbildung 6.1 verzeichnet.
350
gleichverteilt (mit Tax.)
poisson verteilt (mit Tax.)
gleichverteilt (ohne Tax.)
poisson verteilt (ohne Tax.)
300
Zeit (min.)
250
200
150
100
50
0
0
10
20
30
40
50
60
70
Datenbankgroesse (in KB)
80
90
100
Abbildung 6.4: Performanz von M ISTRAL mit synthetischen Daten (Graphik)
Zur Evaluation wurden die 10 Datensätze sowohl mit Taxonomien als auch ohne
Angabe von Taxonomien untersucht. Da die Charakteristik der Daten (Häufigkeit
82
der Artikelmengen) bekannt war, konnten Korrektheit und Vollständigkeit der Regeln überprüft und bestätigt werden. Folglich erzeugt M ISTRAL auch für alle
Datengrößen die gleichen Regeln.
Die Tabelle in Abbildung 6.3 zeigt die Performanz der Implementierung in den
unterschiedlichen Testläufen. Abbildung 6.4 zeigt sehr deutlich, wie der Zeitbedarf fast linear mit der Datenbankgröße zunimmt. Der etwas höhere Zeitbedarf
der gleichverteilten Daten im Vergleich zu den poissonverteilten Transaktionen
lässt sich mit dem entsprechend größeren Datenumfang begründen. Die gleichverteilten Daten enthalten jeweils geringfügig mehr Artikel in den Transaktionen
als die poissonverteilten Datensätze. Dies verdeutlicht die Tabelle in Abbildung
6.2. Eine weitere interessante Eigenschaft lässt sich in Abbildung 6.4 beobachten: Der Zeitbedarf der Testläufe mit Taxonomien steigt merklich steiler an als
der Zeitbedarf der Testläufe ohne Verwendung von Taxonomien. Einen parallelen Verlauf zu den Kurven ohne Taxonomien würde man zuerst erwarten. Diese
Kurven erklären sich aber in folgender Weise: Die Verfahren müssen bei Taxonomien nicht einfach nur mehr Artikel verarbeiten, sondern fügen auch bei jedem
Datenbankdurchlauf in jeder Transaktion die Vorfahren hinzu. Nach jedem Datenbankdurchgang werden die nicht mehr benötigten Vorfahren eliminiert. Dies
schlägt sich in dem wesentlich höher gemessenen Zeitbedarf nieder.
6.2. Katalysator-Testfahrten der Degussa AG
83
6.2 Katalysator-Testfahrten der Degussa AG
Die Degussa AG (Deutsche Gold- und Silber-Scheideanstalt) feierte 1998 ihr 125–
jähriges Bestehen und ist vielen als Edelmetallverarbeiter ein Begriff. Seit 1968 ist
die Degussa jedoch auch in der Entwicklung von Autoabgas-Katalysatoren tätig.
Heute hält sie als Lieferant für diese Katalysatoren 20% des Weltmarktanteils.
Die Entwicklung neuer Katalysatoren umfasst viele Einzelschritte und eine Anzahl von Tests und Auswertungen. Am Ende dieser Kette stehen Testfahrten, die
ein Katalysator — in einen realen PKW eingebaut — auf dem Rollband absolvieren muss. Bei jeder Testfahrt entsteht eine Vielzahl von Meßergebnissen.
Die untersuchten Daten stellen eine Teilmenge dieser Testfahrten dar. Der Datensatz lag in einer relationalen Datenbank (MS-Access) vor und umfasste 2769 Testfahrten aus den Jahren 1996 und 1997. Für jede Fahrt wurden 18 Attribute erfasst,
die sich wie folgt aufschlüsseln: Datum der Fahrt, Motortyp (Otto/Diesel), Motornummer (Art und Größe des Motors), Fahrer, Analytiker, weitere Parameter,
die den Katalysator beschreiben und vier Auswertungsergebnisse der Testfahrt.
Die Inhalte und Namen der Felder wurden teilweise verschlüsselt, da es sich um
betriebssensible Daten handelt.
6.2.1 Vorverarbeitung der Daten
Fachleute der Degussa AG überführten die quantitativen Attribute in Intervalle,
die mit Buchstaben oder Zahlen symbolisiert wurden. Taxonomien waren nicht
bekannt. Da die Testfahrten in einer relationalen Datenbank vorlagen, gestaltete
sich die Vorverarbeitung sehr einfach: Jede Testfahrt wurde als eine Transaktion betrachtet, deren Artikel sich als Kombination des Feldnamens und des Feldwerts definierten. So entstanden beispielsweise die Artikel DATUM-19970228
oder FAHRER NR-6.
Durch die obige Transformation entstanden 737 verschiedene Einzelartikel (Ausprägungen der Feldnamen), verteilt auf 2769 Transaktionen. Jede Transaktion
enthielt genau 18 Artikel und eine fortlaufende Zahl als Transaktionsidentifikation
(TID).
84
6.2.2 Ergebnisse
Es ist leicht ersichtlich, dass der zeitliche Ausschnitt von nur zwei Jahren die
Vielfalt der Attributverteilung begrenzt. Gespeichert wurden im Grunde genommen die Entwicklung weniger Katalysator–Typen und deren verschiedene Prototypenergebnisse. Daher variieren die Attributkombinationen meist nur minimal.
Hieraus folgt aber, dass sehr viele Artikelkombinationen als ,,häufig” gekennzeichnet werden. So überraschten die vielen Regeln trotz hoher Support– und
Konfidenzwerte wenig.
2000
1600
Konfidenz 70%
Konfidenz 80%
Konfidenz 90%
400
Anzahl der Regeln
Anzahl der Regeln
450
Konfidenz 70%
Konfidenz 80%
Konfidenz 90%
1800
1400
1200
1000
800
600
350
300
250
200
150
400
100
200
50
0
0
30
40
50
60
70
Support (in %)
80
90
100
40
50
60
70
80
Support (in %)
90
100
Abbildung 6.5: Anzahl der Regeln (Degussa Testfahrten)
Die Abbildung 6.5 zeigt, wie die Anzahl der Regeln bei fester Konfidenz und
variablem Support variiert. Dabei sind die Werte für eine feste Konfidenz von
70%, 80% und 90% aufgetragen.
Man sieht, dass die Anzahl der Regeln unter einem Support von etwa 60% nicht
mehr für eine manuelle Auswertung geeignet ist. Ebenso ist deutlich zu erkennen,
dass die Regelgröße unter 40% Support exponentiell ansteigt.
Eine Vorstellung von der Regelgröße gibt die folgende Tabelle in Abbildung 6.6,
welche die Größe der Regeln nach Support und Konfidenz aufgeschlüsselt darstellt. Dabei bedeutet 2er Regel, dass die Regel von zwei Artikeln aufgespannt
wird (z.B. MOTOR TYP-C ) KAT ERGEBNIS-A).
Die gefundenen Regeln wurden von Degussa wieder rekodiert und bewertet. Zum
Zeitpunkt der Drucklegung der vorliegenden Arbeit war die Auswertung der Ergebnisse noch nicht fertiggestellt. Eine Bewertung der Regeln ist also leider nicht
möglich.
6.3. Die Warenwirtschaft der Firma Quitmann
85
Anzahl der Regeln nach Regelgröße
Konfidenz
Support
2er
3er
4er
Gesamt
70%
60%
70%
80%
90%
60%
70%
80%
90%
60%
70%
80%
90%
17
12
8
4
14
11
8
4
12
9
7
4
55
36
9
0
37
25
9
0
31
19
7
0
58
40
0
0
33
18
0
0
30
15
0
0
130
88
17
4
84
54
17
4
73
43
14
4
80%
90%
Abbildung 6.6: Verteilung der Regelgrößen (Degussa)
6.3 Die Warenwirtschaft der Firma Quitmann
Als mittelständischer Betrieb aus Hagen mit 85 Mitarbeitern und 25 Millionen DM Umsatz im Jahr vertreibt die Firma Quitmann Büroeinrichtungen, –
maschinen und –bedarf. Alle Aufträge werden in einem Warenwirtschaftssystem
erfasst und gespeichert. Im Rahmen dieser Arbeit sollte die Abteilung Bürobedarf
untersucht werden, da sich die Firma hier interessante Ergebnisse versprach.
Die elektronische Erfassung der Warenwirtschaft wird durch das System UBIS
der Firma Haas aus Gummersbach geregelt. Da das System bis jetzt noch eine proprietäre, filesystem-ähnliche Datenhaltung einsetzt, mussten die Daten in
eine flache Textdatei exportiert werden. Diese enthielt Umsatz und Rohgewinn
aller Kunden in den Jahren 1996 und 1997, aufgeschlüsselt in die sieben Bereiche
des Unternehmens: Möbel, Bürobedarf, Kopierer, Computer, Postbearbeitungsmaschinen, sonstige Maschinen und technischer Kundendienst.
Ausgehend von dieser gut 255 MB großen Datei mit 785246 Zeilen wurde eine
Konvertierung in ein M ISTRAL kompatibles Format durchgeführt. Weiter wurden die Aufträge nach Kundennummer und Auftragsdatum sortiert. Aufträge
der gleichen Kunden selben Datums wurden zusammengeführt. Als Transakti-
86
ons ID wählte man eine Kombination zwischen Kundennummer und Auftragsdatum. Übrig blieb eine knapp 6 MB große Textdatei mit 121412 Transaktionen, die
durch 25196 Einzelartikel aufgespannt wurden. Die durchschnittliche Transaktionsgröße betrug 3,22 Artikel.
Eine weitere Datei wurde bereitgestellt, die alle Artikel aus der Abteilung Bürobedarf in 42 Produktgruppen unterteilte. Diese wurden benutzt, um alle Artikel aus den Transaktionen zu entfernen, die keiner Bürobedarf –Produktgruppe
zugehörig waren. Daraufhin artikellose Transaktionen wurden entfernt. Dies
dezimierte die Transaktionenzahl von 121412 auf 70309 Datensätze mit 9803
Einzelartikeln. Die durchschnittliche Transaktionsgröße blieb mit 3,28 Artikeln
etwa gleich. Dies erklärt sich daraus, dass Transaktionen ohne Bürobedarf–
Produktgruppen in der Regel sehr klein waren (1–2 Artikel) und sich damit
die durchschnittliche Transaktionsgröße erst einmal erhöhte. Weil die ,,Nicht–
Bürobedarfs–Artikel” aus den verbliebenen Transaktionen allerdings entfernt
wurden, verringerte sich aber die Transaktionsgröße wieder.
6.3.2 Ergebnisse
Die Anzahl der verwendeten Einzelartikel (9803 Artikel), die sich auf nur 70309
Transaktionen verteilen, und die kleine durchschnittliche Transaktionsgröße von
3,28 Artikeln ließen keine großen Erwartungen bezüglich der zu findenden Regeln
aufkommen. Bei einem ersten Testlauf stellte sich heraus, dass nur 22 Einzelartikel (0.2% von 9803) einen Support von 0.5% erreichen würden. Kombinationen
zwischen diesen ,,häufigen” Artikeln ließen den Support weiter drastisch fallen
(unter 0.02% Support), so dass an eine Regelgenerierung nicht mehr zu denken
war. Durch die Verwendung der Produktgruppen als Artikel-Taxonomien konnten
jedoch in der Voranalyse einige häufige Artikelmengen gefunden werden.
Daraufhin wurde ein Data Mining Lauf mit 0.3% Support und 60% Konfidenz
durchgeführt. Das Verfahren CUMULATE entdeckte 719 Regeln, die in Abbildung
6.7 nach ihrer Größe und Anzahl detailliert aufgeschlüsselt werden.
Die Graphik in Abbildung 6.8 zeigt, wie die Anzahl der Regeln in gleicher Weise,
ihrem Konfidenzwert entsprechend, zunehmen.
Eine Auswertung der Firma Quitmann zeigte, dass besonders 2er Regeln (Regeln
mit nur einer Vorbedingung und einer Nachbedingung) und Regeln mit Einzelartikeln von Interesse waren. Assoziationsregeln mit größeren Vor– und Nachbedingungen, die ausschließlich aus Produktgruppen bestanden, ließen keine befriedigende Analyse der Zusammenhänge zu.
6.3. Die Warenwirtschaft der Firma Quitmann
87
Anzahl der Regeln pro Regelgröße
Konfidenz
Support
2er
3er
4er
5er
6er
Gesamt
60%
0.3%
0.6%
1.0%
0.3%
0.6%
1.0%
0.3%
0.6%
1.0%
51
10
3
11
1
0
0
0
0
155
65
42
67
24
13
9
3
0
256
110
43
156
64
27
62
21
6
213
37
0
146
19
0
78
12
0
44
0
0
25
0
0
10
0
0
719
222
88
405
108
40
159
36
6
70%
80%
Abbildung 6.7: Verteilung der Regelgrößen (Quitmann)
Nachdem die Regeln des vorherigen Data Mining Laufs nach diesen Kriterien gefiltert worden waren, verblieben 110 Assoziationen in der Ergebnismenge. Darin
waren 54 2er Regeln, 53 3er Regeln und drei 4er Regeln enthalten.
Bis auf zwei Ausnahmen bildeten die 2er Regeln grundsätzlich Einzelartikel auf
die Produktgruppe [101] (Ordnungsmittel) ab. Dies ist wenig verwunderlich, da
diese Produktgruppe mit einem Support von 49.68% in der Datenbasis außerordentlich stark vertreten ist. Nur zwei Regeln zeigten Assoziationen zwischen zwei
Produktgruppen:
(Rund um den Schreibtisch) ) (Ordnungsmittel) [sup: 3,57%; con: 61,86%]
(KL-Rund um den Schreibtisch) ) (Ordnungsmittel) [sup: 1,05%; con: 61,82%]
Das Präfix KL bezeichnet eine Produktgruppe, deren Artikel nicht auf Lager waren
und somit bestellt werden mussten. Ebenso waren Regeln mit hoher Konfidenz
von Interesse. Die Regel
DOR9778 ) (Rund um den Schreibtisch) [sup: 0,34%; con:78,18%]
beispielsweise hatte den höchsten Konfidenzwert aller 2er Regeln. Der Einzelartikel DOR9778 gliedert sich in die Produktgruppe (Schreiben/Zeichnen (Büro))
ein.
Als Folgerung auf die gefundenen Regeln und die Ergebnisse der Auswertung
überlegt die Firma Quitmann momentan, ihren Warenkatalog umzustellen. Artikel bzw. Produktgruppen, die häufig miteinander konsumiert werden, sollen dann
88
Konfidenz 60%
Konfidenz 70%
Konfidenz 80%
Anzahl der Regeln
140
120
100
80
60
40
20
0
0
0.5
1
1.5
2
Support (in %)
2.5
3
Abbildung 6.8: Anzahl der Regeln (Quitmann)
auch nahe beieinander im Katalog vertreten sein, um so dem Kunden die Bestellung zu erleichtern. Langfristig wird eine Überprüfung der Produktstandorte im
Ladengeschäft angestrebt. Auch hier sollen assoziative Artikel und Produktgruppen näher zusammenrücken.
6.4 Pflanzenwissensbasis
Als Beispiel für eine Datensammlung in diagnostischer Domäne wurde eine Pflanzenwissensbasis aus dem Expertensystem D3 [PGPB96] verwendet. Diese Wissensbasis wurde im Rahmen einer Praktikumsarbeit (siehe dazu auch [Ern96]) erstellt und beinhaltet 13101 Fälle. Jeder Fall ist hierbei in 3 Fragebögen (,,Blüte”,
,,Blätter”, ,,Stengel”) aufgeteilt, die zusammen 40 Merkmalsbeschreibungen umfassen. Darüber hinaus ist zu jeder Pflanze eine Abbildung verfügbar.
Für den Data Mining Lauf wurden die Fälle in eine flache Textdatei exportiert.
Jeder Fall erhielt eine eigene Zeile, welche eine eindeutige Fallidentifikation, eine
Diagnose des Pflanzentyps und 40 Merkmalsausprägungen enthielt. Die Datenbasis wurde somit in ein transaktionelles Format mit 41 Artikeln und einer ID pro
Transaktion überführt.
6.4. Pflanzenwissensbasis
89
6.4.2 Ergebnisse
Es sind 74 verschiedene Diagnosen und 102 verschiedene Merkmalsausprägungen
in der Datenbasis gespeichert. Da Regeln mit Diagnoseattributen von besonderem
Interesse waren, wurde die Verteilung der 74 Diagnosen näher betrachtet.
Die häufigste Diagnose ist mit 396 Fällen (3,02% Support) in der Wissensbasis
gespeichert. Die seltenste Diagnose ist nur mit 125 Fällen vertreten, was einem
Support von circa 0,95% entspricht. Damit also alle Diagnosen in den zu generierenden Regeln vertreten wären, müsste der minimale Support unter 0.95% gesetzt
werden.
Die Anzahl der Attribute pro Fall und einige Voranalysen ließen eine große Anzahl von Regeln vermuten. Daher wurden zunächst alle Fälle mit der Diagnose p6355 (Duftlose Kamille Matricaria inodora) aus der Wissensbasis extrahiert. Diese Testmenge sollte probeweise untersucht werden. Die Diagnose p6355
wurde gewählt, da sie mit 396 Fällen am stärksten vertreten war. Der minimale
Support wurde auf 80%, die minimale Konfidenz auf 90% gesetzt. Der Testlauf
ermittelte 20768 Regeln, die diesen Schwellwert erfüllten; 10213 Regeln davon
beinhalteten die Diagnose. Einen genauen Überblick verschafft die Tabelle in Abbildung 6.9, welche die Diagnoseregeln nach ihrer Regelgröße aufschlüsselt. Die
Spalten Vorbedingung und Nachbedingung geben an, wieviele Regeln das Diagnoseattribut in der Vor– bzw. Nachbedingung beinhalten.
Anzahl der Regeln pro Regelgröße
2er Regel
3er Regel
4er Regel
5er Regel
Vorbedingung
Nachbedingung
Gesamt
11
194
1787
5182
8
124
888
2019
19
318
2675
7201
Abbildung 6.9: Verteilung der Regelgrößen (Pflanzen)
Es ist verständlich, dass die große Anzahl der Regeln für eine manuelle Auswertung unbrauchbar ist. Sogar die minimale Konfidenz von 100% wird immer noch
von 4926 Regeln erfüllt.
Testläufe mit anderen Diagnose-Clustern (bspw. mit dem Diagnoseattribut Kornblume Centaurea cyanus) errechneten eine ähnlich große Anzahl von Regeln.
Zusätzlich wurde ein Lauf mit dem Standardverfahren C UMULATE über der ge-
90
samten Datenbasis durchgeführt. Der minimale Support wurde auf 50% und die
minimale Konfidenz auf 70% gesetzt. Mit diesen hohen Schwellwerten erzeugte das Verfahren 409 Assoziationsregeln. Roman Ernst vom Biologischen Institut (Universität Würzburg), der die untersuchte Pflanzenwissensbasis erstellt hatte, sichtete die Resultate und bestätigte die Vermutung, dass nur triviale Zusammenhänge gefunden wurden. Als Beispiel soll folgende Regel aus der Ergebnismenge dienen:
netznervige oder fiedernervige Blattveratur ^ kein Stengelmilchsaft ^
kein gefärbter Milchsaft ) keine Blattranken [sup: 64,35%; con: 96,1%]
Diese Regel ist nicht besonders verwunderlich, da in der Natur die Attribute in
der vorliegenden Kombination häufig auftreten. Folglich assoziieren die Attribute
auch in der Wissensbasis stark.
Die erfolgreiche Implementierung des A PRIOR I NTERVAL –Verfahrens (siehe 7.2,
Seite 96) ermöglichte die Untersuchung der Datenbasis in einem beschränkten
Supportintervall.
Konfidenz
Regelanzahl
100%
17
95%
21
90%
22
85%
25
80%
25
75%
29
70%
32
Abbildung 6.10: Anzahl der Regeln nach Konfidenz (Pflanzen)
So wurde das zulässige Supportintervall auf [0,1%; 3,5%] gesetzt und eine minimale Konfidenz von 70% verlangt. A PRIOR I NTERVAL fand 32 Regeln, welche
die vorgegebenen Schwellwerte erfüllten.
32
Anzahl der Regeln
30
28
26
24
22
20
18
16
70
75
80
85
90
Konfidenz (in %)
95
100
Abbildung 6.11: Anzahl der Planzen–Regeln nach Konfidenz
Die Tabelle 6.10 schlüsselt die Anzahl der Regeln nach dem Konfidenzwert auf.
In Abbildung 6.11 ist die graphische Visualisierung dieser Tabelle zu sehen.
6.4. Pflanzenwissensbasis
91
Herr Roman Ernst bestätigte die gefundenen Regeln. Im Wesentlichen handelte
es sich hierbei um Regeln, die auch in der Wissensbasis eingegeben waren. Somit
konnte das Data Mining Verfahren zur maschinellen Wissens–Reproduktion dienen. Herr Ernst vermutete, dass die bestehende Datenbasis mit 13101 Fällen zu
klein für Zusammenhänge sei, die überraschend für einen Biologen wären.
92
7
Regelfindung in diagnostischen
Domänen
Die Anwendung des Verfahrens in diagnostischen Domänen, wie der PflanzenWissensbasis, konnte zu keinem befriedigenden Ergebnis führen. Der Grund
dafür liegt in der ungewöhnlichen Ausgangslage: Oftmals sind im Vergleich zur
traditionellen Warenkorbdomäne relativ wenige Transaktionen vorhanden. Zusätzlich ist das Ziel selten das Finden der häufigsten Korrelationen. Vielmehr sind
meist die oft auftretenden Assoziationen am wenigsten interessant. So treten beispielsweise in der Medizin häufige Symptome in vielen Diagnosen auf und sind
daher in einer Regel wenig bedeutungsrelevant. Interessanter wäre es also, Assoziationen mit vergleichsweise wenig Support, aber hoher Konfidenz zu finden.
Die bekannten Assoziationsregel–Verfahren in der aktuellen Forschung untersuchen nur das Finden von Regeln mit hohem Support und hoher Konfidenz. In den
folgenden Absätzen soll beschrieben werden, wie Regeln mit niedrigem Support,
aber hoher Konfidenz gefunden werden können.
7.1 Clusterbildung unter Verwendung von
Standardverfahren
Um schon bestehende Standardverfahren weiter verwenden zu können, müssten
die Daten zuvor in geeigneter Weise vorverarbeitet werden.
93
94
7. Regelfindung in diagnostischen Domänen
7.1.1 Vorgehensweise
Kennt der Anwender signifikante Untergruppen innerhalb der Datenbasis, so bietet es sich an, diese in Clustern zu gruppieren. Auf solche Weise ließe sich
beispielsweise in einer medizinischen Domäne nach Ausprägung der Diagnosen
gruppieren. Auf jeden einzelnen Cluster könnte dann ein Standardverfahren, wie
A PRIORI, zum Finden von Regeln verwendet werden. Nachdem die Regeln für
die einzelnen Cluster gefunden worden sind, werden sie in Bezug auf die gesamte
Datenbasis überprüft. Im Folgenden wird die Vorgehensweise näher betrachtet:
Clusterbildung
Bei dieser Vorgehensweise hat eindeutig die Vorverarbeitung, also die Clusterbildung, eine Schlüsselposition inne. Nicht immer ist es ersichtlich, ob vorgenommene Gruppierungen sinnvoll oder erfolgversprechend sind. Eine manuelle
Clusterbildung nach dem diagnostizierenden Attribut scheint hier jedoch am sinnvollsten. Das clusterbildende Attribut wird im folgenden als signifikantes Attribut
bzw. die Ausprägung als signifikanter Artikel bezeichnet.
Standardverfahren
Ein Standardverfahren, wie beispielsweise APRIORI, generiert für jeden Cluster
einzeln die entsprechenden Assoziationsregeln. Bei der Generierung der Regeln
sollte dann darauf geachtet werden, dass der signifikante Artikel stets enthalten ist.
Dadurch wird gesichert, dass nur für diesen Cluster interessante Regeln erzeugt
werden.
Abschließender Scan
Sind die Regeln für die jeweiligen Cluster generiert worden, so sollten sie im Kontext der gesamten Datenbasis überprüft werden. Die Dezimierung des Supportwertes bereitet aus oben angeführten Gründen keine Probleme. Der Veränderung
des Konfidenzwertes sollte aber Beachtung geschenkt werden:
Befindet sich der signifikante Artikel in der Vorbedingung der Regel, so bleibt
der Konfidenzwert im Vergleich Cluster $ Gesamtdaten gleich. Dies ist leicht
ersichtlich, da der signifikante Artikel als einziger in dem berechneten Cluster
enthalten gewesen sein kann. Folglich muss der Konfidenzwert gleich bleiben.
Auf eine interessante Regel deutet jedoch ein unveränderter Konfidenzwert hin,
wenn sich der signifikante Artikel in der Nachbedingung der Regel befindet. Daraus kann man schließen, dass alle Attribute der Regelvorbedingung nur in diesem
einen Cluster enthalten waren. Hieraus folgt eine starke Assoziation mit dem
signifikanten Artikel. Wird der Konfidenzwert im Gesamtvergleich jedoch kleiner, so muss ein anzugebender Schwellwert entscheiden, ob die Regel noch interessant erscheint. Dieser Schwellwert könnte beispielsweise auf die Differenz
7.1. Clusterbildung unter Verwendung von Standardverfahren
[KonfidenzCluster
95
, KonfidenzD ] bezogen sein.
Abschließend sollte man sich allerdings des Nachteils bewußt sein, dass durch die
strikte Unterteilung in Cluster keine Assoziationsregeln gefunden werden können,
die zwei oder mehrere signifikante Artikel enthalten.
7.1.2 Komplexität
Der Aufwand dieses Verfahrens errechnet sich aus der Summe der Komplexität
zur Clusterbildung und der Komplexität des Standardverfahrens. Im Folgenden
sei die Datenbasis D gegeben, die Menge der Cluster sei C und es sei R die
Menge der gefundenen Regeln. Zunächst wird der Aufwand für jeden einzelnen
Punkt betrachtet und anschließend zusammenfassend die gesamte Komplexität.
Clusterbildung
Gruppiert man die Transaktionen nach der Ausprägung des diagnostischen Attributs, so beschränkt sich der Aufwand der Clusterbildung auf einen kompletten Durchlauf durch die Datenbasis. Pro Transaktion werden eine Suchoperation
nach dem signifikanten Attribut und eine Hashoperation benötigt. Die Hashoperation weist der jeweiligen Transaktion gemäß ihrem signifikanten Artikel den
passenden Cluster zu. Der Rechenaufwand der Hashfunktion wird bei optimalem
Hashing als konstant angenommen.
Bei separater Speicherung der Cluster wird ein Speicherbereich benötigt, welcher
der Größe der Datenbasis entspricht. Eine im Zugriff auf die Cluster weniger
schnelle aber speichersparende Lösung stellt die Verzeigerung der Transaktionen
dar. Im jeweiligen Cluster werden dann nicht die kompletten Transaktionen gespeichert, sondern nur ein Zeiger auf die entsprechende Transaktion in der Datenbasis. Da auf jede Transaktion nur ein Zeiger gerichtet sein kann, ergibt sich
als Speicherbedarf ersichtlicherweise (es wird als Speicherbedarf von 1 Byte pro
Zeiger angenommen): jDj 1 Byte.
Standardverfahren
Nach der Verwendung der Clusterbildung ist der für das Standardverfahren bekannte Aufwand zu betrachten. Dadurch, dass die einzelnen Cluster im Durchschnitt relativ kleine Datenbasen darstellen und somit der Datenbankdurchlauf
schneller vollzogen wird, ist eine schnelle Berechnung der Artikelmengen zu erwarten. Für eine genaue Betrachtung der Komplexität des A PRIORI–Verfahrens
wird auf Abschnitt 3.5 (Seite 55) verwiesen.
Abschließender Scan
Den Abschluss des Verfahrens bildet ein zusätzlicher Durchlauf durch die gesam-
96
te Datenbasis, um die gefundenen Regeln im Hinblick auf ihre Konfidenzwerte
zu bewerten. Dabei ist der Aufwand von O (2 jRj) Vergleichen pro Transaktion zu verrechnen. Dies erschließt sich daraus, dass sich die Konfidenz aus dem
Support der zwei erzeugenden Artikelmengen ermittelt. Insgesamt ist also mit
O (2 jRj jDj) Vergleichen zu rechnen.
Gesamtaufwand
Der gesamte Aufwand für dieses Verfahren berechnet sich also wie folgt:
O (jDj SuchOperation)
Such–
(Bildung des Clusters)
Operationen
O (jCj (Aufwand APRIORI ))
(Standardverfahren)
O (2 jRj jDj)
Vergleiche (Abschließender Scan)
Die Speicherverbrauch variiert nach der Speicherart der Cluster: Werden die Cluster separat gespeichert, so wird ein der Datenbankgröße entsprechender Speicherbereich benötigt, bei Verzeigerung nur jDj 1 Byte. Die Speicherung der Regeln
benötigt zusätzlich jRj 10 Byte, wenn man davon ausgeht, dass die Speicherung
einer einzelnen Regel höchstens 10 Byte beansprucht.
7.2 Support in Intervallen (A PRIOR I NTERVALL)
Wie schon besprochen sind Artikelmengen mit niedrigem Support für die Regelbildung von Interesse. Das Finden von ,,seltenen Artikelmengen” ist also eine logische Folgerung. Alleine das Herabsetzen des minimalen Supports ist jedoch eine wenig erfolgversprechende Maßnahme. Durch die exponentielle Vergrößerung
der Artikelmengenanzahl würde dann auch die Regelmenge unüberschaubar groß.
Interessante Regeln gingen damit in einem Meer von Regeln unter.
7.2.1 Vorgehensweise
Im Folgenden wird eine Idee vorgestellt werden, die diesem Umstand abhelfen
soll: Zusätzlich zum bekannten minimalen Support wird ein maximaler Support
eingeführt, welchen die Artikelmengen nicht überschreiten dürfen. Dieser spannt
mit dem minimalen Support ein Intervall auf, in dem die untersuchten Artikelmengen liegen. Diese Artikelmengen werden im Folgenden als Intervallmengen
bezeichnet.
Nach Bestimmen der im Intervall liegenden Einzelartikel kann das gewohnte Standardverfahren zum Finden der Artikelmengen eingesetzt werden. Nachdem alle
7.2. Support in Intervallen ( A PRIOR I NTERVALL )
97
Intervallmengen gefunden wurden, können wie gewohnt die Regeln generiert und
nach Konfidenz sortiert werden.
Man sollte aber bedenken, dass der maximale Support schon bei der Bestimmung
der Einzelartikel angewandt wird. Folglich werden überhaupt nur Artikel in den
Regelfindungsprozess miteinbezogen, deren individueller Support den maximalen
Support nicht überschreitet. So werden keine Regeln der Form A ) B mit Support kleiner dem maximalen Support gebildet werden können, wenn die Einzelartikel A und B den maximalen Support überschreiten. Daraus folgt, dass nicht alle
Regeln erzeugt werden, die im angegebenen Supportintervall liegen. Dieser Verlust der Vollständigkeit kann aber auch erwünscht sein. Denn gerade durch diese
Eigenschaft werden keine Artikel(kombinationen) zur Regelbildung verwendet,
die häufiger als im maximalen Support angegeben vorkommen. Dies unterstützt
das Ziel, Regeln zu finden, deren Artikel zwar nicht häufig vertreten sind, die aber
eine starke Konfidenz aufweisen.
Bestimmen der Intervallgrenzen
Ein offensichtliches Problem stellt die Bestimmung der Intervallgrenzen dar. Die
Größe des Intervalls entscheidet über Anzahl und Qualität der erzeugten Artikelmengen bzw. Regeln.
Als obere Schranke Imax des Intervalls sollte mindestens der maximale Supportwert der interessanten Einzelartikel herangezogen werden. Wie schon bei der
Clusterbildung erwähnt, ist es äußerst hilfreich, wenn der Benutzer angibt, welche Artikel von besonderem Interesse sind (signifikante Artikel). In einer medizinischen Domäne könnten dies beispielsweise Diagnosen sein. Dieser maximale
Supportwert ist ausreichend, da mit steigender Größe der Artikelmengen der Supportwert nur noch sinkt. Eine empirische Erhöhung des maximalen Supports kann
aber hilfreich sein, um weitere Einzelartikel mit höherem Support in den Prozess
einzubinden.
Einen alternativen Ansatz kann man in einem maximalen Support sehen, der
während des Laufes variiert. So würde eine anzugebende Funktion bestimmen,
um wieviel der maximale Support in jedem Schritt dezimiert werden müsste. Eine konstante Funktion f (x) = 0; 1 etwa würde den maximalen Support in jedem
Schritt um 0,1% veringern.
Folglich werden mit einem hohen Supportwert beginnend mehr Artikel(mengen)
zugelassen, die zur weiteren Artikelmengenbildung herangezogen werden
können.
98
7.2.2 Komplexität
Im Wesentlichen kann die Komplexität analog zu der des A PRIORI–Verfahrens
(Seite 55) betrachtet werden. Durch die Beschneidung des möglichen Supportwertes für die jeweiligen Artikelmengen tritt jedoch eine Besonderheit im Verhalten der Cluster auf. Wie in Abschnitt 3.5 beschrieben, stellt ein Cluster i
eine größtmögliche häufige Artikelmenge dar. Jede Erweiterung ist keine häufige
Artikelmenge mehr. Dies gilt auch bei der Bestimmung der A PRIOR I NTERVALL –
Artikelmengen. Die folgende Teilmengeneigenschaft der A PRIORI–Cluster gilt
jedoch nicht mehr: ,,8c i : c ist häufig.” Teilmengen eines A PRIOR I N TERVALL–Clusters können den maximalen Support überschreiten und somit keine
häufige Intervallmenge mehr sein. Wenn C die Menge Cluster sei, dann gilt daher:
CAPRIORI NTERVALL CAPRIORI
(7.1)
Die Komplexität des A PRIOR I NTERVALL Verfahrens liegt also in der des A PRIO RI Verfahrens.
7.3 Anmerkungen zum RX-Projekt
Die Idee zur Regelfindung in diagnostischen Domänen ist nicht neu. Schon in
den späten 70er Jahren beschäftigte man sich an der Stanford Universität mit der
Suche nach kausalen Abhängigkeiten in einer medizinischen Domäne. Ergebnisse
sind im RX–Projekt [Blu84] beschrieben.
Betrachtet man das RX-Programm näher, so bemerkt man, dass nicht direkt Assoziationsregeln im Sinne dieser Arbeit gefunden werden, sondern ,,kausale Abhängigkeiten”. Eine kausale Abhängigkeit A ! B definiert eine Verbindung
zwischen zwei Variablen, für die gilt:
1.
2.
3.
A ist grundsätzlich Vorgänger von B (time precedence).
Die Intensität von A korreliert mit der Intensität von B (covariation).
Es gibt keine dritte Variable C , die für diese Korrelation verantwortlich ist
(nonspuriousness).
Genauer betrachtet treffen also kausale Abhängigkeiten schärfere Aussagen über
Verbindungen als Assoziationsregeln.
7.3. Anmerkungen zum RX-Projekt
99
Das RX Programm besteht aus drei wesentlichen Modulen: Das discovery module
zur Produktion von Hypthesen, dem study module zur Überprüfung und Validierung dieser Hypothesen und einer Wissensbasis, die in allen Phasen des Prozesses
miteinbezogen wird. Die Generierung von kausalen Abhängigkeiten vollzieht sich
bei RX in zwei Grundschritten:
1. Discovery module
Finde Variablen–Paare, die kausale Abhängigkeiten zueinander pflegen. Da
alle Variablen mit allen weiteren Variablen geprüft werden, entsteht hier ein
Aufwand von O(n2 ).
2. Study module
Suche aus den Paaren die stärksten Hypothesen und validiere diese. Hierfür
werden die bestehende Wissensbasis und die darin enthaltenen production
rules eingesetzt. Das study module ist batch–fähig, kann aber auch interaktiv ablaufen.
Die besondere Eigenschaft von RX ist die konzeptionelle Integration einer Wissensbasis in den Generierungsprozess. Dies ermöglicht zum einen triviale Hypothesen zu verwerfen, aber auch zum anderen interessante Korrelationen hervorzuheben. Bestätigte Korrelationen werden in die Wissensbasis aufgenommen
und können so im weiteren Verlauf benutzt werden. Weitere Beachtung sollte
den production rules geschenkt werden. In diesen Regeln wird vom Experten
Domänenwissen abgelegt, welches bei der (automatischen) Auswahl der zu betrachtenden Daten und der einzusetzenden statistischen Methode unterstützt. Der
Einsatz von production rules bekräftigt nicht nur die Modularität des Systems,
sondern erleichtert auch die Eingabe bzw. Überprüfung von neuem Wissen. Weiter können so Abhängigkeiten im bestehenden Wissen einfacher entdeckt werden.
Die feste Verdrahtung der Wissensbasis mit dem Verfahren birgt jedoch nicht nur
Vorteile. So sollte man bedenken, dass die Leistungsfähigkeit des Systems stark
vom Umfang und der Qualität der Wissensbasis abhängig ist. Im vorliegenden
RX Projekt bediente man sich einer Teilmenge der ARAMIS/TOD Datenbank
(American Rheumatism Association Medical Information System/Time–Oriented
Databank), welche 1969 an der Stanford Universität entstand und über mehrere
Jahrzehnte gepflegt wurde.
Zusammenfassend bleibt zu sagen, dass im RX–Projekt einige Konzepte entstanden sind, die auch im Bezug auf das Finden von Assoziationsregeln untersucht
werden sollten. Folgende Punkte sollen als Anregung gegeben werden:
100
1. Intensives Einbringen von Wissen in den Prozess
Die Wissensrepräsentation im RX–Projekt wurde speziell an die medizinische Domäne angepaßt. Die Bildung eines einheitlichen Frameworks zur
Darstellung von Wissen wird dann sinnvoll, wenn auch andere Domänen
mit dem Verfahren untersucht werden sollen.
2. Produktion rules zur Entscheidungsunterstützung
Durch die Definition von production rules kann das System in wichtigen
Momenten die optimale Entscheidung treffen. Dabei bleiben diese Entscheidungen durch die Regeln transparent und für den Benutzer wartbar
und erweiterbar.
3. Kausale Abhängigkeit $ Assoziationsregel
Die RX–Implementierung findet explizit kausale Abhängigkeiten, die nicht
direkt mit Assoziationsregeln vergleichbar sind. Hier wäre zu untersuchen,
inwieweit die schärferen statistischen Annahmen von kausalen Abhängigkeiten in anderen Domänen Sinn geben.
4. Generierung der Regeln von Anfang an
RX generiert ohne Umwege gleich Regeln. Eine Erzeugung von Assoziationsregeln mit niedrigem Support und hoher Konfidenz ohne den Umweg der häufigen Artikelmengen wäre überlegenswert. Näher zu untersuchen bliebe, wie die zu erwartende Flut von Regelmöglichkeiten durch
Domänenwissen eingegrenzt werden kann.
8
Zusammenfassung und Ausblick
Das letzte Kapitel blickt auf die vorangegangene Arbeit zurück. Es bewertet die
entstandenen Ergebnisse und gibt Anregungen für zukünftige Aufgaben, die in
den Rahmen dieser Arbeit fallen.
8.1 Zusammenfassung
Die vorliegende Arbeit untersuchte das Finden von Assoziationsregeln. Beginnend mit einer Einführung in den KDD Prozess wurden in Kapitel 2 verschiedene
Arten von Data Mining Mustern besprochen. So wurden Anwendungsbereiche
wie auch bekannte Verfahren zur Klassifikation, Clusteranalyse, Regression und
sequentielle Muster genannt.
Danach schuf Kapitel 3 die theoretische Grundlage zum Finden von boolschen,
generalisierten und quantitativen Assoziationsregeln und stellte unterschiedliche
Verfahren vor. Mit einer Komplexitätsanalyse des Standardverfahrens (A PRIORI)
schloss das Kapitel.
Zum Zweck einer Anwendungsstudie wurde das Data Mining Werkzeug M I STRAL implementiert. Kapitel 4 beschrieb, welche Anforderungen an ein Data
Mining Werkzeug gestellt werden. Darauf folgend wurde erläutert, wie man mit
Hilfe von Entwurfsmustern diese Anforderungen bei der Realisierung von M I STRAL verfolgen kann. Zentrale Architekturstellen sind in UML–Notation gezeichnet worden.
Davon ausgehend beschrieb Kapitel 5 schließlich die Bedienung des implemen101
102
8. Zusammenfassung und Ausblick
tierten M ISTRAL Kerns. Es wurde erklärt, wie ein Data Mining Projekt zu definieren und durchzuführen ist, ebenso wie das An– und Abkoppeln von neuen
M ISTRAL Komponenten.
Kapitel 6 präsentierte die Ergebnisse der Anwendungsstudie. Neben synthetischen Daten zur Evaluierung von M ISTRAL wurden auch reale Daten der Firmen
Degussa AG (Katalysatoren) und Quitmann (Bürobedarfsartikel) untersucht. Eine Pflanzenwissensbasis diente als Beispiel für eine diagnostische Domäne. Eine Bewertung der Katalysator–Regeln war zum Zeitpunkt der Drucklegung nicht
verfügbar. Die Firma Quitmann zeigte sich zufrieden mit den gefundenen Regeln
und überdenkt Maßnahmen, diese für ihren Geschäftsprozess zu nutzen. Die Ergebnisse in der diagnostischen Domäne stellten sich als wenig befriedigend heraus. Als Reaktion darauf wurde ein in Kapitel 7 vorgestelltes Verfahren implementiert und auf die Pflanzenwissensbasis angewendet. Die so erzeugten Regeln
waren erheblich interessanter, da sie eine Reproduktion derjenigen Regeln darstellten, welche zuvor zum Aufbau der Wissensbasis gedient hatten.
Kapitel 7 griff die mangelhaften Ergebnisse in der diagnostischen Domäne auf und
zeigte verschiedene Lösungsansätze auf, wie interessantere Assoziationsregeln in
diagnostischen Domänen gefunden werden könnten.
8.2 Ausblick
Da in dieser Arbeit sowohl an der theoretischen Grundlage von Assoziationsregeln
als auch an einer Implementierung eines Data Mining Kerns gearbeitet wurde,
muss sich auch der Ausblick in zwei Gebiete teilen:
Der praktische Teil beschäftigte sich ausgiebig mit dem Werkzeug M ISTRAL und
seinen Komponenten. Bei der Implementierung von M ISTRAL wurde in erster
Linie auf Modularität und Wiederverwendbarkeit geachtet. Die Laufzeit der M I STRAL Projekte ist aber sicherlich noch zu verbessern. So würde der Austausch
einiger Module (wie etwa der dateiorientierten Speicherverwaltung) durch effizientere Klassen die Performanz des Programms erheblich steigern.
Ein Standardverfahren zum Finden von (generalisierten) Assoziationsregeln
(C UMULATE ) wurde sorgfältig in Kapitel 6 evaluiert. Das implementierte
A PRIOR I NTERVAL –Verfahren konnte nur im Rahmen der Pflanzenwissensbais
getestet werden. Von Interesse wäre es, die Güte von A PRIOR I NTERVAL in
Verbindung mit anderen diagnostischen Wissensbasen zu evaluieren. Eine Implementation des in Kapitel 7 vorgestellten Cluster–Verfahrens könnte hier Ver-
8.2. Ausblick
103
gleichsmöglichkeiten bilden.
Die interessanteste Richtung im theoretischen Zweig beschreibt sicherlich das
Finden von ,,speziellen Assoziationsregeln”, wie sie in Kapitel 7 definiert sind. Im
Rahmen dieser Diplomarbeit wurden zwei Verfahren angedacht. Die Forschung
nach alternativen und effizienteren Algorithmen ist ein erfolgversprechendes Ziel.
Zur schnelleren und einfacheren Implementierung der Assoziationsregel–
Verfahren wäre eine ,,Assoziationsregel–Hochsprache” von großem Nutzen.
Durch eine einheitliche Syntax könnten neue Algorithmen schnell definiert und
getestet werden. Eine effiziente Implementation der Standardbefehle würde zum
Vorteil aller darin entwickelten Verfahren sein.
Als logische Fortsetzung dieser Idee kann die in Abschnitt 2.3 (Seite 16) vorgeschlagene ,,Data Mining–Hochsprache” gesehen werden. Dieser Punkt scheint
mir persönlich von großer Bedeutung zu sein: Eine einheitliche Data Mining Sprache könnte ebenfalls, wie SQL für die Datenbankforschung, einen gewaltigen Innovationsschub leisten. Der Entwurf einer umfassenden Syntax zur Bewältigung
von Data Mining Aufgaben und die Implementation eines entsprechenden Interpreters/Compilers bedürfte allerdings sicherlich ausgiebiger Studien.
Beschreibung der beigelegten CD–ROM
Auf der beigelegten CD–ROM findet sich im Verzeichnis Mistral das Programm
M ISTRAL im Quellcode und in einer vorkompilierten JAR–Datei. Die Dokumentation der MISTRAL Klassen liegt im HTML–Format vor.
Ebenso kann die vorliegende Arbeit in verschiedenen Formaten im Verzeichnis
Diplomarbeit eingesehen werden.
Die verwendeten Daten der Firmen Quitmann und Degussa AG, sowie die Pflanzenwissensbasis sind im Verzeichnis Daten vertreten.
Ein aktuelles Inhaltsverzeichnis der CD–ROM gibt die Datei index.html im Hauptverzeichnis wieder.
Danksagung
Am Ende angelangt, ist nun der richtige Zeitpunkt gekommen, um mich bei einigen Menschen zu bedanken, welche meine Arbeit in den letzten Monaten erheblich beeinflusst haben.
Ein Dank geht an Carsten Bange, der die Daten der Firma Quitmann beschaffte,
und an Herrn Dr. Jürgen Giesshoff von der Degussa AG. Ebenso bedanken möchte
ich mich bei Roman Ernst, der mir den Einstieg in die Welt der Pflanzen erheblich
erleichterte.
Natürlich soll meinem Betreuer Ioannis ,,The grill–man” Iglezakis gedankt werden, welcher auch mal locker nach Dienstschluss fünf Stunden über Data Mining
diskutieren konnte. Auch ANSI–C Dreizeiler gegen 2 Uhr morgens sorgten bei
einem Diplomanten mit Mauszeiger–Horizont für Erstaunen. Ebenfalls bedanken
möchte ich mich bei Herrn Prof. Frank Puppe, der in seinen ausgiebigen Sprechstunden viele Ideen und Anregungen gab. Nicht zu vergessen sind Rüdiger ,,ruedee” Hain, der Besorgungen aller Art tätigte, und selbstverständlich der restliche
humanoide Lehrstuhl–VI–Inventar. Standardgehn?
Hermann Pfanner soll hier auch ein Dankeschön ausgesprochen werden: Trotz
dieser wirtschaftlich schwierigen Zeit schafft er es Eistee aus direkt aufgebrühtem
Tee zu erstellen und nicht, wie die Konkurrenz, billigen Instant–Tee unters Volk
zu bringen. So diente sein Tee während der Erstellung dieser Arbeit als magenschonender Kaffee–Ersatz und erzeugte unverständliches Kopfschütteln in meiner
Umgebung. Peach rules!
Ein Dank geht an meine Eltern, die mich während meines Studiums mit allen
erdenklichen Dingen unterstützt haben und nie Zweifel an meiner ,,Intelligenz”
hegten.
Meiner Freundin K möchte ich zum Schluss einen dicker smile und ein Dankeschöön für all die schönen Momente schenken. Nothing heals me like you do.
[AIS92]
Rakesh Agrawal, Tomasz Imiclinski, and Arun Swami. Database
mining: A performance perspective. Technical report, IBM Research
Division, Almaden Research Center, San Jose, CA, USA, 1992.
[AIS93]
Rakesh Agrawal, Tomasz Imielinski, and Arun Swami. Mining association rules between sets of items in large databases. In Proceedings
of the 1993 ACM SIGMOD Conference, 1993.
[AS94a]
Rakesh Agrawal and Ramakrishnan Srikant. Fast algorithms for mining association rules. In Proceedings of the 20th VLDB Conference,
1994.
[AS94b]
Rakesh Agrawal and Ramakrishnan Srikant. Fast algorithms for mining association rules. Technical report, IBM Research Division,
Almaden Research Center, San Jose, CA, USA, 1994.
[AS94c]
Rakesh Agrawal and Ramakrishnan Srikant. Mining sequential patterns. In Proceedings of the 11th Intl. VLDB Conference, Santiago,
Chile, 1994.
[Blu84]
Robert L. Blum. Discovery, Confirmation, and Incorporation of
Causal Relationships from a Large Time-Oriented Clinical Data Base: The RX Project, pages 399–425. In [CS84], 1984.
[Bol96]
Toni Bollinger. Assoziationsregeln - Analyse eines Data Mining Verfahrens. In Informatik Spektrum 19: 257-261, 1996.
[CHNW96] David W. Cheung, Jiawei Liang Han, Vincent T. Ng, and C. Y. Wong.
Maintenance of discovered association rules in large databases: An
incremental updating technique. Technical report, The University of
Hong Kong, Hong Kong, 1996.
108
[CHY96]
Ming-Syan Chen, Jiawei Han, and Philip S. Yu. Data Mining: An
overview from database perspective. 1996.
[CM96]
Peter Coad and Mark Mayfield. Java Design. Building better Apps
and Applets. Prentice Hall, Upper Saddle River, NJ 07458, USA,
1996.
[CS84]
William J. Clancey and Edward H. Shortliffe. Readings in Medical
Artificial Intelligence. Addison-Wesley, 1984.
[CS96]
Peter Cheeseman and John Stutz. Bayesian Classification (AutoClass): Theory and Results. In [FPSSU96], 1996.
[Ern96]
Roman Ernst.
Untersuchung verschiedener Problemlösungsmethoden in einem Experten– und Tutorsystem zur makroskopischen Bestimmung krautiger Blütenpflanzen. Master’s thesis, Biologisches Institut, Universität Würzburg, Deutschland, 1996.
[Fis90]
D. H. Fisher. Knowlegde Aquisition via Incremental Conceptual Clustering. In [SD90], 1990.
[Fla97]
David Flanagan. Java in a Nutshell, Second Edition. O’Reilly, Sebastopol, CA 95472, USA, 1997.
[FPSSU96] Usama M. Fayyad, Gregory Piatetsky-Shapiro, Padhraic Smyth, and
Ramasamy Uthurusamy. Advances in Knowledge Discovery and Data Mining. AAAI Press / The MIT Press, Menlo Park, California,
1996.
[Fri91]
J. H. Friedman. Multivariate Adaptive Regression Splines. In Annals
of Statistics, 19:1, 1991.
[Gam96]
Erich Gamma. Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley, Bonn, 1996.
[Goo95]
Klaus Goos. Fallbasiertes Klassifizieren. Methoden, Integration und
Evaluation. PhD thesis, Universität Würzburg, Deutschland, 1995.
[Han97]
Jiawei Han. Data Mining: Where is it heading? In Proc. of 1997
Intl. Conference on Data Engineering (ICDE ´97), 1997.
[HP96]
Jia Liang Han and Ashley W. Plank. Background for association rules and cost estimate of selected mining algorithms. Technical report,
The University of Southern Queensland, Australia, 1996.
[HS93]
109
Maurice Houtsma and Arun Swami. Set-oriented mining for association rules. Technical report, IBM Research Division, Almaden
Research Center, San Jose, CA, USA, 1993.
[KMR+ 94] Mika Klemettinen, Heikki Mannila, Pirjo Ronkainen, Hannu Toivonen, and A. Inkeri Verkano. Finding interesting rules from large
sets of discovered association rules. Technical report, Department of
Computer Science, University of Helsinki, 1994.
[Log98]
Logistik Heute. Datenschlacht um Handelsspannen. 3´98, 1998.
[LSL95]
H. Lu, R. Setiono, and H. Liu. NeuroRule: A connectionist approach
to Data Mining. In Proc. of 21th Intl. Conference on Very Large Data
Bases, p. 478–489, 1995.
[Man96]
Heikki Mannila. Methods and problems in data mining. Technical report, Department of Computer Science, University of Helsinki,
1996.
[MAR96]
M. Metha, R. Agrawal, and J. Rissanen. SLIQ: A fast scalable classifier for Data Mining. In Proc. of 1996 Intl. Conference on Extending
database Technology (EDBT´96), Avignon, France, 1996.
[Mic94]
Tecuci Michaelski. Machine Learning: A Multistrategy Approach,
Vol. IV. Morgan Kaufmann, 1994.
[Mit97]
T. M. Mitchell. Machine Learning. McGraw–Hill, 1997.
[MTV94]
Heikki Mannila, Hannu Toivonen, and A. Inkeri Verkano. Improved
methods for finding association rules. Technical report, Department
of Computer Science, University of Helsinki, 1994.
[PGPB96]
Frank Puppe, Ute Gappa, Karsten Poeck, and Stefan Bamberger.
Wissensbasierte Diagnose– und Expertensysteme. Springer–Verlag,
Berlin, Heidelberg, 1996.
[Qui86]
J. R. Quinlan. Machine Learning 1. Morgan Kaufmann, 1986.
[Qui93]
J. R. Quinlan. C4.5: Programs for Machine Learning. Morgan Kaufmann, 1993.
[Rei94]
Y. Reich. Macro and Micro Perspectives of Multiystrategy Learning,
pages 379–401. In [Mic94], 1994.
110
[SA95]
Ramakrishnan Srikant and Rakesh Agrawal. Mining generalized association rules. Technical report, IBM Research Division, Almaden
Research Center, San Jose, CA, USA, 1995. Also in Proceedings of
the 21st VLDB Conference 1995.
[SA96]
Ramakrishnan Srikant and Rakesh Agrawal. Mining quantitative association rules in large relational tables. Technical report, IBM Research Division, Almaden Research Center, San Jose, CA, USA, 1996.
[SD90]
Jude Shavlil and Thomas G. Dietterich. Readings in Machine Learning. Morgan Kaufmann, 1990.
[SON95]
Ashok Savasere, Edward Omiecinski, and Shamkant Navathe. An
efficient algorithm for mining association rules in large databases.
Technical report, Georgia Institute of Technology, Atlanta, USA,
1995.
[Sri96]
Ramakrishnan Srikant. Fast Algorithms for Mining Association Rules And Sequentiel Patterns. PhD thesis, University of Wisconsin Madison, 1996.
[ST96]
Avi Silberschatz and Alexander Tuzhilin. User-assisted knowledge
discovery: How much should the user be involved. Technical report,
Bell Laboratories, Murray Hill, NJ, USA, 1996.
[SVA97]
Ramakrishnan Srikant, Quoc Vu, and Rakesh Agrawal. Mining
asssocition rules with item constraints. Technical report, IBM Research Division, Almaden Research Center, San Jose, CA, USA, 1997.

Finden von Assoziationsregeln

Transcription

Similar documents

AKTIONSANGEBOTE BEI EBAY ERSTELLEN

Apriori auf Netflix