Data Mining Verfahren zum Finden von...

Data Mining Verfahren zumFinden von Assoziationsregelnund Evaluierung durch das Werkzeug MISTRAL

Diplomarbeit vonJoachim Baumeister

Betreuer:Dipl.–Inform. Ioannis IglezakisProf. Dr. Frank PuppeAugust 1998

Lehrstuhl fur Kunstliche Intelligenzund Angewandte InformatikUniversitat Wurzburg

Erkl arung

Ich erklare hiermit, dass ich diese Arbeit selbstst¨andig angefertigt habe und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

Wurzburg, 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

2.3 Stand der Forschung . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Das Finden von Assoziationsregeln 19

3.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Grundlegende Definitionen . . . . . . . . . . . . . . . . . 19

4 Inhaltsverzeichnis

3.1.2 Generischer Algorithmus . . . . . . . . . . . . . . . . . . 20

3.1.3 Arten von Assoziationsregeln . . . . . . . . . . . . . . . 22

3.2 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

3.3 Generalisierte Assoziationsregeln . . . . . . . . . . . . . . . . . 36

3.3.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2 Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.3 Cumulate . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.4 EstMerge . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.5 Filtern der interessanten Regeln . . . . . . . . . . . . . . 43

3.4 Quantitative Assoziationsregeln . . . . . . . . . . . . . . . . . . 45

3.4.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . 45

3.4.2 Grundlegende Definitionen . . . . . . . . . . . . . . . . . 46

3.4.3 Vorgehensweise beim Finden von quantitativen Assozia-tionsregeln . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.4 Partitionierung der quantitativen Attributwerte . . . . . . 48

3.4.5 Filtern der interessanten Regeln . . . . . . . . . . . . . . 52

3.4.6 Erganzungen zum Algorithmus . . . . . . . . . . . . . . 53

3.5 Betrachtung der Komplexit¨at . . . . . . . . . . . . . . . . . . . . 55

4 Implementierung des Werkzeugs MISTRAL 59

4.1 Uberlegungen zur Implementierung eines Data Mining Werkzeugs 59

4.2 Architektur von MISTRAL . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 Der Kern . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Inhaltsverzeichnis 5

4.2.2 Speicherbereiche . . . . . . . . . . . . . . . . . . . . . . 62

4.2.3 Speicherung der Artikel . . . . . . . . . . . . . . . . . . 64

4.2.4 Die Mistral-Komponenten . . . . . . . . . . . . . . . . . 65

4.3 Aspekte der Implementierung . . . . . . . . . . . . . . . . . . . . 68

5 Bedienungshinweise zu MISTRAL 69

5.1 Aufbau eines Data Mining Laufes . . . . . . . . . . . . . . . . . 69

5.2 Menustruktur von MISTRAL . . . . . . . . . . . . . . . . . . . . 71

5.3 Definition eines MISTRAL Projekts . . . . . . . . . . . . . . . . . 72

5.4 Arbeiten mit MISTRAL Komponenten . . . . . . . . . . . . . . . 72

5.4.1 Koppeln . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4.2 Vorhandene Komponenten . . . . . . . . . . . . . . . . . 74

5.5 Das Tools Men¨u . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

6.3 Die Warenwirtschaft der Firma Quitmann . . . . . . . . . . . . . 85


6.3.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.4 Pflanzenwissensbasis . . . . . . . . . . . . . . . . . . . . . . . . 88


6.4.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 89

6 Inhaltsverzeichnis

7 Regelfindung in diagnostischen Dom¨anen 93

7.1 Clusterbildung unter Verwendung von Standardverfahren . . . . . 93

7.1.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . 94

7.1.2 Komplexitat . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.2 Support in Intervallen (APRIORINTERVALL) . . . . . . . . . . . . 96

7.2.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . 96

7.2.2 Komplexitat . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.3 Anmerkungen zum RX-Projekt . . . . . . . . . . . . . . . . . . . 98

8 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 desData Minings. Zunächst werden Gründe angeführt, die Data Mining und speziellAssoziationsregeln für Forschung und Wirtschaft interessant machen. Im Weite-ren werden die Ziele dieser Arbeit näher umschrieben. Das Kapitel schließt miteinerUbersichtuber die vorliegende Arbeit.

1.1 Motivation

Beachtliche Fortschritte bei der Sammlung und Speicherung von Daten haben inden letzten 10 Jahren zu einem rapiden Anstieg der Datenbestände geführt. Einennicht zu unterschätzenden Einfluss hatte hierbei auch die Einführung der Barcode-Technologie: Da inzwischen nahezu jeder Artikel einen Barcode trägt, ist dieserdatentechnisch erfassbar. Zusätzlich wurde es den Unternehmen durch die preis-wert zur Verfugung stehenden Massenspeicher möglich, weit mehr Daten zu spei-chern als dies noch vor einigen Jahren getan wurde. Diesen erheblichen Anstiegihrer Datenmenge wollen die Unternehmen nutzen, um dem weltweit zunehmen-den Wettbewerbsdruck entgegentreten zu können. Der erste Schritt besteht darin,die verschiedenen heterogenen Datenbestände des Unternehmens zentral und ein-heitlich verfugbar zu machen. DieserUbergang zur Speicherung der Daten in so-genanntenData Warehousesist heute meist schon vollzogen. Da die gesammeltenDatenbestände durch ihre Größe in der Regel unmöglich manuell analysiert wer-den konnen, besteht der nächste logische Schritt in der Nutzung vonData MiningTechnologien.

7

8 1. Einleitung

Data Mining beschreibt die Gewinnung von nützlichen Informationen aus beste-henden Datenbeständen. Nützliche Informationen können hierbei von mannig-faltiger Natur sein: Die Daten können anhand ihrer Eigenschaften in Blöckengruppiert oder klassifiziert worden sein. Oft ist es auch möglich, Beziehungenzwischen den einzelnen Daten zu finden.

Diese Informationen wollen die Anwender nutzen, um ein besseres Verständnisuber Zusammenhang und Aufbau der Daten zu erlangen. Durch das Wissen vonMustern und Ablaufen in den gespeicherten Geschäftsprozessen erhofft man sichschließlich eine intelligentere Entscheidungsunterstützung bei relevanten Pro-blemfallen.

An Data Mining werden also große Hoffnungen und Wünsche geknüpft, die esheute auch zum Teil schon erfüllen kann. Ermutigt werden diese Erwartungendurch aufsehenerregende Meldungen aus der Wirtschaft, in denen einzelne Unter-nehmen durch den Einsatz von Data Mining spürbare Gewinne einfahren konn-ten. Als bekanntes Beispiel dient das weltgrößte EinzelhandelsunternehmenWal-Mart, das sich durch konsequenten Einsatz von Data Warehouse/Data MiningTechnologie von der Konkurrenz absetzen konnte.1

1.2 Zielsetzung

Data Mining bildet den zusammenfassendenUberbegriff fur eine wachsende An-zahl verschiedener Technologien, die ihren Ursprung in der Statistik, der Daten-banktheorie und dem Maschinellen Lernen haben. Zu den bekanntesten MiningArten zahlen Klassifikation, Clusterbildung, Regression und Assoziationsregeln.

In dieser Arbeit wird nur eine bestimmte Art von Data Mining Verfahren unter-sucht werden: Das Finden vonAssoziationsregeln, welches erstmals in [AIS93]vorgestellt wurde. Assoziationsregeln beschreiben Relationen zwischen häufigauftretenden Datenausprägungen. Im Kontext eines Supermarktes, in welchemman die ArtikelA, B undC kaufen kann, könnte eine Assoziationsregel folgen-dermaßen lauten: “Wenn der Kunde ArtikelA kauft, dann kauft er auch mit 80%Wahrscheinlichkeit die ArtikelB undC.” Fur medizinische Diagnosen könnte ei-ne Assoziationsregel so lauten: “Hat der Patient die LaborwertausprägungenL1

undL2, dann spricht das mit 75% Wahrscheinlichkeit für DiagnoseD.” Die vor-liegende Arbeit beschreibt eine Anzahl von Verfahren zum Finden von boolschen,generalisierten und quantitativen Assoziationsregeln. Durch die Implementierung

1Fur den Erfolg der Kette Wal-Mart sind aber sicherlich auch die mit dem Warehouse zusam-menhangende Distributionslogistik und andere weitere Faktoren verantwortlich [Log98].

1.3. Struktur der Arbeit 9

mehrerer Verfahren werden später synthetische und reale Szenarien untersuchtwerden. In den realen Szenarien sind sowohl transaktionelle als auch diagnosti-sche Domänen vertreten.

1.3 Struktur der Arbeit

Die Arbeit gliedert sich in einen theoretischen und einen praktischen Teil. Dieeinzelnen Kapitel sind in folgender Weise zu lesen:

� Kapitel 2 gibt einen kurzenUberblick in das umfassende Gebiet des DataMining. Hierfur wird der Begriff des KDD-Prozesses (Knowledge Discove-ry in Databases) eingeführt, in welchen Data Mining integriert ist. Im Wei-teren werden wichtige Data Mining Verfahren vorgestellt und kurz erläutert.

� Kapitel 3 beschreibt das Finden von Assoziationsregeln. Zunächst wird aufdie Terminologie der Assoziationsregeln eingegangen, dann ein generischerAlgorithmus zum Finden von Assoziationsregeln gegeben und schließlichwerden die verschiedenen Arten von Assoziationsregeln abgegrenzt. Dieweiteren Abschnitte erläutern Verfahren zum Finden der einzelnen Regelar-ten. Am Ende des Kapitels wird die Komplexität des APRIORI-Algorithmusuntersucht, der eine Grundlage für die meisten Verfahren darstellt.

� Kapitel 4 geht auf die Implementierung des Data Mining Werkzeugs MI-STRAL ein. MISTRAL wurde im Rahmen dieser Diplomarbeit erstellt undzeichnet sich durch einen modularen, erweiterbaren Kern aus. WichtigeAspekte der Implementierung werden genau untersucht und beschrieben.

� Kapitel 5 zeigt, wie man mit dem Werkzeug MISTRAL Data Mining Projek-te anlegen und durchführen kann. Neben der Beschreibung der Programm-bedienung werden auch die wesentlichen Dateiformate einiger Komponen-ten dargestellt.

� Kapitel 6 beschreibt zunächst die Evaluierung von MISTRAL und dieDurchfuhrung von Performanzstudien. Hierfür werden synthetische Da-ten herangezogen, deren Charakteristika bekannt sind. Nach der Evaluie-rung werden reale Datenbanken der Firma Degussa AG und Quitmann aufAssoziationsregeln untersucht. Nach der Analyse der Datensätze werdendie Ergebnisse der verschiedenen Data Mining Läufe dargestellt. Schließ-lich werden noch zwei unterschiedliche Assoziationsregel–Verfahren in Da-tensatzen mit diagnostischer Domäne angewandt. Hierzu dient eine Wis-

10 1. Einleitung

sensbasis zur Pflanzenerkennung, die aus dem Expertensystem D3 extra-hiert wurde.

� Kapitel 7 zeigt, warum der Einsatz von Standardverfahren zum Finden vonAssoziationsregeln in diagnostischen Domänen wenig erfolgreich war. Oft-mals ist hier ein häufiges Auftreten der Regeln in der Wissenbasis wenigerwichtig. Ein hohes Vertrauen (Konfidenz) der Regeln spräche aber für eineinteressante Entdeckung. Es werden Ansätze besprochen, wie Regeln mitdieser Charakteristik gefunden werden können.

� Kapitel 8 schließlich fasst die Erkenntnisse und Ergebnisse der vorangegan-genen Kapitel zusammen. Der Ausblick auf mögliche zukunftige Entwick-lungen im Bereich Assoziationsregeln und zusätzliche Erweiterungen vonMISTRAL bilden den Abschluss dieser Arbeit.

Diese Arbeit wurde in der neuen Rechtschreibung erstellt; als Textsystem dienteLATEX.

2

Data Mining und das Finden vonInformationen

Bevor diese Arbeit auf das Finden von Assoziationsregeln eingeht, sollen die Be-griffe KDD (Knowledge Discovery in Databases) und Data Mining definiert wer-den. KDD gilt namlich als der umschließende Prozess, in den Data Mining ein-gebettet wird. Verschiedene Data Mining Muster neben Assoziationsregeln, wieKlassifikation, Clusteranalyse oder Sequentielle Muster, werden kurz angespro-chen.

2.1 Der KDD Prozess

Data Mining als das Suchen nach Wissen in großen Datenbeständen darf nicht alsisolierter Arbeitsschritt gesehen werden. Vielmehr stellt es ein Teilstück in einemumfassenden Prozess dar, demKnowledge Discovery in Databases(KDD). Das,,Wissen” wird hierbei in Form von Mustern repräsentiert. Laut der Definition in[FPSSU96] definiert sich KDD wie folgt:

Knowledge Discovery in Databasesis the non-trivial process ofidentifying valid, novel, potentially usefull and ultimately understan-dable patterns in data.

KDD ist also ein Vorgang, der zur Gewinnung von Mustern (dem Wissen) dient.Diese Muster sollten bestimmte Eigenschaften besitzen, wie Gültigkeit (valid),

11

12 2. Data Mining und das Finden von Informationen

Neuartigkeit (novel), Nützlichkeit (useful) und Verständlichkeit (understanda-ble). Data Mining ist innerhalb dieses Prozesses für das Finden dieser Musterzustandig. 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 ausgehendder Data Mining Schritt angewendet wird.

Zu Beginn ist es wesentlich, dass der Anwender ein Verständnis fur die Domaneentwickelt und seine Ziele, die er mit KDD erreichen will, gebildet hat. Die zurVerfugung stehende Datenbasis geht häufig auf ein Data Warehouse zurück undspeichert üblicherweise Daten im Giga– bis Terrabyte Bereich. Daher ist es wich-tig, eine Auswahl aus dem verfügbaren Datenbestand zu treffen, die beispiels-weise nur bestimmte Datensammlungen betrachtet oder aber nur spezielle Attri-bute berucksichtigt. Die anschließende Vorverarbeitung dieser Zielmenge dientder Bereinigung der Daten. Hier muss entschieden werden, wie mit fehlerhaftenoder fehlenden Attributen zu verfahren ist. Die folgende Transformation berei-tet die Daten für den Data Mining Algorithmus auf. Dabei können zum Beispielunwichtige Attribute gefiltert oder auch mehrere Datensätze zu einem neuen zu-sammengefasst werden. Die Auswahl des zu verwendenden Data Mining Algo-rithmus fordert vom Benutzer das meiste Wissen. Die zu findende Musterart mussgenau spezifiziert und der dazu passende Algorithmus ausgewählt werden. Nachdem Data Mining Lauf werden die entdeckten Muster evaluiert. Unter Umständenbenotigt man hierfur weitere Daten aus der Datenbasis. Am Ende des Prozessesstehen die Evaluation und Interpretation der gefundenen Muster. Entsprechendihrer Domane kann aus den Resultaten des Data Mining Laufs Wissen gebildetwerden. Dieses Wissen ist das gewünschte Ziel des KDD Prozesses.

Man sollte sich bewußt machen, dass dieser Prozess immer vom Menschen mitbe-gleitet werden sollte. Die Resultate, welche man mit KDD erzielen kann, hängenim Wesentlichen davon ab, wie interaktiv der Benutzer in den Prozess eingreifenkann bzw. wie sich schon vorhandenes Wissen einbringen lässt. Die Moglichkeit,den Nutzer interaktiv in den Prozess miteinzubeziehen, wird in [KMR+94] unter-sucht (siehe dazu auch Seite 22).

2.2. Verschiedene Data Mining Verfahren 13

2.2 Verschiedene Data Mining Verfahren

Eine Schlusselstelle des KDD Prozesses ist die Auswahl des passenden Data Mi-ning Verfahrens. Die übergeordneten Aufgaben von Data Mining sind Vorhersage(prediction) und Beschreibung (description). Da die vielen einzelnen Verfahrenunterschiedliche Arten von Mustern finden, ist es sinnvoll, eine Gruppierung nachder Art der zu findenden Muster vorzunehmen. Die vorliegende Arbeit hat ihrenSchwerpunkt im Finden von Assoziationsregeln als Musterart. Dennoch soll imFolgenden ein kurzerUberblick uber einige wichtige weitere Gruppen gegebenwerden.

2.2.1 Klassifikation

Die Klassifikation zahlt zu den überwachten Lernverfahren und hat ihren Ur-sprung im Maschinellen Lernen. Klassifikation beschreibt dabei die Aufgabe, eineungeordnete Menge von Objekten in vorgegebene Klassen zu unterteilen. Diesevorgegebenen Klassen beschreiben ein Klassifikationsmodell, welches durch einesogenannteTrainingsmengeerstellt wird. Die Klassenzugehörigkeit der Objektein der Trainingsmenge ist dabei bekannt. So verweisen die Attribute der einzelnenDatensatze auf eine bestimmte Klasse. Nachdem das Klassenmodell mit der Trai-ningsmenge aufgebaut worden ist, kann es mit einer dazu disjunkten Testmengevalidiert werden. Anwendung finden Klassifikationsverfahren beispielsweise inder medizinischen Diagnose, der Kreditvergabe im Bankwesen oder im Direkt-marketing.

Zu den bekanntesten Klassifikationsalgorithmen zählen die Entscheidungsbaumbildenden Verfahren, wie ID–3 von J. R. Quinlan [Qui86] und dessen NachfolgerC4.5 [Qui93]. Dieser erweitert die Klassifikationsdomäne von kategorischen aufnummerische Attribute und zeichnet sich durch speziellepruning–Mechanismenzur Vermeidung von übertrainierten Bäumen aus.

Ein weiterer Ansatz stellt die Klassifikation mit Hilfe der ILP (induktive Logik-programmierung) 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 können vonrealen, diskreten oder auch vektoriellen Attributwerten lernen. Als bekanntesterAlgorithmus laßt sich hier BACKPROPAGATION [Mit97] nennen.


2.2.2 Clusteranalyse

Unter der Clusteranalyse versteht man die automatische Gruppierung einer un-geordneten Menge von Objekten. Die Clusteranalyse zählt zu den nicht–über-wachten Lernverfahren und grenzt sich somit von der Klassifikation ab. Währendsich bei der Klassifikation die Objekte in festen Gruppen (Klassen) befinden, sinddie Clustergruppen vor dem Lauf einer Clusteranalyse unbekannt. Eine Funkti-on bestimmt dabei dieAhnlichkeit zwischen den einzelnen Objekten und ordnetdiese in gleichen oder verschiedenen Clustern an.

Die Clusteranalyse unterscheidet zwischen zwei Verfahrensweisen: Dieklassi-schen Verfahren(nummerische Taxonomie) beschranken sich darauf, die gegebe-nen Objekte in Gruppen anzuordnen. DasConceptual Clusteringerweitert dieklassischen Verfahren. Der grundlegende Unterschied besteht in der Beschaffen-heit derAhnlichkeitsfunktion: Die nummerische Taxonomie bestimmt dieAhn-lichkeit zweier Objekte durch den Wert einer nummerischen Funktion. Damitbesteht jedoch der Nachteil, dass die resultierenden Gruppierungen für den An-wender nicht mehr oder nur sehr schlecht nachvollziehbar sind. Das ConceptualClustering behebt diesen Umstand, indem es bei der Bildung der Gruppen aufBegriffe achtet, welche die jeweiligen Cluster später charakterisieren können.

Zu den bekannten Conceptual Clustering Verfahren zählen die AlgorithmenCOBWEB bzw. COBWEB/2 [Fis90].

2.2.3 Regressionsverfahren

Regressionsverfahren dienen zum Erlernen einer Funktiony = f(x)+�, die jedemObjektx einen reellen Werty zuordnet. Mit Hilfe von Punktenx im Objektraumsoll also eine Funktion approximiert werden. Die Funktionf kann dabei aus li-nearen, aber auch aus nichtlinearen Intervallen bestehen. Die Konstante� stellteinen Fehler dar, der beispielsweise durch verrauschte Daten entstehen kann. Ge-meinhin wird� = 0 angenommen.

Anwendung finden Regressionsverfahren in der Prognose, wie zum Beispiel beider Vorherbestimmung von Aktienkursen oder Geschäftsverlaufen. Auch in dermedizinischen Domäne konnen Regressionsverfahren zur Vorhersage von Symp-tom/Diagnose Kombinationen genutzt werden.

Als bekanntes Regressionsverfahren ist MARS (Multivariate Adaptive Regressi-on Splines) [Fri91] zu nennen.

2.2. Verschiedene Data Mining Verfahren 15

2.2.4 Assoziationsregeln

Assoziationsregeln beschreiben Zusammenhänge zwischen Attributen. Die vor-liegende Arbeit beschäftigt sich in den folgenden Kapiteln eingehend mit demFinden von Assoziationsregeln. Kapitel 3 beschreibt die einzelnen Arten von As-soziationsregeln und stellt entsprechende Algorithmen vor. Das Kapitel 7 erläutertdie Problematik, Assoziationsregeln in diagnostischen Domänen zu finden, undzeigt mogliche Verfahren auf.

2.2.5 Sequentielle Muster

Das Finden von sequentiellen Mustern (sequential patterns) ist eng mit dem Fin-den von Assoziationsregeln verknüpft. Als zu untersuchende Datenbasis wird hiereine Menge von Datensequenzen (data sequences) herangezogen. Eine Datense-quenz stellt eine Menge zusammengehöriger Transaktionen dar. Jede Transaktionist durch einen Zeitstempel gekennzeichnet und beinhaltet eine Menge von Arti-keln.

Im Kontext einer medizinischen Domäne ware eine Datensequenz eine sortierteSammlung von Arztbesuchen eines bestimmten Patienten, in welcher beispiels-weise Symptome und Diagnosen gespeichert sind. Sequentielle Muster könntenhier helfen, Symptome und Diagnosen zu finden, die anderen Diagnosen (zeitlich)vorangehen.

Das in [AS94c] vorgestellte APRIORIALL–Verfahren dient zum Finden von se-quentiellen Mustern. Die Erweiterung GSP (Generalized Sequentual Patterns)stellt R. Srikant in seiner Dissertation [Sri96] vor. GSP verfügt uber die Mog-lichkeit, Taxonomien und zeitliche Constraints in den sequentiellen Mustern zuberucksichtigen. Dabei geht das Verfahren ähnlich zu dem auf Seite 28 bespro-chenen APRIORI–Algorithmus vor. Er generiert sukzessive zuerst häufige 1er Se-quenzen, dann daraus 2er Sequenzen, usw. Die häufigen k–Sequenzen werdendurch Bildung und anschließende Bewertung dieser Kandidaten ermittelt. DerUnterschied der Verfahren besteht in der Art der Kandidatengenerierung und deranschließ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-


ten zu finden. Häufig werden diese Methoden bei der interaktiven Datenanlyseeingesetzt. Das Entdecken von Veränderungen und Abweichungen (Change andDerivation Detection) sucht die auffälligsten Veranderungen in den Daten undwird haufig bei der Datenreinigung (Data Cleaning) genutzt. DerText Retrie-velsucht nach Texten, die einem vorgegebenen Text oder angegebenen Attributenahnlich sind. Diese Art von Data Mining wird besonders aufgrund der raschenVergroßerung des Internets (WWW, News) und den darin enthaltenen (unstruktu-rierten) Dokumenten an Bedeutung gewinnen. Eine empfehlenswertenUberblickuber diese und weitere Musterarten gibt [CHY96].

2.3 Stand der Forschung

Obwohl Data Mining und inzwischen auch Assoziationsregeln in der Industrieals Technologien anerkannt und auch angewendet werden, stellen sich an dieForschung noch viele Herausforderungen: Momentan bestehen die meisten Da-ta Mining Anwendungen aus isolierten Programmen. Heikki Mannila vertritt in[Man96] sogar die These, dass Data Mining heute auf dem gleichen Stand ist, wiees dasData Managementin den 1960er Jahren war. Nur das relationale Datenmo-dell und machtige Datenbankabfragesprachen (wie SQL) konnten damals einenspurbaren Fortschritt bringen. Mannila schließt daraus, dass auch Data Miningein solches theoretisches Framework benötigt, um der gesamten Forschungsrich-tung einen Impuls geben zu können.

Jiawei Han beschreibt in seinem Ausblick [Han97] folgende Punkte, die in dennachsten Jahren Ziel der Data Mining Forschung sein werden:

� Integration in Data Warehouseund OLAP TechnologienSchon heute bestehen in vielen Anwendungsbereichen Data Warehouse Im-plementierungen, die mit Erfolg eingesetzt werden. Das Gleiche gilt fürzahlreiche OLAP Werkzeuge, die man als Vorstufe zu Data Mining An-wendungen sehen kann. Durch die Integration von Data Mining Verfahrenin bestehende Data Warehouse oder OLAP Installationen würde man dieNutzlichkeit und Machtigkeit aller Technologien merklich anheben können.

� Herausbilden neuer WissensartenEs ist denkbar, dass neben den bekannten Wissensarten durchaus weite-re Muster entwickelt werden könnten. So könnten beispielsweise nebenKlassifikation, Clusteranalyse oder auch Assoziationsverfahren neue Mu-ster, wie Charakterisierung, Vergleich oder zeitabhängige Muster, entste-

2.3. Stand der Forschung 17

hen. Viele dieser Musterarten sind nicht oder noch nicht ausreichend er-forscht.

� Entwicklung einer Data Mining HochspracheWie schon zuvor angesprochen, kann die Entwicklung einer Data MiningHochsprache merkliche Fortschritte bringen. Eine solche Sprache würde esNutzern erlauben, ad-hoc Data Mining Verfahren oder Muster zu beschrei-ben. Daruber hinaus könnte die interaktive und Muster-gerichtete Sucheeffizienter und flexibler umgesetzt werden.

� Umgang mit immer komplexeren DatenMomentan beschränkt sich das Finden von Mustern hauptsächlich auf Do-manen, denen relationale oder transaktionelle Daten zu Grunde liegen.Trotzdem wird in Zukunft das Finden von Mustern auf unstrukturierten oderhalb-strukturierten Daten, wie Hypertext oder Multimedia-Daten, immer in-teressanter werden.

� Hocheffizientes Data MiningDurch die steigenden Datenmengen werden effizientere Verfahren im Ziel-punkt der Forschung stehen. So beschäftigen sich verschiedene Richtungenmit parallelem [SON95], verteiltem oder auch inkrementellem Data Mining[CHNW96].

� VisualisierungNicht nur die richtige und verständliche Visualisierung der gefundenen Mu-ster ist fur den Erfolg eines Data Mining Projekts von entscheidender Be-deutung. Schon eine hilfreiche Darstellung der bestehenden Daten mit in-teraktiven Visualisierungs-Werkzeugen kann die Auswahl einer sinnvollenQuellmenge bzw. des benötigten Data Mining Verfahrens erheblich verein-fachen.

� AnwendungenNeben den Fragen nach der technischen Realisierung stehen auch Fragennach der Verwendung der gefundenen Muster offen: Wie können die ge-fundenen Muster erfolgreich in die geschäfts– oder entscheidungsfindendenBereiche eingebracht werden? Wie integriert man das erarbeitete Wissen inbestehende Wissensbasen oder Expertensysteme?

3

Das Finden vonAssoziationsregeln

Dieses Kapitel schafft die theoretischen Grundlagen, die zum Verständnis von As-soziationsregeln nötig sind. Zunachst werden allgemeingültige Definitionen undein generischer Algorithmus zum Finden von Assoziationsregeln beschrieben. Inden folgenden Abschnitten werden Algorithmen zum Finden von boolschen Asso-ziationsregeln (Seite 23), generalisierten Assoziationsregeln (Seite 36) und quan-titativen Assoziationsregeln (Seite 45) vorgestellt.

3.1 Einf uhrung

Das Finden von Assoziationsregeln stützt sich auf eine kleine Anzahl von Be-griffen, die nun erläutert werden. Danach wird ein generischer Algorithmus zumFinden von Assoziationsregeln skizziert und ein einfacher Algorithmus zum Ge-nerieren von Assoziationsregeln aus häufigen Artikelmengen präsentiert.

3.1.1 Grundlegende Definitionen

Assoziationsregeln beschreiben Korrelationen zwischen gemeinsam auftretendenDingen [Bol96]. ,,Dinge” konnen in diesem Zusammenhang sehr unterschiedli-cher Natur sein: Im Kontext eines Kaufhauses würde es sich um Waren, wie zumBeispiel ,,Schokolade” oder ,,Brot” handeln. Im Rahmen der medizinischen Dia-gnose 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]:

AssoziationsregelnSeiI = fI1; I2; : : : ; Img eine Menge von Attributen, die manals Artikel (items) bezeichnet. EineTransaktionT besteht aus einer Menge vonArtikeln, so dassT � I gilt. D sei als die Datenbank gegeben, in der alle Trans-aktionen gespeichert sind. MitjDj wird die Große der Datenbank als Anzahl derTransaktionen definiert. Eine TransaktionT unterstutzt(supportet) X, eine Men-ge einiger Artikel ausI, wennX � T gilt. Eine Assoziationsregelist dann eineImplikation der FormX ) Y , wennX � I, Y � I undX \ Y = ; gilt.

Einek-ErweiterungE einer ArtikelmengeX 2 I undX = fi1; : : : ; ing ist eineObermenge vonX undE hat folgende Eigenschaft:E = fi1; : : : ; in; in+1; : : : ; in+kg, so dass giltX \ fin+1; : : : ; in+kg = ; undin+1; : : : ; in+k 2 I.

Support und Konfidenz Eine RegelX ) Y hat einen Support (support) von sProzent, wenns Prozent der Transaktionen ausD die Artikel dieX [Y enthalten.Formal ausgedrückt definiert sich also der Support der RegelX ) Y :

support(X ) Y ) =jft 2 D j (X [ Y ) � tgj

jDj(3.1)

Eine RegelX ) Y besitzt eineKonfidenz(confidence) von c Prozent, wenncProzent der Transaktionen inD, dieX enthalten, auchY enthalten. Die formaleDefinition der Konfidenz erschließt sich also wie folgt:

confidence(X ) Y ) =jft 2 D j (X [ Y ) � tgj

jft 2 D j X � tgj=

support(X ) Y )

support(X)(3.2)

Eine Artikelmenge wird alshaufig(frequent, large, strong) bezeichnet, wenn sieeinen vom Benutzer vorgegebenen Supportwert (min support) uberschreitet.

3.1.2 Generischer Algorithmus

Das Problem des Findens von Assoziationsregeln lässt sich nun als das Problembeschreiben, inD alle Implikationen der FormX ) Y zu finden, deren Supportund Konfidenz größer als die vom Benutzer vorgegebenen Schranken sind.

Alle Verfahren folgen dabei der gleichen Struktur, die in Algorithmus 3.1.1 wie-dergegeben ist:

3.1. Einfuhrung 21

Algorithmus 3.1.1Generischer Algorithmus zum Finden von Assoziationsregeln(1) Finde alle ,,häufigen Artikelmengen” in der DatenbasisD.(2) Generiere aus diesen Mengen die Regeln,

welche die vorgegebene Konfidenz erfüllen.(3) Filtere die Regeln nach Interesse des Benutzers.

Die drei Unterpunkte sollen nun näher betrachtet werden:

(1) Finden der haufigen ArtikelmengenDie Feststellung der häufigen Artikel-mengen bildet den Kern aller Verfahren. Hier treten die wesentlichen Unterschie-de zwischen den einzelnen Algorithmen auf. Eine genaue Beschreibung verschie-dener Vorgehensweisen folgt in den nächsten Abschnitten.

(2) Generierung der RegelnNachdem die häufigen Artikelmengen mit Hilfe derAlgorithmen gefunden wurden, können die Regeln gebildet werden. Algorithmus3.1.2 stellt das ad–hoc Verfahren aus [AS94b] zur Generierung von Regeln vor.Dabei seiLk die Menge der häufigen Artikelmengen mit der Größek.

Algorithmus 3.1.2 Ad–hoc Algorithmus zur Regelgenerierungforall (Lk, k > 2) f

call genrules(lk, lk);g

proceduregenrules(lk: frequentk–itemset,am: frequentm–itemset)fA = f(m� 1)–itemsetsam�1 j am�1 � amg;forall (am�1 2 A) f

conf = support(lk) / support(am�1);if (conf � minconf ) f

produceRule(am�1 ) (lk � am�1));with confidence = conf andsupport = support(lk)

if (m� 1 > 1)genrules(lk, am�1);

gg

g

(3) Filtern der Regeln Die Assoziationsregelverfahren generieren meist einegroße Anzahl von Regeln, welche für den Benutzer schwer überschaubar sind.Folglich ist es angebracht, die Regeln nach ihrem ,,Interessegrad” zu filtern. Die-ser Interessegrad kann von sehr unterschiedlicher Natur sein. So bietet es sich


beispielsweise an, die Regeln nach ihrem Konfidenzwert zu sortieren. Bei gene-ralisierten bzw. quantitativen Assoziationsregeln kann man Regeln verwerfen,wenn sie von anderen Regeln bereits mitabgedeckt werden. Der Verlust vonmoglicherweise interessantem Detailwissen wird dabei allerdings in Kauf genom-men. Eine detaillierte Beschreibung dieser Filtermethoden wird in 3.3.5 und 3.4.5gegeben.

Ein alternativer Ansatz, die für den Benutzer interessanten Regeln zu finden, wirdin [KMR+94] beschrieben: Dort kann der Nutzer mit Hilfe vonTemplatesin-teressante Regeln umschreiben, welche dann in den bestehenden Regeln gesuchtwerden. Nachteilig ist hier jedoch, dass vor der Selektion zunächst alle Regeln er-zeugt werden müssen. Eine Filterung schon während der Regelgenerierung wäreweitaus kosteneffizienter. So untersuchen Srikant et al. in ihrem Aufsatz [SVA97],inwieweit sich Contraints über die An- oder Abwesenheit von Artikelkombinatio-nen in den Generierungsprozess integrieren lassen.

Die visuelle Unterstützung bei der Filterung der Regeln und dem allgemeinenUberblick der Ergebnisse hat sich in vielen Data Mining Werkzeugen als sehrhilfreich herausgestellt. In [KMR+94] wird beschrieben, wie man Regeln in Hy-pergraphen visualisieren kann. Ebenso unterstützen Darstellungen statistischerWerte (Regelgrößen und –häufigkeiten) den Benutzer beim Finden interessanterMuster.

3.1.3 Arten von Assoziationsregeln

Es ist sinnvoll, Assoziationsregeln nach den Attributarten, über denen sie erzeugtwerden, zu unterteilen. Regeln, die über boolschen Attributwerten gebildet wer-den (der Artikel ist in der Transaktion enthalten oder nicht), nennt manboolscheAssoziationsregeln. Auf verschiedene Verfahren zur Bildung dieser Regeln wirdin Abschnitt 3.2 eingegangen. Oftmals ist es interessant zwischen den einzel-nen Artikeln hierarchische Verwandtschaftsbeziehungen zu definieren. SolcheTaxonomienhelfen in vielen Fällen bisher unentdeckte Regeln zu finden. Aufeinige Ansatze zur Generierung solchergeneralisierten Assoziationsregelnwirdin Abschnitt 3.3 eingegangen. In der Praxis sind die Attributwerte jedoch meistnicht von boolscher Natur. Regeln über quantitativen oder kategorischen Attribut-auspragungen bezeichnet man alsquantitative Assoziationsregeln. Sie werden inAbschnitt 3.4 vorgestellt.

3.2. Einfache boolsche Assoziationsregeln 23

3.2 Einfache boolsche Assoziationsregeln

Verfahren fur boolsche Assoziationsregelnbilden Regeln über boolschen Attribut-auspragungen. Es wird also geprüft, ob der jeweilige Artikel in den Transaktionenenthalten ist oder nicht. Verschiedene Verfahren zum Finden von boolschen As-soziationsregeln beschreiben die folgenden Abschnitte.

3.2.1 AIS

Das AIS–Verfahren wurde erstmals 1993 in [AIS93] vorgestellt und wird als einerder ersten Algorithmen zum Finden von Assoziationsregeln betrachtet. Algorith-mus 3.2.1 zeigt das Grundgerüst des Verfahrens.

Das Verfahren läuft so lange in einer Schleife, bis dasfrontier setkeine Mengenmehr enthält. Demfrontier setkommt hierbei eine besondere Rolle zu: Währendder Algorithmus die Datenbasis komplett durchläuft, wird jedes Tupelt einzelnherausgenommen.

Nun wird fur jede Mengef aus demfrontier setgepruft, ob sie int enthaltenist. Ist dies der Fall, so werden Erweiterungen vonf generiert und in die Kandi-datenmengeCf eingefugt. Die Generierung dieser Kandidatencf wird in einemgesonderten Abschnitt besprochen. Die Häufigkeit jedes einzelnen Kandidatenwird gezahlt, damit diejenigen, die denmin supporterreichen, in die MengeLder haufigen Artikelmengen aufgenommen werden können.

Am Ende eines jeden Durchgangs wird die Entscheidung getroffen, welche die-ser Kandidaten in dasfrontier setdes nachsten Durchgangs aufgenommen wer-den. Die Voraussetzungen, welche zur Bildung des neuenfrontier setszutreffenmussen, werden später geklart.

Generierung der Kandidatencf 2 Cf

Bei der Generierung der Kandidaten geht das Verfahren nach der rekursiven Pro-zedurExtendvor. Die Sortierung nachIj vermeidet dabei eine mehrfache Erzeu-gung derselben Artikelmengen.

Insgesamt werden also alle Artikelkombinationen in die KandidatenmengeCf

aufgenommen, die als häufig angenommen werden, so wie auch die rekursivenErweiterungen dieser Kandidaten. ,,Nicht häufig” geschätzte Artikelmengen wer-den zwar aufgenommen, aber nicht weiter expandiert. Sollten sich diese als ,,nichthaufige” Artikelkombinationen angenommenen Mengen später doch als häufig er-weisen, so wird ein weiterer Durchgang durch die Datenbasis nötig sein (dies wird


Algorithmus 3.2.1 Das AIS–VerfahrenL = ;; // the frequent itemsetsF = f;g; // the frontier set

while (F 6= ;) fC = ;; // the candidate setforall (t 2 D) f

forall (f 2 F ) fif (f � t) fCf = candidates that are extensions of f (contained in t)forall (cf 2 Cf ) f

if (cf 2 C)cf :count = cf :count+ 1;

elsefcf :count = 0;C = C + cf ;

gg

g

F = ;;forall (c 2 C) f

if ( c:countjDj

> min support)L = L+ c;

if (c should be used as a frontier in the next pass)F = F + c

gg

in der Bestimmung desfrontier setsnaher untersucht).

Eine wichtige Frage stellt die Schätzfunktion dar, mit der man festlegt, ob eineArtikelkombination als häufig angenommen werden soll.

Agrawal, Imielinsky und Swami benutzen in [AIS93] zur Schätzung die stati-stische Unabhängigkeitsannahme: Nimmt man an, dass die MengeX + Y eineErweiterung desfrontier setsX ist und weiterhinY = I1; I2; : : : ; IK gegeben ist,so berechnet sich der erwartete Support�s wie folgt:

�s = f(I1) � f(I2) � : : : � f(Ik) �(x� c)

jDj(3.3)


Prozedur 3.2.1ExtendprocedureExtend(X: itemset,t: tuple)f

let Ij be such that8Il 2 X; Ij � Ilforall (Ik 2 t; Ik > Ij) f

AddXIk toCf .if (XIK) is expected to be frequent

Extend(XIk, t)g

g

f(Ik) kennzeichnet hier die relative Häufigkeit des ArtikelsIk in der DatenbankD. Die Variablex gibt die absolute Anzahl der Tupel inD an, dieX enthalten. Inc ist die relative Tupelzahl enthalten, die im aktuellen Durchgang schon untersuchtwurde undX enthielt (aber noch nichtX + Y ).

Man kann(x�c)jDj

als den aktuellen Support vonX in der verbliebenen Datenbasisbezeichnen. Unter der Annahme statistischer Unabhängigkeit folgert man nun,dass sich der erwartete Support fürX+Y aus dem Produkt zwischen dem SupportvonX und den einzelnen relativen Häufigkeiten der Artikel ausY ergibt.X + Ywird als haufig angenommen, wenn�s denmin supporterreicht.

Bestimmung desfrontier setsFAm Ende eines jeden Laufes wird dasfrontier set fur den nachsten Durchgangbestimmt. Hier müssen nur diejenigen Mengen in das neuefrontier setaufgenom-men werden, die zwar als ,,nicht häufig” angenommen wurden, sich aber späterbei derUberprufung doch als häufig erwiesen.

Dies begrundet sich folgendermaßen: Wurde eine MengeX als ,,nicht haufig”angenommen, wurden auch keine ErweiterungenX+Ik vonX gebildet. Folglichkonnte auch keine ErweiterungX+Ik auf Haufigkeituberpruft werden. Trotzdemkonnen bestimmte Erweiterungen vonX auch wieder häufig sein, da sich jaXals haufig herausgestellt hat. Aus diesem Grund wirdX in das frontier setFeingefugt.

Mengen, die als ,,nicht häufig” angenommen wurden und sich bei derUberprufung auch als ,,nicht häufig” erwiesen, müssen nicht weiter untersuchtwerden, da ErweiterungenX + Ik einer ,,nicht häufigen” MengeX keinengroßeren Support haben können alsX selbst.

Andererseits muss auch keine MengeX eingefugt werden, die im letzten Durch-gang als häufig angenommen wurde, da schonX und alle Erweiterungen von


X im letzten Durchgang überpruft wurden. Dies wird durch die Prozedur 3.2.1(EXTEND) gesichert.

Daher reicht es aus, nur diejenigen Mengen in dasfrontier setF aufzunehmen,die zuvor als ,,nicht häufig” angenommen, aber bei derUberprufung als haufigerkannt wurden.

BeispielEin Beispiel soll die Generierung der Kandidaten und den Schätzprozessverdeutlichen: Sei die Menge der verfügbaren ItemsI = fA;B;C;D;E;Fg inalphabetischer Weise sortiert und dasfrontier setbestehe momentan nur aus derArtikelmengeF = fABg. Fur ein Tupelt = ABCDF aus der Datenbank wer-den die folgenden Artikelmengen generiert:

Menge Erwartung Aktion

ABC haufig expandiere weiterABCD nicht haufig nicht weiter expandierenABCF haufig weitere Expansion nicht möglichABD nicht haufig nicht weiter expandierenABF haufig weitere Expansion nicht möglich

Die MengenABCF undABF wurden zwar als häufig angenommen, konntenaber nicht weiter erweitert werden, da sich kein Artikel int befindet, der größeralsF ist. Die KombinationenABCE undABE wurden nicht untersucht, da derArtikel E nicht in t enthalten ist. Die KombinationABCDF (wie auchABDF )wurde nicht generiert, daABCD (ABD) als “nicht haufig” geschätzt wurde. Ausdiesem Grund erzeugte dieExpand-Prozedur keine Erweiterungen.

3.2.2 SetM

Das in [HS93] vorgestellte SETM–Verfahren zeigt den Ansatz, das Finden vonAssoziationsregeln eng mit der Datenbanksprache SQL zu koppeln. So lässt sichder komplette Algorithmus mit SQL–Befehlen beschreiben. [HS93] präsentiertdaher den Algorithmus auch in SQL. Um eine einheitliche Darstellung in die-ser Arbeit zu gewährleisten, wird der das SETM–Verfahren in Algorithmus 3.2.2durch Pseudocode notiert.

Im Gegensatz zu AIS trennt SETM die Generierung der Kandidaten von derBerechnung des Supports. In jedem Durchgang sucht er pro Transaktion diehaufigen Artikelmengen aus dem vorherigen Durchlauf und generiert daraus die1–Erweiterungen. Diese werden inCt gespeichert. Analog dazu werden inCk die


Algorithmus 3.2.2 SETML1 = ffrequent 1-itemsetsg;L1 = ffrequent 1-itemsets together with the TIDs

in which they appear, sorted on TIDg;k = 2;while (Lk�1 6= ;) fCk = ;;forall (T 2 D) f

Lt = fl 2 Lk�1 j l:T ID = t:T IDg; // frequent(k � 1)-itemsets inTforall (lt 2 Lt) fCt = 1-extensions ofLt contained inT ; // candidates inTCk = Ck + f< t:TID; c > j c 2 Ctg;

ggSortCk on itemsets;Delete all itemsetsc 2 Ck for which c:count < min support givingLk;Lk = f< l:itemset; count ofl in Lk > j l 2 Lkg; // with previous stepSortLk on itemsets;k = k + 1;

gResult =

Sk Lk

Kandidaten plus ihrer zugehörigen TID (Transaktionsidentifikation) mitgeführt.Spater wird das Zählen des Supports durch das Sortieren und Zusammenfassendieser Struktur ermöglicht.

Offensichtlich liegt der Nachteil dieses Verfahrens in der Größe der Kandidaten-mengeCk, da jeder Kandidat ausCk so viele Eintrage enthält, wie es Transaktio-nen mit dieser Artikelmenge gibt. Das Sortieren der MengenLk undCk bedeutetein weiteres Performanzproblem, da es in jedem Durchgang ausgeführt werdenmuss.

Auf der anderen Seite kann SETM einfach (in SQL) implementiert werden. Aufdiese Weise lässt sich relativ schnell ein Assoziationsregel–Verfahren in SQL-Datenbanken implementieren.

3.2.3 Die Apriori–Klasse

Den Algorithmen der APRIORI–Klasse liegt allen die gleiche Idee zu Grunde, dieerstmals in [AS94a] vorgestellt wurde. Hier sollen zuerst das Orginalverfahren


und dann seine Modifikationen beschrieben werden.

3.2.3.1 Apriori

Ahnlich zu SETM berechnet der APRIORI–Algorithmus [AS94a] sukzessive diehaufigen Artikelmengen mit1; 2; 3; : : : n Artikeln.

Algorithmus 3.2.3 APRIORI

L1 = ffrequent 1-itemsetsg;k = 2;while (Lk�1 6= ;) fCk = new candidates of sizek generated fromLk�1;forall (T 2 D) f

Ct = subset(Ck; t);forall (candidatesc 2 Ct) f

c.count++;g

gLk = all candidates inCk with minimum support;k = k + 1;

gResult =

Sk Lk

Dabei geht das Verfahren nach einem einfachen Schema vor: Zunächst werdendie haufigen Einzelartikel bestimmt. In jedem weiterenk–ten Durchgang wer-den dann Kandidaten für diek-elementigen häufigen ArtikelmengenLk generiert.Hierfur dienen die schon berechneten(k � 1)-elementigen häufigen Artikelmen-genLk�1. Im Anschluss daran wird der Support der Kandidaten in einem kom-pletten Durchlauf durchD gezahlt. Diejenigen Kandidaten, die denmin supporterreichen, werden inLk aufgenommen.

Generierung der KandidatenDie Prozedur aprioriGeneration beschreibt die Bildung der Kandidaten imk-tenSchritt: Wie man sieht, erzeugt die Prozedur ausLk�1 eine Obermenge vonLk.Die Korrektheit wird im Folgenden bewiesen.

Beispiel Es seien die häufigen ArtikelmengenL3 gegeben:f(Milch Brot Cola)(Milch Brot Fanta) (Milch Cola Fanta) (Milch Cola Twix) (Brot Cola Fanta)g.Nach dem Join enthält die KandidatenmengeC4 die beiden Elementef(MilchBrot Cola Fanta) (Milch Cola Fanta Twix)g. Da die Teilmenge (Milch FantaTwix) nicht in L3 enthalten ist, wird (Milch Cola Fanta Twix) im Prune-Schritt


Prozedur 3.2.2aprioriGenerationprocedureaprioriGeneration (Lk�1)f

// join Lk�1 ./ Lk�1 so that each (k-1)–subsetI 0 � I is contained inLk�1

Ck = ffi1; i2; : : : ; ikg j 81 � j � k : fi1; i2; : : : ; ikg � ij 2 Lk�1 gg

wieder entfernt. Somit bleibt nur (Milch Brot Cola Fanta) in der Kandidatenmen-ge erhalten.

Korrektheit des AlgorithmusDer APRIORI–Algorithmus arbeitet korrekt, wenn alle häufigen ItemmengenLk

berechnet werden. Dies hängt aber unmittelbar davon ab, ob die Berechnung derKandidatenmenge richtig erfolgt. Zu zeigen ist also, dassCk � Lk gilt.

Zum Beweis nützt man die Eigenschaft, dass jede Teilmenge einer häufigen Item-menge wieder eine häufige Itemmenge sein muss. Nun erweitert man jede Item-menge ausLk�1 um ein Item. Iteriert man die Expansion dieser Itemmenge fürjedes mogliche Item, so erhält man fur jede Itemmenge ausLk�1 eine Mengek–elementiger Obermengen. Aus diesen Obermengen können dann diejenigenItemmengen gelöscht werden, deren beliebige(k � 1)-Teilmengen nicht inLk�1

liegen. Die Obermengen-Eigenschaft vonLk bleibt dabei erhalten, da keine Men-ge geloscht wird, die inLk liegen konnte.

Genau diese Vorgehensweise beschreibt der AlgorithmusaprioriGeneration: DerJoin-Schritt entspricht der Expansion der Itemmengen um alle weiteren möglichenItems. Die Bedingungpk�1 < qk�1 sichert lediglich die Vermeidung von re-dundanten Duplikaten. Das Entfernen der Itemmengen, welche keine(k � 1)-elementigen Teilmengen inLk besitzen, wird im Prune-Schritt beschrieben. Folg-lich liefert aprioriGenerationeine Obermenge vonLk und es giltCk � 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, verwen-det APRIORITID [AS94a] eine alternative Datenstruktur bei der Berechnung derhaufigen Artikelmengen: Nachdem die Kandidaten wie bei APRIORI generiertwurden, benutzt man nun die MengeCk zur Berechnung des Supports. DieseMenge wird zu Anfang des Algorithmus mit Hilfe eines Datenbankscans aufge-baut und pro Iteration an die Entwicklung angepaßt. Dabei istCk eine Men-


ge mit Tupeln von der Form< TID; fXkg >, so dass jedes einzelneXk einemoglicherweise häufige k-Artikelmenge ist, die in der Transaktion mit der Num-merTID enthalten ist.

Beispiel Sei die DatenbankD = f[1: A C D], [2: B C E], [3: A B C E], [4: BE]g gegeben. Die erste Zahl jedes Eintrags symbolisiert die TID. Der minimaleSupport liegt bei 2 Transaktionen. Für k = 1 enthalt C1 also die vollstandigeDatenbankD in einer alternativen Speicherstruktur. Mit steigendemk schrumpftjedoch die Größe vonCk. Folglich istC1 undC2 wie in Tabelle 3.1 gegeben. DieGenerierung vonCj (j > 2) erfolgt analog.

TID C1 Eintrage

1 fAg, fCg, fDg2 fBg, fCg, fEg3 fAg, fBg, fCg, fEg4 fBg, fEg

TID C2 Eintrage

1 fA Cg2 fB Cg, fB Eg, fC Eg3 fA Bg, fA Cg, fA Eg

fB Cg, fB Eg, fC Eg4 fB Eg

Abbildung 3.1: Beispiel furC1 undC2

In Algorithmus 3.2.4 ist eine detaillierte Darstellung des Verfahrens gegeben.

3.2.3.3 AprioriHybrid

Wahrend der APRIORI–Algorithmus durch die Datenbankläufe in jeder IterationPerformanzschwächen aufweist, benötigt APRIORITID in der Anfangsphase ex-trem viel Arbeitsspeicher. Das APRIORIHYBIRD–Verfahren [AS94a] kombiniertnun beide Ansätze mit dem Ziel, die gegenseitigen Schwächen auszugleichen.

Es ist namlich nicht zwingend erforderlich, denselben Algorithmus für den voll-standigen Data Mining Prozess einzusetzen. APRIORI und APRIORITID verwen-den die gleiche Prozedur zur Kandidatengenerierung und arbeiten daher mit dengleichen Artikelmengen. Dies macht es möglich, im Lauf “on-the-fly” zwischenden beiden Verfahren zu wechseln.

In der Anfangsphase ist es sinnvoll, den speicher–sparsamen APRIORI zur Gene-rierung der häufigen ArtikelmengenLk einzusetzen. Sobald die StrukturCk aberin den Arbeitsspeicher paßt, erweist sich ein Umschalten auf den APRIORITIDals erfolgversprechend. Am Ende eines jeden Durchlaufs wird mit Formel 3.4geschatzt, obCk in den Arbeitsspeicher gepasst hätte.


Algorithmus 3.2.4 APRIORITIDL1 = ffrequent 1-itemsetsg;C1 = databaseD;k = 2;while (Lk�1 6= ;) fCk = new candidates of sizek generated fromLk�1;Ck = ;;forall (T 2 Ck�1) f

// determine candidate itemsets inCk contained in// the transaction with identifierT:TIDCt = 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 inCt;if (Ct 6= ;)Ck = Ck + < t:TID; Ct >;


gResult =

Sk Lk

24Xc2Ck

support(c)

35 + number of transactions (3.4)

Wenn in der aktuellen Iteration weniger häufige Artikelmengen erzeugt wurdenals in der vorherigen und die MengeCk nach dem obigen Schätzwert in den Spei-cher gepasst hätte, dann wird in den APRIORITID gewechselt. Die zusätzlicheAddierung der Transaktionenzahl (number of transactions) soll einen Wechselvermeiden, wennCk im aktuellen Durchlauf in den Speicher gepaßt hätte, aberCk+1 in der nachsten Iteration nicht.

Es ist allerdings zu beachten, dass der Wechsel zwischen APRIORI und APRIO-RITID teuer ist, da hierfür die komplette DatenstrukturCk erzeugt werden muss.

3.2.3.4 OCD

Das OCD–Verfahren [MTV94] entstand relativ gleichzeitig mit dem APRIORI–Algorithmus und beschreibt grundsätzlich die gleiche Vorgehensweise. OCD eli-


miniert ebenfalls unmögliche Kandidaten vor dem Datenbankdurchlauf, die aprio-ri nicht haufig sein konnen.

Der Unterschied liegt im Wesentlichen in den Feinheiten der Kandidatengene-rierung: So definieren sich die (k+1)–Artikelmengen, welche als Kandidaten inFrage kommen, wie folgt:

Ck+1 = fX � I j jXj = k + 1 ^X includes s+ 1 members of Lkg (3.5)

Da hier zu viele Artikelmengen generiert werden, bieten die Autoren in [MTV94]eine kleinere KandidatenmengeC 0

k+1 an:

C 0k+1 = fX [X 0 j X;X 0 2 Lk ^ jX \X 0j = k � 1g (3.6)

Es wird also eine Obermenge von Kandidaten zu der oben vorgestellten APRIORI–Kandidatengenerierung erzeugt.

Beipiel SeiL3 = fABC;ABD;ACD;ACE;BCDg gegeben. APRIORI wurdenur C4 = fABCDg als Kandidaten erzeugen, während OCD die Kandidaten-mengeC 0

4 = fABCD;ABCE;ACDEg generieren würde.

Als eine Optimierung ihres Verfahrens schlagen Mannila et al. in [MTV94] vor,Kandidaten verschiedener Größen zusammen zu generieren und diese dann ge-meinsam in einem einzigen Datenbankdurchlauf zu überprufen. So wird die zeit-intensive Anzahl der Datenbankdurchläufe minimiert. Bei der Generierung derKandidaten verfolgt OCD dabei einen weiteren Ansatz:

Es sei die häufige ArtikelmengeFs gegeben. Anstelle jede KandidatengruppeCs+j einzeln aus der vorherigen KandidatengruppeCs+j�1 zu generieren, wer-den alle MengenC 0

s+1; : : : ; C0s+c gleichzeitig aus Vereinigungen vonCs–Paaren

berechnet. Die KandidatenmengeCs+j berechnet sich ausC 0s+j, indem fur je-

desX 2 C 0s+j getestet wird, ob es genau

�s+js

�Mengen ausLs enthalt. Diese

Methode wird von den Autoren [MTV94] alsc-extensionbezeichnet.

BeispielSeiL2 = fAB;AC;BC;AD;BD;CD;AE;FG;BGg als haufige 2er–Artikelmenge gegeben. Es lässt sich nun leicht errechnen, dassL5 = ; sein muss,da�52

�= 10 und damit großer alsjL2j = 9 ist. Damit lassen sich keine Kandidaten

fur L5 generieren, da jedesX 2 C5 in 10 Artikelmengen vonL2 enthalten seinmusste.

Es ist leicht ersichtlich, dass diese Methode für kleine Kandidatengruppen sehrvorteilhaft ist, da durch die Zusammenfassung Datenbankdurchläufe eingespartwerden konnen.


3.2.4 Partition

Das PARTITION–Verfahren [SON95] verfolgt den Ansatz, die Anzahl der kom-pletten Datenbankdurchläufe zu minimieren. So kann es garantieren, dass zumFinden aller häufigen Artikelmengen nicht mehr als zwei vollständige Daten-bankscans nötig sind. Dabei teilt sich der Algorithmus in zwei Phasen auf:

1. PhaseIn der ersten Phase wird die gesamte DatenbasisD in etwa gleich großelogische Partitionen aufgeteilt. Diese Partitionen dürfen sich nicht überlappen undbeinhalten Transaktionen ausD. Auf diese Weise wirdD komplett durch die Par-titionen abgedeckt. Nun werden für jede einzelne Partition die dafür haufigen Ar-tikelmengen generiert. Die im Kontext dieser Partition häufigen Artikelmengenwerden alslokal haufige Artikelmengenbezeichnet. Am Ende der ersten Phasewerden die lokal häufigen Artikelmengen aller Partitionen miteinander vermischt.Die daraus resultierende Gesamtmenge markiert die Kandidaten für den Berech-nungslauf in der zweiten Phase.

2. PhaseMit den in der ersten Phase gewonnenen Kandidaten kann die zweitePhase begonnen werden. Ein weiterer Datenbankdurchlauf klärt, welche der Kan-didaten denmin supporterreichen und welche nicht. Im Kontext der gesamtenDatenbank spricht man dann vonglobal haufigen Artikelmengen. Die grundle-gende Idee dieses Verfahrens besteht also darin, dass jede global häufige Artikel-menge in mindestens einer Partition lokal häufig sein muss.

Prozedur 3.2.3generateCount(CG: globalCandidateSet,p: databasePartition)

proceduregenerateCount(CG: globalCandidateSet,p: databasePartition)f

forall (1-itemsets)generate the TID-list

for (k = 2; CGk 6= ;; k++) f

forall (k-itemsetc 2 CGk ) f

templist = c[1]:tidlist\ c[2]:tidlist\ : : : c[k]:tidlist;c:count = c:count+ jtemplistj;

gg

g

Wahl der Partitionsgr oßeVon entscheidender Bedeutung ist die richtige Wahl der Partitionsgröße. Arbei-tet man mit großen Partitionen, so verringern sich die Datenbankzugriffe und derMischaufwand in der 1. Phase. Allerdings ist mit einem vermehrten Swap-Zugriff


zu rechnen, wenn die Partition nicht mehr in den Arbeitsspeicher passt. Zu kleinePartitionen erhöhen aber wieder unötig den Zugriff auf die Datenbank. Folglichsollte der Umfang einer Partition gerade so groß gewählt werden, dass sie kom-plett im Arbeitsspeicher untergebracht werden kann.

Algorithmus 3.2.5 PARTITION

P = partition the Database(D);n = number of partitions;

// Phase 1for (i = 1; i � n; i++) f

readPartition(pi 2 P );Li = generateFrequentItemsets(pi);

g// now mergefor (i = 2; Li 6= ;; j = 1; 2; : : : ; n; i++)CGi =

Sj=1;2;:::;n L

ji ;

// Phase 2for (i = 1; i � n; i++) f

readPartition(pi 2 P );forall (candidatesc 2 CG)

generateCount(c; pi);g

gResult =fc 2 CGjc:count � min supportg;

Die globale KandidatenmengeVor Eintritt in die 2. Phase wird eine globale Kandidatenmenge durch das Mi-schen der lokal häufigen Artikelmengen erzeugt. Die Größe dieser Menge ist sehrwichtig fur die Effizienz des Algorithmus, da sie vollständig wahrend der 2. Phasebenotigt wird. Dennoch lassen sich keine genauen Aussagen treffen. Die jeweili-gen Charakteristika der Daten und der benutzerdefinierte Support haben nämlicheinen großen Einfluss auf die Generierung. Als obere Schranke lässt sich jedochGleichung 3.7 angeben.

Die Anzahl der Partitionen ist hier mitn gegeben undjcj als die Anzahl der Ele-mente in der Artikelmengec. Versuche in [SON95] haben jedoch gezeigt, dassdie resultierende Kandidatenmenge erheblich kleiner ausfällt.

j globalCandidates j � n �maxfjcj j c 2 localCandidatesg (3.7)


Die verwendeten Notationen sind wie folgt zu verstehen:CGi sind die Kandidaten

fur die global haufigeni–Artikelmengen.Lji sind die lokal haufigen Artikelmen-

gen in der Partitionpj undCG ist die Menge der globalen Kandidaten.

Die ProzedurgenerateFrequentItemsets(pi) erzeugt die lokal h¨aufigen Artikel-mengen. Hierf¨ur kann ein beliebiger Algorithmus, wie zum Beispiel APRIORI

benutzt werden.


3.3 Generalisierte Assoziationsregeln

Oftmals lassen sich Artikel logisch gruppieren oder auch Beziehungen zwischeneinzelnen Artikeln definieren. Die Verwendung von Taxonomien kann zu wesent-lich interessanteren Ergebnissen führen.

3.3.1 Einf uhrung

Eine Taxonomie kennzeichnet eineist–ein–Beziehung zwischen zwei Artikeln.Abbildung 3.2 zeigt den Ausschnitt einer Taxonomie im Kontext eines Kaufhau-ses. Hier gilt beispielsweise:H–Milch ist–eineMilch oderBrot ist–einLebens-mittel.

VollmilchH-Milch

Milch Brot

VollkornbrotWeißbrot

Lebensmittel

CD-Player

HiFi

Receiver

Elektronik

Apple Mac PC

Computer

Abbildung 3.2: Beispiele fur Kaufhaus-Taxonomien

In der realen Welt ist meist eine Vielzahl von Taxonomien zwischen Artikeln ge-geben. So können Taxonomien über Preiskategorien (billig, teuer, Sonderange-bote, : : :) oder auch Warengruppen (Lebensmittel, Kleidung,: : :) gebildet wer-den. Multiple Taxonomien werden in der Regel als gerichtete, azyklische Graphen(DAG) modelliert.

Selbstverständlich bedeutet die Erstellung solcher Strukturen einen Mehraufwand

3.3. Generalisierte Assoziationsregeln 37

fur den Benutzer, der diese Beziehungen zuerst manuell definieren muss. Trotz-dem kann die Einbeziehung von Taxonomien in den Data Mining Prozess vorteil-haft sein:

� Bei einer großen Anzahl von Artikeln können viele Artikel denmin supportnicht mehr erreichen, wenn es zu wenig Transaktionen gibt, die diese un-terstutzen. Dies wäre aber sehr wohl möglich, wenn man die vorhandenenArtikel hierarchisch gruppieren würde.Beispiel: [H–Milch )Weißbrot] erreicht denmin supportnicht mehr, aber[Milch ) Weißbrot], da [Vollmilch) Weißbrot] ausreichend häufig vor-handen ist.

� Taxonomien können auf einfache Weise zum Filtern von redundanten unduninteressanten Regeln benutzt werden. Auf die Filterung wird in Abschnitt3.3.5 eingegangen werden.

DefinitionSeiI = fi1; i2; : : : ; img eine Menge von Literalen, auch Artikel (items) genannt.Sei weiterT ein gerichteter azyklischer Graph auf diesen Literalen. Eine Kantein T reprasentiert eineist-ein–Beziehung, so dassT die Menge der Taxonomienreprasentiert. Gibt es inT eine Kante vonp nachc, so nennt manp denVater(parent) von c undc ein Kind (child) von p. Weiter nennt manx einenVorfahren(ancestor) vonx, wenn es einen Pfad vonx nachx gibt. x ist eindirekter Vorfahre(close ancestor) vonx, wenn es keinen weiteren Artikely gibt, so dass gilt:y istVorfahre vonx und x ist Vorfahre vony. Vorfahren haben generell die gleicheAnzahl von Artikeln wie ihre Kinder.

SeiD die Menge der zu untersuchenden TransaktionenT (T � I). Eine Trans-aktionsupporteteinen Artikelx 2 I, wennx in T enthalten ist oder ein Vorfahrevonx. Folglich supportetT eine ArtikelmengeX � I, wenn T jeden Artikel ausx supportet.

Eine generalisierte Assoziationsregel(generalized association rule) ist eine Im-plikation der FormX ) Y (X � I, Y � I, X \ Y = ;), so dass kein ArtikelausY ein Vorfahre eines Artikel ausX ist.

Anmerkungen zu Support und KonfidenzWenn eine Mengefx; yg den minimalen Support erreicht, dann wird ersichtli-cherweise auch dermin supportvonfx; yg; fx; yg undfx; yg gehalten. Anderer-seits gilt dies nicht generell für die Konfidenz: Erreicht eine RegelX ) Y denmin supportund diemin conf, so kann man weiter die minimale Konfidenz nurfurX ) Y garantieren.


Ebenso ist es wichtig anzumerken, dass sich der Support eines Artikels nicht ausder Summe seiner Kinder berechnen lässt. Mehrere Kindartikel können in ei-ner einzelnen Transaktion enthalten sein und so den Support für den Vaterartikelbeeinflussen. Aus diesem Grund ist es auch nicht möglich, den Support in denoberen Hierarchieebenen aus dem Support der Artikel in den Blättern zu berech-nen.

Die Abschnitte 3.3.2, 3.3.3 und 3.3.4 stellen Verfahren zur Berechnung häufigerArtikelmengenuber Taxonomien vor. Aus diesen Mengen können dann, analog zuden einfachen Assoziationsregeln, die Regeln generiert werden. Durch die man-nigfaltigen Verwandtschaftsbeziehungen werden viele redundante und uninteres-sante Regeln generiert. Abschnitt 3.3.5 zeigt, wie man mit Hilfe von Taxonomienuninteressante Regeln filtern kann.

3.3.2 Basic

Die zentrale Fragestellung beim Finden von häufigen Artikelmengen ist, ob eineTransaktion einen Artikel supportet oder nicht. Um die Existenz von Taxonomienerweitert, ergibt sich nun die Frage, ob eine Transaktion einen Artikel oder einenVorfahren des Artikels supportet.

Folglich liegt es nahe, jede TransaktionT um die Vorfahren der Artikel inT zuerweitern. Dann lässt sich, leicht verändert, der bekannte APRIORI–Algorithmuszum Finden von generalisierten Assoziationsregeln verwenden. Dies ist der An-satz des BASIC-Verfahrens [SA95] in Algorithmus 3.3.1.

Algorithmus 3.3.1 BASIC

L1 = frequent 1-itemsets; // includes items at any levelk = 2;while (Lk�1 6= ;) fCk = new candidates of size k generated fromLk�1;forall (T 2 D) f

Add all ancestors of each item inT to T , removing duplicates;Increment the count of all candidates inCk that are contained inT ;


gResult =

Sk Lk;

Zu Beginn werden die häufigen 1-Artikelmengen berechnet. Zu beachten ist, dass


diese Artikel aus jeder beliebigen Hierarchiestufe stammen können.

Danach folgt BASIC der Grundstruktur des APRIORI–Verfahrens: Iterativ werdenzuerst die Kandidaten aus den häufigen Artikelmengen des vorherigen Durch-gangs berechnet. Zur Bestimmung, welche Kandidaten wirklich häufig sind, wirddanach jede Transaktion der Datenbank, erweitert durch die Vorfahren, durchlau-fen. Sobald keine häufigen Artikelmengen mehr gefunden werden können, brichtder Algorithmus ab.

3.3.3 Cumulate

Das CUMULATE–Verfahren [SA95] entsteht im Wesentlichen aus am BASIC–Al-gorithmus, nimmt jedoch einige Optimierungen vor.

1. Filtern der Vorfahren : Der Transaktion werden nur bestimmte Vorfahrender Artikel zugefugt. So mussen nur Vorfahren in die Transaktion eingefügtwerden, die in mindestens einer Kandidatenmenge enthalten sind.

Daruber hinaus ist es nicht nötig, die ursprünglichen Artikel in einer Trans-aktion zu behalten, wenn sie nicht in der Kandidatenmenge enthalten sind.

Beispiel: Sei eine Taxonomie wie in Abbildung 3.2 gegeben undfMilch,Weißbrotg die einzige zu überprufende Kandidatenmenge. Nun kann manim Taxonomiebaum die ArtikelH–Milch undVollmilch durch den überge-ordneten ArtikelMilch austauschen. Folglich wird den Transaktionen nurnochMilch hinzugefugt. Die Artikel Vollmilch und H–Milch wurden ausden Transaktionen entfernt werden.

2. Vorberechnung der Vorfahren: Anstatt jedesmal den Taxonomiegraphenzu durchwandern, können zur Ermittlung der Vorfahren auch im Voraus be-rechnete Tabellen benutzt werden. In diesen Tabellen stehen nur Vorfahren,die auch benötigt werden (siehe Optimierung 1).

3. Wegstreichen von Mengen, die einen Artikel und seinen Vorfahren ent-halten: Die beiden folgenden Lemmas zeigen die Korrektheit dieser Opti-mierung:

Lemma 1 Der Support fur eine ArtikelmengeX, die sowohl den Artikelxals auch seinen Vorfahrenx enthalt, ist der gleiche wie der Support für dieArtikelmengeX � fxg.


BeweisEs ist leicht ersichtlich, dass jede Transaktion, dieX supportet,auchX � x unterstutzt, daX � x � X ist. Nach Definition supportet jedeTransaktion, diex unterstutzt, auchx. Folglich supportet jede Transaktion,dieX � x unterstutzt, auchX.

Lemma 2 WennLk, eine Menge von häufigenk–Artikelmengen, keineMenge enthält, die sowohl den Artikel, wie auch seinen Vorfahren enthält,dann wird die Kandidatengenerierung (siehe Seite 29) keine Menge produ-zieren, die sowohl den Artikel als auch den Vorfahren beinhaltet.

BeweisMan nehme an, dass die Prozedur zur Kandidatengenerierung docheinen KandidatenX erzeugt, der sowohlx als auch seinen Vorfahrenxenthalt. SeiX 0 eine Teilmenge vonX mit k Artikeln, diex und x enthalt.DaX 0 nicht im Prune–Vorgang der Kandidatengenerierung entfernt wordenist, mussX 0 in Lk enthalten sein. Dies ist aber ein Widerspruch zu derBehauptung, dass keine Artikelmenge inLk sowohlx als auchx enthalt.

Das erste Lemma zeigt, dass keine Mengen gezählt werden müssen, dieden Artikel und seinen Vorfahren zusammen enthalten. Diese Erkenntniswird im Algorithmus beim Loschen aller 2er Mengen, die Artikel und Vor-fahre beeinhalten, verwendet. Im zweiten Lemma wird gezeigt, wie die-ser Schritt das Generieren von Kandidatenmengen mit Artikel–Vorfahren–Kombination im weiteren Iterationslauf des Algorithmus verhindert. DieFolge ist offensichtlich eine Reduktion der Kandidatenanzahl, ohne dieVollstandigkeit zu verlieren.

Die oben genannten Optimierungen sind im Algorithmus 3.3.2 mit Kommentarengekennzeichnet.

3.3.4 EstMerge

Der ESTMERGE–Algorithmus [SA95] basiert auf dem vorgestellten CUMULATE–Verfahren, weist jedoch wesentliche Optimierungen auf. FolgendeUberlegungensollen diese Optimierungen motivieren:

StratifizierungMan nehme eine Taxonomie wie in Abbildung 3.2 an. Es sei alsoLebensmittelein Vater vonMilch undMilch wiederum ein direkter Vorfahre vonVollmilch. Er-rechnet man nun, dassfLebensmittel, Computerg denmin supportnicht erreicht,dann kann man daraus schließen, dassfMilch, Computerg oderfVollmilch, Com-puterg denmin supportebenfalls nicht erfüllen konnen. Aus diesem Grund ist es


Algorithmus 3.3.2 CUMULATE

ComputeT �, the set of ancestors of each item, fromT ; // Opt. 2L1 = ffrequent 1-itemsetsg;k = 2;while (Lk�1 6= ;) fCk = new candidates of sizek generated fromLk�1;if (k = 2) f

Delete any candidates inC2 that consists ofan item and its ancestor; // Opt. 3

gDelete all items inT � that are not present in any

of the candidates inCk; // Opt. 1forall (T 2 D) f

forall (x 2 T )Add all ancestors of x inT � to T ;

Remove any duplicates fromT ;Increment the count of all candidates inCk that are contained inT ;


gResult =

Sk Lk;

geschickt, zunächst die Supportberechnung in höheren Hierarchien durchzuführenund die Erkenntnisse über den Support in die tieferen Ebenen zu propagieren.

EineAd–hoc–Implementierung dieser stratifizierenden Vorgehensweise würde al-so zuerst im Taxonomiegraphen die Artikel der Tiefe0 (Artikel ohne Vorfahren)berechnen. Die Nachfahren derjenigen Artikel, die keinen minimalen Supportbesitzen, würde man dann entfernen, da sie denminsupportebenfalls nicht errei-chen konnen. Iterativ müsste der Algorithmus nun die Artikel der Tiefe1; 2; : : :in gleicher Weise betrachten. Um die Datenbankzugriffe zu minimieren, könnteman Artikel mehrerer Hierarchiestufen zusammenfassen und in einem Durchgangberechnen. Srikant und Agrawal beschreiben diese Implementierung in dem Al-gorithmus STRATIFY [SA95].

Schatzen des SupportEine weitere Idee zur Optimierung der Artikelmengenberechnung stellt das Schät-zen der Kandidaten dar. Mit Hilfe einer BeispielmengeDS � D wird geschatzt,ob die Kandidaten im aktuellen Durchgang den Support erreichen. Die als häufiggeschatzten Artikelmengen werden ebenso gezählt wie diejenigen MengenC 0

k, die


zwar nicht als häufig geschätzt wurden, aber deren Eltern häufig sind. Allerdingsschließt man die Nachfahren der Mengen ausC 0

k von der Supportberechnung aus.Sollten sich später einige Mengen ausC 0

k doch als häufig herausstellen, so werdendie Nachfahren dieser Mengen inC 00

k gesammelt und in einem extra Durchganguberpruft. Dadurch bleibt die Vollständigkeit erhalten.

BeispielEs sei die Taxonomie wie in Abbildung 3.2 gegeben und der minimaleSupport liege bei 6%. Die Tabelle in Abbildung 3.3 zeigt den Support einigerKandidaten.

wirklicher Support ausDKandidaten Support ausDS Szenario A Szenario B

fLebensmittel, Computerg 8% 7% 9 %fBrot, Computerg 5% 5% 8 %fWeißbrot, Computerg 1%

Abbildung 3.3: Beispiele Supportschätzung

Man kann erkennen, dass nur die ArtikelmengefLebensmittel, Computerg alshaufig geschätzt wird. Trotzdem muss zusätzlich nochfBrot, Computerg indie Kandidatenmenge aufgenommen werden, da zu diesem Zeitpunkt nicht si-cher ist, obfLebensmittel, Computerg haufig ist (Brot ist direkter Nachfahrevon Lebensmittel). In Szenario A erweist sich zwarfLebensmittel, Computergals haufig, aberfBrot, Computerg nicht. Daher mussfWeißbrot, Computergnicht in einem extra Durchlauf berechnet werden, wie es in Szenario B der Fallware. Hier erreichtfBrot, Computerg namlich den minimalen Support; folglichwird fWeißbrot, Computerg der MengeC 00

k zugefugt und im extra Durchgangberucksichtigt.

Anstelle die Kandidaten ausC 00k in einem separaten Durchgang zu zählen, ist es

sinnvoller, diese mit den KandidatenCk+1 im nachsten Iterationsschritt zu unter-suchen. Da man dann allerdings noch nicht weiß, welche Artikelmengen ausC 00

k

haufig sind (diese werden nämlich bei der Generierung vonCk+1 benotigt), nimmtman zur Erzeugung vonCk+1 einfach alle Mengen ausC 00

k als haufig an.

Die Zusammenführung der oben genannten Optimierungen wird im VerfahrenESTMERGE (Algorithmus 3.3.3) dargestellt. Die Modifikationen in CUMULA -TE konnen hier ebenfalls eingesetzt werden, auch wenn sie aufgrund derUber-sichtlichkeit weggelassen wurden.


Algorithmus 3.3.3 ESTMERGE

L1 = ffrequent 1-itemsetsg;GenerateDS , a sample of the database, in the first pass;k = 2;C 001 = ;;

while (Lk�1 6= ; or C 00k�1 6= ;) f

Ck = new candidates of sizek generated fromLk�1 [ C 00k�1;

Estimate the support of the candidates inCk by making a pass overDS ;C 0k = candidates inCk that are expected to have minsupport and

candidates all of whose parents are expected to have minsupport;Find the support of the candidates inC 0

k [ C 00k�1 by making a pass overD;

Delete all candidates inCk whose ancestors (inC 0k) do not have minsupport;

C 00k = remaining candidates iCk that are not inC 0

k;Lk = all candidates inC 0

k with min support;Add all candidates inC 00

k�1 with min support toLk�1

k = k + 1;gResult =

Sk Lk;

3.3.5 Filtern der interessanten Regeln

Die generierten Regeln können nach einem in [SA96] vorgestellten Interessemaßeingeteilt und somit gefiltert werden. Die Vorgehensweise soll mit Hilfe eineskleinen Beispiels eingeführt werden:

BeispielEs sei die RegelLebensmittel ) Computer (Support 8%, Konfidenz70%) gegeben. Nach dem Taxonomiegraphen in Abbildung 3.2 istLebensmittelVater vonBrot. Nimmt man an, dassBrot etwa1=4 des gesamten Lebensmittel-verkaufs ausmacht, so würde man erwarten, dass die RegelBrot ) Computer2% Support und 70% Konfidenz innehält. Wenn also die Werte des Supportsund der Konfidenz nahe bei diesen Werten liegen, so kann die RegelBrot )Computer als uninteressant betrachtet werden.

Im Weiteren wird eine formale Definition des Interessemaßes gegeben, mit dessenHilfe der Benutzer Regeln filtern kann. Ein einzustellender ParameterR steuertdabei die Stärke der zu filternden Regeln.

Erwarteter SupportSei die RegelX ) Y undZ = X [Y gegeben. Sei mitE

Z[Pr(Z)] der erwartete

Support vonZ definiert, wenn der SupportPr(Z) des VorfahrensZ bekannt ist.Weiter seiZ = fz1; : : : ; zng und


Z = fz1; : : : ; zj; zj+1; : : : ; zng, 1 � j � n, so dasszi ein Vorfahre vonzi ist.Dann definiert sich der erwartete Support vonZ bzgl. des bekannten Supportsvon Z wie folgt:

EZ [Pr(Z)] =Pr(z1)

Pr(z1)� : : :�

Pr(zj)

Pr(zj)� Pr(Z) (3.8)

Erwartete KonfidenzZum erwarteten Support kann analog die erwartete KonfidenzE

X)Y[Pr(Y jX)]

der RegelX ) Y definiert werden. SeiY = fy1; : : : ; yng undY = fy1; : : : ; yj; yj+1; : : : ; yng, 1 � j � n, so dassyi ein Vorfahre vonyi ist.Dann definiert sich die erwartete Konfidenz vonX ) Y bzgl. der bekanntenRegelX ) Y wie folgt:

EX)Y [Pr(Y jX)] =Pr(y1)

Pr(y1)� : : :�

Pr(yj)

Pr(yj)� Pr(Y jX) (3.9)

Man sollte beachten, dassEX)Y

[Pr(Y jX)] = Pr(Y jX) gilt.

Nun kann man eine RegelX ) Y als R-interessantbzgl. ihres VorfahrensX ) Y nennen, wenn entweder der Support vonX ) Y dasR-fache des erwar-teten Supports bzgl.X ) Y ist, oder die Konfidenz dasR-fache der erwartetenKonfidenz bzgl.X ) Y betragt.

Interessante RegelSei eine MengeS von Regeln und ein MinimalinteresseR gegeben. Eine RegelX ) Y ist interessant(in S), wenn sie keine Vorfahren inS besitzt oder sieR–interessant bzgl. ihrer direkten Vorfahren ist. Die RegelX ) Y ist teilweiseinteressant(in S), wenn sie keine Vorfahren inS besitzt oder sieR–interessantbzgl. mindestens eines direkten Vorfahrens ist.

3.4. Quantitative Assoziationsregeln 45

3.4 Quantitative Assoziationsregeln

Die bisher besprochenen Verfahren beschreiben das Finden von Assoziationsre-geln mit boolscher Aussagekraft. Es wird also geprüft, ob ein Artikel in einerTransaktion vorhanden ist oder nicht.

In der Realitat werden allerdings viel häufiger quantitative oder kategorische Aus-sagen über Artikel getroffen und sie sind daher sehr wichtig für die Bildung vonAssoziationsregeln. Im Kontext eines Kaufhauses wäre eine solche quantitativeAssoziationsregel: ,,Wer 3 mal ArtikelA kauft, erwirbt mit 90% Wahrschein-lichkeit 2 mal ArtikelB.” Im Rahmen einer medizinischen Diagnosedatenbankkonnte eine quantitative Assoziationsregel so aussehen: ,,Der Patient hat sehrstarken Husten und Laborwert A-20, dann ist er mit 96% Wahrscheinlichkeit einstarker Raucher.”

3.4.1 Problemstellung

Das Gebiet der quantitativen Assoziationsregeln ist noch relativ neu und dahergibt es nur wenige Literaturstellen, die sich mit dem Finden solcher Regeln be-schaftigen. Das von Srikant und Agrawal [SA96] vorgestellte Verfahren soll hierausfuhrlich diskutiert werden:

Da das Problem der boolschen Assoziationsregeln schon sehr gut untersucht wur-de, ist es zunächst interessant, inwieweit das Finden von quantitativen Assozia-tionsregeln auf das Finden von boolschen Assoziationsregeln abgebildet werdenkann: Der einfachste Weg wäre, fur jeden Artikeli die moglichen Ausprägungenzu untersuchen und für jede Ausprägung einen neuen Artikelik zu generie-ren. Ein Artikel i mit 10 verschiedenen Ausprägungen würde also die Mengei0 = fi1; : : : ; i10g erzeugen. Für Artikelgruppen mit sehr vielen (oder kontinu-ierlichen und damit unendlich vielen) Ausprägungen schlägt diese Methode aberoffensichtlich fehl. Hier bietet es sich an, Intervalle über eine Menge von zusam-menhangenden Werten zu bilden und mit diesen Intervallen die neuen Artikel zugenerieren.

Das catch–22 ProblemDie Wahl der Intervallgrenzen ist kein triviales Problem. Srikant et al. [SA96] be-schreiben den Trade–Off zwischen großen und kleinen Intervallen als dascatch–22Problem:

1. Zu geringer Support: Teilt man den Wertebereich der einzelnen Attribute


in zu viele Intervalle auf, so finden sich zu wenige Transaktionen, die dieseeinzelnen Intervallbereiche unterstützen. Viele Bereiche erreichen somitnicht mehr den minimalen Support.

2. Zu geringe Konfidenz: Als Reaktion auf den Supportverlust könnte mandie Intervallbereiche größer wahlen. Werden aber zu große Wertebereichein Intervallen vereint, so erreichen einige Regeln die minimale Konfidenznicht mehr. Diese Erkenntnis ergibt sich aus der Definition der Konfidenz.

Zusammenfassend lässt sich dascatch–22Problem also folgendermaßen beschrei-ben: Sind die Intervalle zu klein, so erreichen einige Regeln denmin supportnicht; werden die Intervalle zu groß, so ist die Konfidenz für einige Regeln zuklein.

Eine mogliche Losung des Problems wäre die Aufspaltung der einzelnen Wer-tebereiche in möglichst viele denkbare Intervalle, in der Weise, dass sich ei-nige Intervalle auch überlappen. Wenn man also beispielsweise die Interval-le [1..10], [11..20], [21..30] betrachten würde, konnte man auch die Intervalle[1..20], [11..30] oder [1..30] miteinbeziehen. In dieser Hinsicht ließen sich dieProbleme des zu geringen Supports und Konfidenz umgehen. Allerdings entste-hen durch die Bildung der vielen (redundanten) Intervalle zwei neue Probleme:

1. Ausfuhrungszeit: Hat ein Wertn verschiedene Wertausprägungen, so gibtes durchschnittlichO(n2) mogliche Intervallbereiche. Daraus folgt, dassdurch den rapiden Anstieg der Intervallanzahl auch die Ausführungszeitdrastisch steigt.

2. Zu viele Regeln: Erreicht ein Attributwert den minimalen Support, so er-reicht ihn auch jedes Intervall, in dem dieser Attributwert vertreten ist.Hieraus folgt, dass die Anzahl der erzeugten Regeln mit der Anzahl derverfugbaren Intervalle steigt.

Es ist noch zu bemerken, dass es in der Regel nicht sinnvoll ist, über kategori-schen Attributen Intervalle zu bilden. Sind jedoch Taxonomien über diesen kate-gorischen Attributen möglich, so konnten diese zur Intervallbildung dienen.

3.4.2 Grundlegende Definitionen

Zunachst ist es hilfreich, quantitative und kategorische Attribute in einem Termi-nus abzubilden. Die Werte der kategorischen Attribute werden in fortlaufenden


Zahlen abgebildet ebenso wie die Werte der quantitativen Attribute, die nicht inIntervalle aufgeteilt wurden. Quantitative Attribute, die in Intervalle unterteiltwurden, werden ihren Intervallen entsprechend ebenfalls in fortlaufenden Zah-len abgebildet, ohne dabei die Ordnung der Werte zu verlieren. Auf diese Wei-se lasst sich jeder Datensatz der Datenbank in ein Tupel(Attribut, Zahlenwert)uberfuhren.

Abbildung der AttributeSeiI = fi1; i2; : : : ; img die Menge der Attribute undP eine Menge von positivenZahlen. Man bezeichne mitIV die MengeI � P und ein Tupel(x; v) 2 IVbedeute das mit dem Wertv verbundene Attributx.

SeiIR die Mengef(x; l; u) 2 I � P �P j l � u, fur x quantitativ;l = u, furx kategorischg. Auf diese Weise stellt also das Tripel(x; l; u) 2 IR entwederein quantitatives Attribut mit dem Intervallbereich[l; u] oder ein kategorischesAttribut mit dem Wertl dar. Weiter gelte für alleX � IR:attributes(X) = fx j (x; l; u) 2 Xg

Quantitative AssoziationsregelEine ArtikelmengeR � IR supported ein X, wenn gilt: [8(x; l; u) 2X] [9(x; q) 2 R], so dassl � q � u gilt. Eine quantitative Assoziations-regel ist eine Implikation der FormX ) Y mit X � IR, Y � IR undattributes(X) \ attributes(Y ) = ;. Eine RegelX ) Y hat die Konfidenzc, wennc Prozent der Transaktionen inD die X supporten auchY supporten.Entsprechend hat die RegelX ) Y einen Support vons, wenns Prozent derTransaktionen inD die MengeX [ Y unterstutzen.

Generalisierung und SpezialisierungMan bezeichnetX als eineGeneralisierungvonX, wenn gilt:attributes(X) =attributes(X) und8x 2 attributes(X) : [(x; l; u) 2 X ^ (x; l0; u0) 2 X ) l0 �l � u � u0]. X ist dann eine Spezialisierung vonX . In diesem Kontext sprichtman bei Generalisierungen oft auch vonVorfahren. Beispielsweise wäref(Milch1..8), (Brot 1..2)g eine Generalisierung vonf(Milch 1..5), (Brot 1..2)g .

3.4.3 Vorgehensweise beim Finden von quantitativenAssoziationsregeln

Das Finden von quantitativen Assoziationsregeln lässt sich in 5 Teilschritte unter-gliedern, auf die im Weiteren näher eingegangen werden soll:

1. Partitionierung der quantitativen Attributwerte Fur jedes quantitative


Attribut werden die sinnvollen Intervalle bestimmt, in welche der Wertebe-reich unterteilt werden soll. Für kategorische Wertebereiche ist eine Parti-tionierung in der Regel nicht sinnvoll.

2. Harmonisierung der Attributwerte Bei kategorischen Attributen werdendie Wertausprägungen in fortlaufenden Ziffern abgebildet. In entsprechen-der Weise werden quantitative Attribute, die nicht partitioniert wurden, infortlaufenden Ziffern abgebildet. Die Ordnung zwischen den Wertausprä-gungen darf dabei nicht verloren gehen. Wurden quantitative Attribute inIntervalle partitioniert, so werden diese Intervalle ebenfalls in fortlaufendenZiffern abgebildet. Auch hier soll die Ordnung erhalten bleiben.Von nun an kennt das Verfahren nur Werte für quantitative Attribute. DieIntervalle oder Kategorien, die hinter diesen Ziffern stehen, bleiben für denAlgorithmus transparent.

3. Supportberechnung Es wird der Support für die quantitativen und ka-tegorischen Attribute berechnet. Zusätzlich werden für die quantitativenAttribute noch so lange benachbarte Werte miteinander verschmolzen undder resultierende Support bestimmt, bis ein benutzerdefinierter, maxima-ler (!) Supportuberschritten wird. Artikel, die den minimalen Supportuberschreiten, ergeben die Menge der häufigen Einzelartikel.

4. Verwendung eines boolschen Assoziationsregel–VerfahrenNach derVorarbeit ist es nun möglich, ein um leichte Modifikationen erweiter-tes boolsches Assoziationsregel–Verfahren zu benutzen. Der Apriori–Algorithmus wird dafur von [SA96] vorgeschlagen. Auf die nötigenErganzungen wird in Abschnitt 3.4.6 eingegangen.

5. Filtern der interessanten RegelnBeim Generierungsprozess entstehenviele uninteressante und redundante Regeln. In Abschnitt 3.4.5 wird einMaß vorgestellt, welches das Interesse und den Informationswert einer Re-gel bestimmt.

3.4.4 Partitionierung der quantitativen Attributwerte

Wie schon in der Einleitung ersichtlich wurde, stellt die Partitionierung der Wer-tebereiche ein wesentliches Problem des Verfahrens dar. Dieses besteht dar-in, dass jede Partitionierung einen gewissen Informationsverlust mit sich führt.Um diesen Informationsverlust bewerten zu können, wird zunächst ein Teil-vollstandigkeitsmaß über Artikelmengen eingeführt.


K–Vollst andigkeit(K–complete) SeiC die Menge aller häufigen Artikelmengen inD und sei weiterK � 1 reell. Dann heißtP K–vollstandig bzgl.C, wenn gilt:

1. P � C

2. X 2 P ^X 0 � X ) X 0 2 P

3. [8X 2 C][9C 2 P] :

(a) X ist eine Generalisierung vonX undsupport(X ) � K �support(X)und

(b) [8Y � X][9Y � X ]: Y ist eine Generalisierung vonY undsupport(Y ) � K � support(Y ).

Die beiden ersten Bedingungen 1. und 2. sichern , dassP nur haufige Artikelmen-gen enthält und somit zur Generierung von Regeln geeignet ist. Der erste Teil derdritten Bedingung sagt, dass es für jede ArtikelmengeX in C eine Generalisie-rung gibt, deren Support höchstens K mal größer ist. Im zweiten Teil der drittenBedingung sieht man, dass diese Eigenschaft auch für Teilmengen vonX zutrifft.Bei naherer Betrachtung wird klar, dassP furK = 1 mit C identisch ist.

BeispielZur Verdeutlichung seien die in Abbildung 3.4 häufigen Artikelmengengegeben. Die Artikelmengen 2, 3, 5 und 7 sind eine 1,5–vollständige MengeM,da fur jede ArtikelmengeX 2 M, entweder 2, 3, 5 oder 7 eine Generalisie-rung darstellt, deren Support mindestens das 1,5 fache des Supports vonX ist.Demgegenüber ist zwar Artikelmenge 2 eine Generalisierung von Artikelmenge1, aber der Support von Artikelmenge 2 ist nur das 1,2 fache des Supports vonArtikelmenge 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 Teilvollstandigkeit

Mit Hilfe eines Lemmas zeigen [SA96] folgende interessante Beobachtung:


Lemma 3 SeiP K–vollstandig bzgl. der Menge der häufigen ArtikelmengenCundRC die Menge der ausC generierten Regeln, welche die minimale Konfidenzerfullen. Weiter seiRP die Menge der ausP generierten Regeln, deren Konfidenzmin conf

Kerfullt. Fur jede RegelA) B ausRC gibt es dann eine RegelA) B,

so dass gilt:

� A undB sind Generalisierungen vonA undB.

� A) B hat hochstens den K–fachen Support vonA) B.

� Die Konfidenz vonA ) B ist mindestens das1K

–fache und höchstens dasK–fache der Konfidenz vonA) B.

Zwei weitere Lemmata zeigen Eigenschaften, die zur Partitionierung der Wertebe-reiche wichtig sind. Folgendes Lemma untersucht die Partitionen eines einzelnenAttributs:

Lemma 4 Seix ein quantitatives Attribut undK > 1 reell. Nun wirdx in Inter-valle (sogenannte Basisintervalle) partitioniert, so dass für jedes dieser Basisin-tervalleB gilt:

� support(B) < min support � K�12

oder

� “ B ist Einzelwert”

Wenn man nun mitP die Menge aller Kombinationen von Basisintervallen be-zeichnet, die den minsupport erreichen, dann istP K–vollstandig bzgl. der Men-ge aller moglichen Bereiche überx mit min support.

Das anschließende Lemma verallgemeinert diese Eigenschaft aufn Attribute:

Lemma 5 Sei eine Menge vonn quantitativen Attributen und ein reellesK > 1gegeben. Man nehme an, dass jedes einzelne Attribut derart in BasisintervalleBpartitioniert wird, dass entweder

� support(B) < min support � K�12�n oder

� “ B ist Einzelwert”

gilt. WennP die Menge aller häufigen Artikelmengen über diesen partitioniertenAttributen ist, dann istP K–vollstandig bzgl. der Menge aller häufigen Artikel-mengen (die ohne Partitionierung gewonnen wurden).


Aufgrund der Lemmatas kann man nun für eine beliebig gegebene Partition denGrad der Teilvollständigkeit bestimmen. Hier soll dies zunächst nur fur ein ein-zelnes Attribut gezeigt werden:

Nachdem man die Partition mit dem größten Support gefunden hat, dient die For-mel

s = min support �K � 1

2(3.10)

zum Finden des Grades der Teilvollständigkeit. Nach einfacher Umformung er-gibt sich

K = 1 +2 � s

min support(3.11)

Fur n Attribute dient die entsprechende Formel

K = 1 +2 � n � s

min support(3.12)

In [SA96] wird weiter gezeigt, dass gleichgroßes Partitionieren den Grad derTeilvollstandigkeit minimiert. Folglich minimiert für einen gegebenen Grad derTeilvollstandigkeit gleichgroßes Partitionieren die Anzahl der Intervalle, die zurErfullung dieses Grades benötigt werden.

Zusammenfassend betrachtet lässt sich also leicht bei einem gegebenen Teilvoll-standigkeitsgrad und einem gegebenenmin support die Anzahl der benötigtenPartitionen berechnen. Um einen GradK der Teilvollstandigkeit zu erreichen,darf der Support einer Partition (mit mehr als einem Wert)min support � k�1

2�n

nicht uberschreiten, wobein 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 Teil-vollstandigkeit nicht beeinflussen), so entstehen1

sPartitionen, die jeweils ihren

Support unters halten.

Hieraus ergibt sich folgende Formel:

Intervallzahl =2 � n

m � (K � 1)(3.13)

(n: Anzahl der quantitativen Attribute, m: minimaler Support, K: Grad der Teil-vollstandigkeit)


3.4.5 Filtern der interessanten Regeln

Bei der Generierung der quantitativen Assoziationsregeln werden sehr viele re-dundante und damit uninteressante Regeln erzeugt. Ein Ansatz, diese Korrelatio-nen zu filtern, soll hier vorgestellt werden. Zunächst betrachte man zwei Regelnder Art:

(Milch 1..10) ) (Brot 2..4) 8% Support, 70% Konfidenz(Milch 1..5) ) (Brot 2..4) 2% Support, 70% Konfidenz

Folgt man nun der Annahme, dass14

der Transaktionen, in denen (Milch 1..10)liegt, auch (Milch 1..5) enthalten ist, so kann die zweite Regel als redundant an-gesehen werden, da sie gleiche Konfidenz und die erwarteten 25% der Supportsder ersten Regel hält. Eine Regel erscheint also erst dann interessant, wenn sieeinen großeren Wert als erwartet hält. Dieses “greater–than–expected–value”–Kriterium wird nun formal definiert:

ErwartungswertSeiEPr(Z)[Pr(Z)] der erwartete Wert des Supports von Z (Pr(Z)), basierend

auf Pr(Z), wobei Z Generalisierung vonZ ist). Sei weiter die ArtikelmengeZ = f(z1; l1; u1); : : : ; (zn; ln; un)g undZ = f(z1; l01; u

01); : : : ; (zn; l

0n; u

0n)g. Dann

ist

EPr(Z)[Pr(Z)] =Pr((z1; l1; u1))

Pr((z1; l01; u01))

� : : :�Pr((zn; ln; un))

Pr((zn; l0n; u0n))

� Pr(Z) (3.14)

In gleicher Weise lässt sich der Erwartungswert für die Konfidenz der RegelX )Y definieren, wennY = f(y1; l1; u1); : : : ; (yn; ln; un)g undY = f(y1; l01; u

01); : : : ;

(yn; l0n; u0n)g:

EPr(Y jX)[Pr(Y jX)] =Pr((y1; l1; u1))

Pr((y1; l01; u01))

� : : :�Pr((yn; ln; un))

Pr((yn; l0n; u0n))

� Pr(Y jX)

(3.15)

Leider ist es nicht ausreichend, eine Artikelmenge als interessant bzgl. ihres Vor-gangers zu bezeichnen, sobald der Support größer oder gleich dem R–fachen deserwarteten Supports ist. Auf Grund dieser Bedingung werden immer noch vieleIntervalle falschlicherweise als interessant angesehen. Vielmehr ist es wichtig,


auch Spezialisierungen der Artikelmengen zu betrachten. So werden Spezialisie-rungen der Artikelmenge gesucht, die interessanter als die eigentliche Menge sind.Ist dies der Fall, so wird die Spezialisierung von der Menge abgetrennt und un-tersucht, ob die Differenz daraus noch interessant ist. Wird keine Spezialisierungmit dieser Eigenschaft gefunden, so behält man die Artikelmenge als interessant.

R–interessantEine ArtikelmengeX istR–interessant bzgl.X , wenn der Support vonX großeroder gleich demR–fachen des erwarteten Supports ist (basierend aufX) undwenn jede SpezialisierungX 0 mit der Eigenschaft “X 0 hat min support” undX �X 0 � IR, die DifferenzX �X 0 ist R–interessant bzgl.X.

3.4.6 Erganzungen zum Algorithmus

Die Vorgehensweise des Algorithmus zum Finden quantitativer Assoziationsre-geln wurde bereits besprochen. In den vorliegenden Abschnitten wurde beschrie-ben, wie die Attributwerte partitioniert werden sollten und wie interessante Arti-kelmengen herausgefiltert werden können. Damit ist die wichtigste Vorarbeit fürden Algorithmus schon geleistet. Der Fokus soll nun auf den Kern des Prozessesgerichtet werden: Dem Finden der häufigen Artikelmengen.

Zum Finden der häufigen Artikelmengen schlagen [SA95] einen leicht modifi-zierten Apriori–Algorithmus vor. Mit häufigen Einzelartikeln beginnend werdensukzessive häufige, mehrelementige Artikelmengen gebildet. Die Generierungder Kandidatenmenge und die Bestimmung des Supports benötigen jedoch eineAnpassung an die Aufgabenstellung.

KandidatengenerierungAusgehend von einer (k-1)–elementigen häufigen ArtikelmengeLk�1 generiertdiese Prozedur einek-elementige KandidatenmengeLk.

Wahrend die beiden ersten Schritte dem Grundalgorithmus entsprechen, stellt derdritte Schritt die eigentliche Erweiterung dar:

1. Join–PhaseEin Join wird aufLk�1 mit sich selbst ausgeführt, so dass diek � 2 ersten Elemente geordnet sind und sich die beiden letzten Attributeunterscheiden.

2. Prune–PhaseAlle resultierenden Artikelmengen werden untersucht. Liegteine(k � 1)-elementige Teilmenge vor, die nicht inLk�1 liegt, so wird dieentsprechendek–elementige Artikelmenge entfernt.


3. Prunen nach InteresseGibt der Benutzer ein Interessemaß an, so wirddieses Maß zum Prunen der Artikelmengen benutzt.

Supportbestimmung der KandidatenFur die Bestimmung des Supports aller Kandidaten wird ein kompletter Daten-bankdurchlauf benötigt. Die Datenbasis wird tupelweise ausgelesen und jedesTupel (Transaktion) wird mit der Kandidatenmenge verglichen.

Zum effizienteren Vergleich können die Kandidaten in Gruppen organisiert wer-den, so dass gleiche kategorische Attributwerte und gleiche quantitative Attributein einer Gruppe versammelt sind. Jede Kandidaten–Gruppe wird durch einen so-genanntenSuper–Kandidatenersetzt. Dieser Super–Kandidat besteht aus zweiTeilen: Den gemeinsamen kategorischen Attributwerten und einer Datenstruktur,welche die unterschiedlichen quantitativen Attributwerte abbildet.

BeispielSeien beispielsweise folgende drei Kandidaten generiert worden:

f(Kreditkarte Ja), (Milch 1..5), (Brot 1..2)g,f(Kreditkarte Ja), (Milch 1..8), (Brot 2..4)g,f(Kreditkarte Ja), (Milch 3..4), (Brot 4..6)g

Alle drei Kandidaten besitzen die gleichen Attribute und haben für das einzige,kategorische AttributKreditkarteden gleichen Wert “Ja”. Daher lassen sie sichzu einem Super–Kandidaten zusammenfassen.

Kreditkarte Ja

Milch Brot1..5 1..21..8 2..43..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 kate-gorischen Werte eines Super–Kandidaten enthält, mussen in diesem Super–Kandidaten diejenigen Kandidaten gefunden werden, welche die Transakti-on unterstützen.

3.5. Betrachtung der Komplexität 55

3.5 Betrachtung der Komplexit at

Die einzelnen Autoren führen in ihren Aufsätzen ausführliche Tests mit syn-thetischen und realen Datensätzen durch. So beschreiben sie bei verschiede-nen Datencharakteristika die unterschiedlichen Verhaltensweisen der vorgestell-ten Algorithmen. Dennoch vermisst man theoretischeUberlegungen bezüglichder Komplexitat der einzelnen Algorithmen. Han et al. stellen jedoch in [HP96]Uberlegungen zur Komplexitätsberechnung von Assoziationsregelverfahren an.

Das APRIORI–Verfahren bildet für die meisten Algorithmen die Grundlage in derGenerierung der häufigen Artikelmengen. So bauen beispielsweise auch Mo-difikationen, wie Verfahren zum Finden von generalisierten Assoziationsregeln(CUMULATE) auf dem APRIORI–Algorithmus auf. Aus diesem Grund wird hiereine fundierte Untersuchung dieses Verfahrens gegeben. Leichte Modifikationenverandern die Grundkomplexität nicht entscheidend.

Zunachst ist es wichtig, Obergrenzen für die zu untersuchenden Artikelmengenzu finden. Die Anzahl allerk–Artikelmengen über der Menge aller ArtikelI mitjIj = N ist

jAkj =

N

k

!(3.16)

Folglich gilt jAkj 2 O(Nk). EineUberprufung aller ArtikelmengenAk im k–tenSchritt ist also zu aufwendig. Aus diesem Grund wählen die APRIORI–Verfahrenin sogenanntenKandidatenmengenCk Artikelmengen aus, die überhaupt für dieBildung der haufigen ArtikelmengenLk in Frage kommen.

Von Interesse ist zunächst die Komplexität dieser ArtikelmengenLk. Die einfach-ste Moglichkeit ware, eine WahrscheinlichkeitsverteilungPt(n) uber den Datenanzunehmen (n sei die Transaktionsgröße). Sind keine weiteren Informationenverfugbar, so müssen allek–Artikelmengen gleichwahrscheinlich angenommenwerden, also giltCk = Ak. Sinnvoller ist es Korrelationen über der DatenbasisDanzunehmen und diese näher zu betrachten.

Um diese Korrelationen näher beschreiben zu können, wird der BegriffClustereingefuhrt. Ein Cluster ist eine größtmogliche, haufige Artikelmenge, so dassjede Teilmenge zwar häufig, aber jede Erweiterung des Clusters nicht mehr häufigware.Ublicherweise kann davon ausgegangen werden, dass die zu untersuchendeDatenbank über eine Anzahl von Clustern verfügt. Sei daher mitC die Menge derClusteruberD gegeben und es giltC = f 1; 2; 3; : : :g.

Komplexit at vonLk Die Große vonLk ist einfach zu errechnen, wenn alle Cluster


disjunkt sind. Dann ist jede Teilmenge des jeweiligen Clusters i eine haufigeArtikelmenge und es gibt pro Cluster

�j ijk

�haufige Artikelmengen. Folglich gilt

insgesamt, dassjLkj =Pi

�j ijk

�ist.

Gewohnlicherweise überlappen sich die einzelnen Cluster jedoch und es gilt dann:

jLkj =Xi

j ij

k

!�Xi;j

j i \ jj

k

!+Xi;j;l

j i \ j \ lj

k

!� : : : (3.17)

Die erste SummePi

�j ijk

�kann hier als obere Grenze und der Term

Pi

�j ijk

��P

i;j

�j i\ jj

k

�als untere Grenze gesehen werden.

Mit dem Wissen um die Größen vonLk lassen sich nun die Kosten des APRIORI–Verfahrens in Algorithmus 3.2.3 (Seite 28) schätzen.

In der ersten Zeile werden die häufigen Einzelartikel ermittelt. Die Kosten für dieFestplattenzugriffe lassen sich auf einen gesamten Durchlauf durch die Datenbankfestsetzen. Mit einer passenden Hashfunktion wird das Generieren und Zählender 1-Artikelmengen in konstanter Zeit erledigt. Seiencd die Kosten fur einenFestplattenzugriff (Lesen/Schreiben). Dann sind die Kosten für die Generierungder haufigen 1-ArtikelmengenO(jjDjj) und die Zugriffskosten belaufen sich aufO(cd � jjDjj).

Die nun startende Hauptschleife wird von zwei Prozeduren bestimmt: Die Gene-rierung der Kandidaten und das anschließende Zählen derselben. Die Kandida-tengenerierung ist in Prozedur 3.2.2 (Seite 29) abgebildet. Der beginnende Join-Schritt benotigt im schlimmsten FallO(jLk�1j2) Operationen. Das anschließendePrunen verarbeitetO(k � jCkj � jLk�1j) Operationen. Insgesamt verbraucht dieKandidatengenerierung also Kosten in Höhe von

O(jLk�1j2 + k � jCkj � jLk�1j) (3.18)

Im Anschluss daran wird die Datenbank komplett durchlaufen und die Präsenzder generierten Kandidaten in der Transaktionen gezählt. Die Kosten für diesenDatenbankdurchlauf betragen

O(fs � jDj+ jCtj � jDj) (3.19)

Hier seienfs die Kosten fur die Bildung der TeilmengenCt von Ck, die in deraktuellen Transaktion enthalten sind (siehe APRIORI–Verfahren auf Seite 28).

3.5. Betrachtung der Komplexität 57

Die Kostenfs sind sehr individuell vonCk und der jeweils aktuellen Trans-aktion t abhangig. Eine ad–hoc–Implementation der Teilmengenbildung würdeO(m � jCkj � t) kosten, wobeim die Anzahl derCk fur ein bestimmtesk ist.

Zusammenfassend belaufen sich die Gesamtkosten der Hauptschleife auf

O

Xk

�jLkj

2 + k � jCkj � jLk�1j+ fs � jDj+ jCtj � jDj�!

(3.20)

Da jede Iteration der Schleife einen Datenbankdurchgang erfordert, belaufen sichdie Gesamtkosten der Plattenzugriffe auf

O(K � cd � jjDjj) (3.21)

wobeiK die Anzahl der nötigen Iterationen ist. Es gilt fürK

K � maxfjtj j t 2 Dg (3.22)

DaD in der Regel sehr groß ist, sindfs � jDj und jCtj � jDj die bestimmendenTerme in Gleichung 3.20.

4

Implementierung des WerkzeugsMISTRAL

Zu Beginn dieses Kapitels werden die wichtigsten Eigenschaften eines Da-ta Mining Werkzeugs erörtert. Danach folgt eine detaillierte Besprechung derSchlusselkomponenten, die diese Eigenschaften in MISTRAL implementieren.Dabei werden die verwendeten Entwurfsmuster genannt und zentrale Stellen inUML skizziert.

4.1 Uberlegungen zur Implementierung einesData Mining Werkzeugs

Im Rahmen dieser Arbeit wurde das Data Mining Werkzeug MISTRAL (MIningSystem Targeting Rules, Associations and Links) implementiert. Dieses Tool-kit besteht im Wesentlichen aus einem Kern und daran gekoppelten Komponen-ten. Diese Komponenten implementieren Algorithmen (Algorithm), Datenverbin-dungen (DataFetcher) oder auch spezielle Darstellungen der Ergebnisse (View-er). Um eine gewisse Grundfunktionalität zu erreichen, wurden Komponentenprogrammiert, die es nun, von beliebigen Datenbanken ausgehend, ermöglichenhaufige Artikelmengen, Artikelverteilungen und (generalisierte) Assoziationsre-geln zu berechnen. Darüber hinaus ist es leicht möglich, weitere Algorithmen,DataFetcher und Viewer an den Kern zu koppeln.

Der Kern bewerkstelligt den Data Mining Lauf in einer 3er Kette: Holen der Da-ten, Verarbeiten durch einen Algorithmus und Darstellen der Ergebnisse.

59

60 4. Implementierung des WerkzeugsMISTRAL

Die wichtigsten Eigenschaften eines Kerns sind dabei:

1. Modularit atDurch die modulare Architektur des Kerns und der Komponenten ist es pro-blemlos moglich, das Werkzeug durch neue Komponenten zu erweitern.Die objektorientierte Architektur im Verbund mit dem Einsatz von Ent-wurfsmustern wird im folgenden Absatz näher beschrieben.

2. Effiziente DatenbearbeitungDa Data Mining Verfahren in der Regel mit (sehr) großen Datenmengen ar-beiten, ist es für das Programm von entscheidender Bedeutung, Datenope-rationen, wie das Auslesen oder Bearbeiten von Datensätzen, in effizienterWeise durchzuführen.

4.2 Architektur von M ISTRAL

Die wichtigsten Stellen im Programm, welche die Modularisierbarkeit von MI-STRAL garantieren (Kern, Speicherbereich, Komponentenentwurf) und solche, dieden Speicherbedarf eingrenzen (Speicherung der Artikel) sollen nun genannt wer-den.

4.2.1 Der Kern

Das Klassendiagramm in Abbildung 4.1 zeigt nur die wichtigsten Strukturen desKerndesigns. Im Zentrum des Entwurfs steht die KlasseMKernel , welche dieadministrativen und operativen Aufgaben des Kerns übernimmt.

Zu den administrativen Aufgaben gehören:

1. Verwaltung der verfügbaren KomponentenViewer, Algorithmen und DataFetcher können hinzugefügt oder gelöschtwerden. Ebenso ist es möglich, fur jede Komponente einen beschreibendenText anzeigen zu lassen.

2. Erstellen eines Data Mining ProjektsDefinition der zu verwendenden Komponenten. Hier können eine Liste voneinem (oder mehreren) Viewern, ein Algorithmus und ein DataFetcher aus-gewahlt werden.

4.2. Architektur vonMISTRAL 61

3. Festlegen der BenutzerschnittstelleAn den Kern sollte eine Benutzerschnittstelle zur einfachen Bedienung ge-koppelt werden. Es stehen eine kommandozeilenorientierte und eine fen-sterorientierte Shell zur Verf¨ugung.

4. Speichern und Laden der Programmkonfiguration und Projektdefinition.

MKernel

AlgorithmListDataFetcherListViewerListconfiguration

runfinesetUsedAlgorithmsetUsedViewersetUsedDataFetchersave/loadProjectcloseKerneladd/removeAlgorithmadd/removeDataFetcheradd/removeVIewerset/getShell

Memory

MistralShell

JMistral MistralBatch

MComponent

setKernelrunfinetoStringgetAboutgetComponentIDequals

VIewer

Algorithm

DataFetcher 1 1

1 1

* 1

1

1

1 2

Abbildung 4.1: Mistral–Kern (UML)

Die operativen Aufgaben des Kerns umfassen:

1. Vorbereitung des Data Mining ProjektsHier ist das Anlegen von Speicherbereichen und der Test auf Korrektheitder eingestellten Parameter f¨ur jede Komponente wichtig.


2. Durchfuhrung des ProjektsJede Komponente wird in einem eigenen Thread gestartet. Danach kann derStatus des Projekts jederzeit erfragt werden.

3. NachbereitungNach dem Lauf wird das Logfile geschrieben und der verwendete Speicher-bereich bereinigt.

Im Ausschnitt des Klassendiagramms sind im Wesentlichen nur die operativenAufgaben wiederzufinden, da diese von größerem Interesse sind. Zur Bereitstel-lung von Speicherbereichen dient die KlasseMemory, bei deren Entwurf die Mu-ster Strategie und Observer [Gam96] Verwendung fanden. Eine nähereBetrachtung vonMemory folgt in Abschnitt 4.2.2.

DasStrategie Muster wurde ebenfalls bei der Benutzerkopplung eingesetzt.Theoretisch kann so jede Klasse, die das InterfaceMistralShell implemen-tiert, als Benutzerschnittstelle des Kerns dienen. Die optionale Verwendung ei-nes kommandozeilenorientierten (MistralBatch ) oder eines fensterorientier-ten (JMistral ) Programms mit dem gleichen Kern belegt dies.

Weiterhin sind die drei HauptkomponentenViewer , DataFetcher undAl-gorithm in Form von gleichnamigen Klassen an den Kern gekoppelt. Der Ent-wurf dieser Klassen wird in Abschnitt 4.2.4 näher untersucht.

4.2.2 Speicherbereiche

Das UML Klassendiagramm in Abbildung 4.2 zeigt nur die grundsätzliche Funk-tionalitat. Der Kernel verwaltet standardmäßig zwei Speicherbereiche: Der erstedient zur Speicherung der Ausgangsdaten (dataSet), während der zweite die be-rechneten Ergebnisse sammelt (resultSet).

DemStrategie Muster [Gam96] folgend wurde die GrundklasseMemory im-plementiert, um konkrete Implementierungen austauschbar zu machen. Als kon-krete Strategie wurde eine vollständig auf dem Arbeitsspeicher basierende Lösung(RAMMemory) und eine dateibasierte Speicherstruktur (FileMemory ) imple-mentiert.

Eng verknupft mit derMemory Klasse sind die KlassenDataFetcher , Al-gorithm undViewer . Diese Klassen dienen als Schnittstellen zu den konkre-ten Implementierungen von Datenanbindungen, Algorithmen und Darstellungs-komponenten für die Ergebnisse. Diese Komponenten sollten jederzeit über die


Viewer

MComponent

setKernelrunfinetoStringgetAboutgetComponentIDequals

Algorithm

Memory

resetclosegetNextElementgetElementAtgetChangegetSize

FileMemoryRAMMemory

Observer

update

Subject

observers

notifyObserverssubscribeunsubscribe

1 1

2 1

1 *

Abbildung 4.2: Speicherbereich (UML)

Veranderung in einem Speicherbereich informiert sein. So können die meisten Al-gorithmen erst dann starten, wenn alle Daten imdataSet versammelt sind. ImGegensatz dazu kann eine Darstellungskomponente (Viewer) immer die aktuellberechneten Ergebnisse darstellen.

Um diese Funktionalität zu erreichen, wurde das Observer(Publisher-Subscriber ) Muster [Gam96] umgesetzt. Memory er-weitert hierbei die KlasseSubjekt , welche Beobachter verwalten undbenachrichtigen kann. Die KlassenAlgorithm und Viewer wiederumimplementieren das InterfaceObserver , welches vom Subjekt benachrichtigtwird. DataFetcher wurde nicht um das InterfaceObserver erweitert, dadiese Komponenten üblicherweise in einem sequentiellen Lauf die Daten holenund im Speicherbereich ablegen. Eine Benachrichtigung macht hier wenig Sinn.


4.2.3 Speicherung der Artikel

Bei der Durchfuhrung eines Data Mining Projekts muss häufig mit mehreren hun-derttausend Artikeln umgegangen werden. Daher ist die effiziente und trotzdemSpeicher minimierende Implementierung einer Artikelklasse von großem Interes-se.

ConcreteFlyweight

valueiid

setNamegetNamesetIDgetIDequalstoString

Item

id

toStringequals

ItemFactory

ConcreteFlyweightList

addremoveAllIemselementAtgetSize

* 1

Abbildung 4.3: Verwaltung der Artikel (UML)

Die KlasseItem lehnt sich an das in [Gam96] vorgestellteFlyweight Musteran. So kann dieser Terminologie folgend die KlasseItem alsKlient, die KlasseItemFactory alsFliegengewichtFabrikundConcreteFlyweight als Im-plementierung vonkonkretesFliegengewichtverstanden werden.

Zur naheren Erläuterung der Funktionsweise hier ein kleines Beispiel: Es wirdwahrend des Programmlaufes eine neue Instanz vonItem mit einem entspre-chenden Artikelnamen gebildet. Daraufhin fragt der Konstruktor vonItem beiItemFactory nach einer Referenz, die dem Artikelnamen entspricht. Wur-de der Artikelname noch nicht verwendet, so erzeugtItemFactory ein neueskonkretes Fliegengewicht, speichert es intern ab und liefert eine Referenz daraufzuruck. Ist diese Artikelausprägung schon vorhanden, so wird die entsprechendeReferenz zurückgeliefert. Die KlasseItem muss also nur eine Referenz spei-chern, wahrend die KlasseItemFactory die komplette Information der jewei-ligen Artikelreferenzen in konkreten Fliegengewichten speichert.

Auf diese Weise muss die komplette Information jeder Artikelausprägung nur ein-mal gespeichert werden. Die Klienten verwalten nur Referenzen. Der damit ver-bundene Speicher- und Laufzeitgewinn ist leicht nachvollziehbar.


4.2.4 Die Mistral-Komponenten

Wie schon vorher beschrieben verwirklicht der Kern nur administrative und opera-tive Projektaufgaben. Die eigentliche Arbeit wird von den Mistral Komponentenubernommen. 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 (TEXTDATA FETCHER) oder einerJDBC/ODBC Datenbank (DBCDATA FETCHER). Von dort holen sie dieangeforderten Daten in den Kern.

2. Data Mining Algorithmen (Algorithm)Diese Komponenten sind für die Musterfindung aus den bereitgestellten Da-ten zustandig. Dazu kann das Finden von (generalisierten) Assoziationsre-geln (KomponenteCumulate ) oder von haufigen Artikelmengen (Kompo-nenteFrequentSets ) zahlen. Ebenso kann die Verteilung der Einzelar-tikel berechnet werden (ITEMDISTRIBUTION). Der Algorithmus APRIOR-INTERVALL findet Assoziationsregeln in einem speziellen Supportintervall.

3. Darstellungskomponenten (Viewer)Viewer dienen zum Darstellen oder Sichern der Ergebnisse des Da-ta Mining Prozesses. So schreibt beispielsweise die KomponenteTextfileViewer die Ergebnisse in eine Textdatei. TABTEXTVIEWER

und MISTRALFILEVIEWER sind Spezialisierungen von TEXTFILEVIEWER

und schreiben die Ergebnisse in bestimmte Dateiformate. WINDOWVIEW-ER zeigt die Ergebnisse in einem Programmfenster an.

Damit die Anbindung der Komponenten an den Kern problemlos vollzogen wer-den kann, sind einige Voraussetzungen zu beachten.

Zunachst einmal muss jede Komponente das InterfaceMComponent implemen-tieren, welches die nötigsten Methoden vordefiniert. Die wichtigsten Methodendieses Interface sindfine() und run() . Wahrend die Methodefine() dieKorrektheit der eingegebenen Komponentenparameter prüft, aktiviert die Metho-derun() den Lebenszyklus der Komponente. Dabei startet der Kern jede Kom-ponente als einen eigenen Thread.

Weiterhin muss jede Komponente eine der drei VaterklassenDataFetcher ,Algorithm oderViewer erweitern. Durch die Erweiterung der eigenen Klassedurch eine dieser drei Klassen wird der Typ der Komponente festgelegt. Darüber


hinaus kann eine neue Komponente auch von einer Klasse abgeleitet sein, diefruher vonDataFetcher , Algorithm oderViewer geerbt hat. Abbildung4.4 (Seite 66) zeigt die Architektur der MISTRAL Komponenten in UML–Notati-on. TABTEXTVIEWER beispielsweise unterscheidet sich nur im Ausgabeformatder Resultate und kann so problemlos von TEXTFILEVIEWER erben. Trotzdemwird TABTEXTVIEWER ohne Weiteres von MISTRAL als Komponente akzeptiert.

ApriorInterval

setMaxSupportgetMaxSupport

Cumulate

setConfidencegetConfidencesetInterestMeasuregetInterestMeasureTabTextViewerMistralFileViewer

TextFileViewer

url

setURLgetURL

FrequentSets

setSupportgetSupportsetTaxonomyURLgetTaxonomyURLgenerateCandidates

ItemDistributionDummyAlgorithm

Algorithm

sourcedestinationstate

setSourcesetDestination

WindowViewer

reload

TextDataFetcher

getNextTransactionhasMoreTransactions

Viewer

model

setModel

DataFetcher

urlmoldel

setURLgetURLsetModel

DBCDateFetcher

uidpasswdsqlCommanddbDriver

setUIDgetUIDsetPassWDgetPassWdsetSQLCommandgetSQLCommandsetDBDrivergetDBDriver

Observer

update

MComponent

finerunsetKernelgetComponentIDgetAbouttoStringequals

Abbildung 4.4: Mistral–Komponenten (UML)

Als wichtiger Punkt sollen noch die Eigenschaften von Komponenten betrach-tet werden: Aus der geforderten Variabilit¨at konnen Komponenten eine unter-schiedliche Art und Anzahl von Eigenschaften besitzen. Der Terminologie derJavaBeans Technologie folgend werden Parameter von Komponenten, die ver-andert werden k¨onnen, als Eigenschaften (Properties) bezeichnet. Entsprechend


derJavaBeans Konvention [Fla97] wird auch in Mistral auf diese Eigenschaf-ten mit get - und set -Methoden zugegriffen. Dabei akzeptiert Mistral nur Ei-genschaften mit Vollzugriff, also nur solche mitget - und set -Methoden. AlsUbergabeparameter dient standardmäßig einString –Objekt, welches innerhalbder Methode konvertiert werden muss.

Wie in Abbildung 4.4 schön zu sehen ist, besitzt beispielsweise die CUMULA -TE Komponente die EigenschaftenConfidence(die Konfidenz) undInterestMea-sure (das Interessemaß). Die EigenschaftenSupport(der Support) undTaxono-myURL (die URL der Taxonmiendatei) erbt die Komponente von FREQUENT-SETS. Keine Eigenschaften besitzen die Komponenten DUMMYALGORITHM undITEMDISTRIBUTION. Der Algorithmus ITEMDISTRIBUTON berechnet die Ver-teilung der Einzelartikel, während DUMMYALGORITHM die gelesenen Daten un-verandert durch den Kern reicht. Beide Komponenten benötigen also keine vonaußen zugänglichen Eigenschaften.

Abbildung 4.5: Beispiel: JavaDoc zu APRIORINTERVAL

Die gesamte Implementierung in Java wurde unter Berücksichtigung des JAVA -DOC–Syntax kommentiert. JAVA DOC gehort zum Standardumfang des JDKs


(Java Developer Kit) von Sun und generiert aus den Programmkommentaren auto-matisch verzeigerte HTML–Seiten. Die so erstellte Dokumentation kann auf derbeigelegten CD mit einem beliebigen HTML–Browser betrachtet werden. Abbil-dung 4.5 zeigt einen Ausschnitt aus der Dokumentation zur Algorithm Kompo-nente APRIORINTERVAL.

4.3 Aspekte der Implementierung

Das Werkzeug MISTRAL wurde komplett in Java (Version 1.1.x mit JFC) imple-mentiert. Diese Entscheidung brachte einige Vorteile, aber auch Nachteile mitsich, welche hier kurz erörtert werden sollen.

Vorteile Einer der geforderten Aspekte von MISTRAL sollte die Modularitat undErweiterbarkeit sein. Beliebige neue Komponenten sollen problemlos an den Kerngehangt werden können, ohne eine Neukompilation oder Modifikation der übrigenProgrammkomponenten zu erfordern. Durch die interpretierte Ausführung des Ja-va Bytecodes in einer virtuellen Maschine (JVM) und der JAVA BEANS Technolo-gie wurde es sogar möglich, wahrend des Programmlaufs neue Komponenten ein-zuhangen oder zu bearbeiten. Aufgrund des strengen objektorientierten Aufbausund Sprachgebrauchs von Java war es sehr einfach, die verwendeten Entwurfsmu-ster (siehe 4.2) zu implementieren.

Der plattformubergreifende Bytecode von Java ermöglichte das Laufen von MI-STRAL unter verschiedenen Betriebssystemen. So wurden beispielsweise ersteTestlaufe mit Daten unter Solaris 2.5.2 (Sun JDK 1.1.6) durchgeführt. Die mei-sten Laufe wurden jedoch unter MS–Windows NT 4 (SR3) absolviert, da sichhier die JVM (Symantec JIT 300.009) am schnellsten erwies. Das Programm liefebenfalls unter Linux (Kernel 2.0.32 JDK 1.1.4) und MacOS 8.1 (Apple MRJ 2.2).

NachteileDie Performanz eines Java Programms ist stark von der verwendetenJVM abhangig. So zeigte sich, dass die virtuellen Maschinen für die jeweiligenBetriebssysteme äußerst unterschiedlich implementiert waren. Beste Ergebnis-se konnten mit einem JIT (Just–In–Time Compilern) unter MS–Windows erreichtwerden. Ein JIT kompiliert Programmteile während des Laufs (just–in–time) vomBytecode in den jeweiligen plattformabhängigen Bitcode und führt diesen dannaus. Dies bringt — verglichen mit einer der interpretierten Ausführung — erheb-liche Geschwindigkeitsvorteile. So war der JIT (Version i300.009) von Syman-tec unter MS–Windows NT um den Faktor 5 schneller als der Orginalinterpretervon Sun. Trotzdem muss davon ausgegangen werden, dass Implementierungen inC++ um den Faktor 3-4 schneller sind.

5

Bedienungshinweise zu M ISTRAL

Im folgenden Kapitel wird das Programm MISTRAL beschrieben. Zunächst wirdder Aufbau eines Data Mining Laufes erläutert. Im Weiteren wird gezeigt, wiesich mit MISTRAL Data Mining Projekte definieren und durchführen lassen. DieAnkopplung und Bearbeitung neuer Komponenten wird ebenso beschrieben. Wei-ter werden die Anwendungszwecke der MISTRAL Werkzeuge (TaxonomiesundCheckSupport) und gezeigt. Den Abschluss bildet die Definition der benutztenDateiformate.

5.1 Aufbau eines Data Mining Laufes

Die Durchfuhrung eines Data Mining Laufes teilt sich in folgende Schritte auf:

1. Transformation der Datenbasis

2. Voranalyse der Daten

3. Definition eines Projekts

4. Projektdurchführung

5. Sichten und Interpretieren der Ergebnisse

Im momentanen Entwicklungsstadium unterstützt MISTRAL nur den 3. und4. Punkt dieser Aufzählung. Die restlichen Punkte müssen also von externen

69

70 5. Bedienungshinweise zuMISTRAL

Programmen erledigt werden. Durch die Implementierung weiterer MISTRAL –Komponenten sind diese Aufgaben aber auch in MISTRAL integrierbar.

Transformation der DatenbasisNach dem Verständnis der Domäne wird zunächst einmal eine Auswahl aus derDatenbasis getroffen. Diese Selektion kann Teilmenge der vorhandenen Trans-aktionen bedeuten oder aber auch nur bestimmte Attribute der Transaktionen be-trachten. Nicht immer liegen die Daten in einem MISTRAL kompatiblen Formatvor. Es ist also eine Transformation in ein Format nötig, das eine gekoppelteDataFetcher-Komponente lesen kann.

Abbildung 5.1: Das Programm MISTRAL

Voranalyse der DatenBevor man mit dem eigentlichen Data Mining beginnt, ist es häufig sinnvoll, ineiner Voranalyse die Daten zu untersuchen. Dabei betreibt man das angestrebteProjekt auf einer kleinen Testmenge der Datenbasis, die zufällig bestimmt werdensollte. Gefundene Grenzwerte — also zum Beispiel besonders starke oder be-sonders schwache Regeln — sollten überpruft werden. ZurUberprufung haufigerArtikelmengen bietet sich zum Beispiel das in MISTRAL integrierte WerkzeugMISTRALCHECK an. Anhand dieser Ergebnisse kann abgeschätzt werden, wiedas tatsächliche Projekt resultieren wird.

Definition eines ProjektsUm ein Data Mining Projekt zu definieren, müssen bestimmte Komponenten aus-gewahlt werden: Eine DataFetcher Komponente, welche die Daten bereitstellt,

5.2. Menustruktur vonMISTRAL 71

ein Algorithmus, der die Daten verarbeitet, und eine Anzahl von Viewer Kom-ponenten zur Darstellung und Speicherung der Ergebnisse. Die Definition einesProjekts wird in Abschnitt 5.3 näher besprochen.

Projektdurchf uhrungNachdem die Komponenten für das Projekt bestimmt worden sind, kann das Pro-jekt gestartet werden. Zuvor bietet es sich jedoch an, die Definitionen in einerProjektdatei zu speichern. Hierfür dient die MenüoptionFile/Save... .Sobald das Projekt gestartet ist, kann man unterProject/Summary den aktu-ellen Status des Projektlaufs abfragen. Hier sind auch die eingestellten Parameterder einzelnen Projektkomponenten einsehbar. Der Data Mining Lauf ist beendet,sobald in der Statusleiste die MeldungProject finished. angezeigt wird.

Sichten und Interpretieren der ErgebnisseNachdem das Projekt abgeschlossen ist, müssen die Ergebnisse gesichtet und in-terpretiert werden. Es bietet sich an, als Viewer auch denTextfile Viewer(Tabulator Style) zu verwenden. Hier werden die erzeugten Regeln spal-tenweise in eine Textdatei geschrieben. Dadurch ist ein späterer Import in eineTabellenkalkulation wie zum Beispiel MS-Excel problemlos möglich.Die aufbereitete Präsentierung der Regeln vereinfacht die Interpretation durch denAnwender.

5.2 Menustruktur von M ISTRAL

Die einzelnen Menüs von MISTRAL gliedern sich logisch in folgende Unterpunk-te:

� File Hier kann ein neues Projekt erstellt (New), ein bereits erstelltes Projektgeladen (Open) oder gespeichert werden (Save ). Der MenupunktExitspeichert alle getroffenen Einstellungen und beendet das Programm.

� Project Dieses Menü dient zur Erstellung eines neuen Projektes. Ein be-reits definiertes Projekt kann hier ebenso verändert werden. DerProjectWizard fuhrt durch die komplette Definition eines Data Mining Projektsund ist Anfangern zu empfehlen. Manuell können die zu verwendendenKomponenten in den MenüpunktenDataFetcher , Algorithm undViewer erreicht werden. Der MenüpunktSummarygibt eine Zusammen-fassung über die getätigten Projekteinstellungen undRun schließlich startetdas aktuelle Projekt.


� ComponentsHier konnen die MISTRAL Komponenten an– oder abgekop-pelt werden. Jede Art von MISTRAL Komponente ist hier mit einem eigenenMenupunkt vertreten.

� Tools DasTools Menu beinhaltet verschiedene Werkzeuge, die währendeines Data Mining Prozesses nützlich sind. So zeigtTaxonomies dieBaumstruktur von Taxonomien an.Check Support wiederum berech-net den Support von bestimmten Artikelmengen in zu spezifizierenden Da-tensatzen. Auf dasTools –Menu wird in 5.5 detaillierter eingegangen.

� Help DasHelp Menu bietet momentan nur einenAbout Dialog an, derdie Version und das Logo von MISTRAL zeigt.

5.3 Definition eines M ISTRAL Projekts

Zur Definition eines MISTRAL Projekts mussen die drei Schlüsselkomponentenbestimmt werden: DATA FETCHER, ALGORITHM und VIEWER. Die Festlegungder gewunschten Komponenten kann im Menü Project durchgefuhrt werden.Die Abbildung 5.2 zeigt die Definition einer Algorithmus Komponente.

Um eine andere Komponente festzulegen, wählt man denSelect Schalter. DieKomponenten DATA FETCHER und ALGORITHM erlauben hierbei nur Einfach-auswahl, während bei der Definition der VIEWER Komponente Mehrfachauswahlmoglich ist. So konnen zum Beispiel die Ergebnisse durch einen WINDOWVIEW-ER in einem Fenster dargestellt werden. Gleichzeitig schreibt ein TEXTFILE-VIEWER die Ergebnisse in eine Datei.

Hinweis Durch die Implementierung in Java treten zwei Besonderheiten bei derBedienung auf: Werden in den Textfeldern Eingaben getätigt, so mussen dieseimmer mitENTERbestatigt werden. Weiter dient der forward-slash/ als einheit-liches Trennzeichen für Dateipfade (alsoD:/Daten anstelle vonD: nDaten ).

5.4 Arbeiten mit M ISTRAL Komponenten

MISTRAL Komponenten bestimmen die wesentliche Funktionalität des Data Mi-ning Werkzeugs. Durch das einfache An– und Abkoppeln der Komponenten inMISTRAL ist diese Funktionalität sehr flexibel an ein bestehendes Data MiningProblem anpassbar.

5.4. Arbeiten mitMISTRAL Komponenten 73

Abbildung 5.2: Projektdefintion (DBCDataFetcher)

5.4.1 Koppeln

MISTRAL kann problemlos weitere Komponenten aus den Bereichen DATA FET-CHER, ALGORITHM und VIEWER aufnehmen. Wie neue Komponenten aufgebautsein sollten, kann in Abschnitt 4.2.4 detailliert nachgelesen werden. Zur Ankopp-lung und Bearbeitung der vorhandenen Komponenten dient dasComponentsMenu.

Die Abbildung 5.3 zeigt das Bearbeitungsfenster der ALGORITHM Komponente.Allgemein lassen sich in den Bearbeitungsfenstern neue Komponenten ankoppeln(Add), vorhandene Komponenten aus MISTRAL loschen (Remove) und Informa-tionenuber die gerade angewählte Komponente anzeigen (About ).

Soll eine neue Komponente in MISTRAL aufgenommen werden, so muss derAddSchalter in einer derComponentsMenus gedruckt werden. Ein Eingabefensterfragt nach der URL der anzukoppelnden Komponente. Diese URL entspricht demKlassennamen, dem sein Paketname vorausgeht.

Beispiel Wollte man etwa die neue Komponente APRIORINTERVAL mit glei-chem Klassennamen und Paketzugehörigkeit MISTRALCOMPONENTS in MI-STRAL einhangen, so müsste die URLMistralComponents.ApriorIntervallau-ten. Es wird davon ausgegangen, dass die Klasse in einem erreichbaren Java–Klassenpfad untergebracht ist.


Abbildung 5.3: Bearbeiten von MISTRAL Komponenten

5.4.2 Vorhandene Komponenten

Die Eigenschaften der schon in MISTRAL integrierten Komponenten soll hier kurzvorgestellt werden:

� DataFetcher

– TextDataFetcherDamit konnen flache Textdateien eingelesen wer-den. Eine detaillierte Beschreibung des verwendeten Dateiformatswird in Abschnitt 5.6 gegeben.

– DBCDatafetcher Diese Komponente bietet eine Anbindung an Da-tenbanken mit JDBC/ODBC Schnittstelle. Durch Angabe des instal-lierten Datenbanktreibers und der Datenbankquelle (URL) kann jedeJDBC/ODBC Datenbank an MISTRAL gekoppelt werden. Ein zu spe-zifizierender SQL Befehl steuert hierbei das Auslesen der Daten.

� Algorithmen

– Cumulate Ein Algorithmus zum Finden von (generalisierten) Asso-ziationsregeln. Er wurde erstmals in [SA95] vorgestellt.

– ApriorInterval Im Wesentlichen dem CUMULATE–Verfahren gleich.Zusatzlich kann hier eine obere Support–Schranke angegeben wer-

5.5. Das Tools Menü 75

den, welche die häufigen Artikelmengen bzw. Regeln einschränkt.Naheres hierzu in Abschnitt 7.2 (Seite 96).

– FrequentSetsEin Verfahren zur Bestimmung häufiger (generalisier-ter) Artikelmengen.

– ItemDistribution Dieser Algorithmus liest die komplette Datenbankein und berechnet die Häufigkeit aller vorhandenen Einzelartikel.

– DummyAlgorithm Dieser Algorithmus bewirkt nichts. Er schleustdie Daten, die er von der DataFetcher Komponente geliefert bekommt,gleich an den Viewer weiter. DUMMYALGORITHM kann in Verbin-dung mit der TEXTFILEVIEWER (MISTRAL STYLE) Komponente da-zu genutzt werden, Daten aus fremden Datenquellen in eine flache,DataFetcher kompatible, Textdatei zu konvertieren.

� Viewer

– WindowViewer Dieser Viewer gibt die Ergebnisse in einem Fensteraus. Allerdings empfiehlt sich die Benutzung von WindowViewer nurbei kleinen Resultatmengen.

– TextfileViewer Hier werden die Verbalisierungen der möglichen Re-sultate (wie Regeln oder häufige Artikelmengen) in eine einfache Text-datei geschrieben.

– TextfileViewer (Mistral Style) Wenn Resultate Transaktionen sind,dann werden diese im TextDataFetcher Format geschrieben. Anson-sten wie bei TextfileViewer.

– TextfileViewer (Tabulator Style) Wenn die Resultate Regeln sind,dann werden diese in einem tabellenähnlichen Format geschrieben.Ansonsten wie bei TextfileViewer.

5.5 Das Tools Men u

Zum Verstandnis der Daten hält MISTRAL einige Werkzeuge bereit, die direkt ausdem Programm gestartet werden können:

TaxonomiesZwischen Artikeln konnen Hierarchien, sogenannte Taxonomien, gebildet wer-den. Milchprodukteist dann z. B. eineUbergruppe vonMilch, welche ihrerseitswieder eineUbergruppe vonH–Milch ist. Solche Taxonomien werden mit Hil-fe einer Taxonomiedatei bei einigen Algorithmen (z.B. CUMULATE) angegeben.


Um einenUberblick uber die definierten Hierarchien zu gewinnen, können dieTaxonomiebäume mit dem Tool TAXONOMIES angezeigt werden.

Abbildung 5.4: Tool Taxonomies

Check SupportZur Voranalyse oder auch zur Kontrolle der Ergebnisse kann das Tool CHECK

SUPPORTdienen. Hier wird eine im TextDataFetcher Format gespeicherte Dateials Datenbasis angegeben. Eine spezifizierte Artikelmenge wird daraufhin vondiesem Tool in der Datenbasis gesucht. Nach dem erfolgreichen Lauf durch dieDaten wird der Support der angegebenen Artikelmenge berechnet und ausgege-ben. Auf diese Weise lassen sich einzeln häufige Artikelmengen und Konfidenzenvon Regeln berechnen bzw. überprufen.

5.6 Dateiformat: TextDataFetcher

Oftmals ist es nötig, die Daten aus einem proprietären Datensystem in eine flacheTextdatei zu überfuhren. Dadurch wird die folgende Transformation der Datenmeist erst ermöglicht oder zumindest vereinfacht. Die Komponente TEXTDATA -FETCHERbildet das Bindeglied zwischen solchen Textdateien und dem MISTRAL

Kern. Das Format ist denkbar einfach:

Jede Zeile besteht aus genau einer Transaktion. Die Einträge in dieser Zeile sinddurch Tabulatoren getrennt. Dabei wird der erste Eintrag als Transaktionsiden-tifikation (TID) interpretiert. Die folgenden Einträge stellen die verschiedenenArtikel dar.

5.7. Dateiformat: Taxonomie-Definition 77

TID1 [<--TAB]Artikel1 [<--TAB]Artikel2TID2 [<--TAB]Artikel2 [<--TAB]Artikel3TID3 [<--TAB]Artikel1

...

Abbildung 5.5: Format TextDataFetcher

5.7 Dateiformat: Taxonomie-Definition

Taxonomien werden in Dateien definiert. Dabei muss der komplette Hierarchie-wald in einer Datei abgelegt sein. Die einzelnen B¨aume werden durch eine Zeilegetrennt, die den Bezeichner[NEWTREE]enthalt. Auch die letzte Baumdefiniti-on in der Datei sollte mit dieser Zeile enden.

Zwischen zwei[NEWTREE] wird der eigentliche Baum definiert: Jede Zeileenthalt genau einen Ursprungs- und einen Endknoten, die beide durch einen Ta-bulator getrennt sind. Der erste Knoten einer Baumdefinition kennzeichnet dabeidie Wurzel. Sonst gilt folgende Grundregel: Jeder Knoten auf der linken Seitemuss zuvor (in einer vorhergehenden Zeile) schon einmal als Endknoten auf derrechten Seite definiert worden sein. Der Baum aus Abbildung 5.4 m¨usste also sobeginnen:

[NEWTREE]Milchprodukte [<--TAB] MilchMilchprodukte [<--TAB] JogurtMilch [<--TAB] Fit–MilchMilch [<--TAB] H–MilchH–Milch [<--TAB] H–Milch1.5%H–Milch [<--TAB] H–Milch0.2%Jogurt [<--TAB] JogurtNaturJogurt [<--TAB] JogurtGeschmack...[NEWTREE]

Abbildung 5.6: Format Taxonomie Definition

6

Auswertung der Daten undErgebnisse

Um die Korrektheit und Leistungsfähigkeit von MISTRAL zu zeigen, wurden dieersten Programmläufe mit synthetisch erzeugten Daten durchgeführt. Dabei han-delte es sich um künstlich generierte Transaktionen aus der Warenkorbdomaine.Spater wurden Daten aus zwei realen Anwendungsbereichen untersucht. Bei-de ließen sich ebenfalls auf die Transaktionsebene transformieren. Eine Daten-bank beinhaltete Ergebnisse von Abgas–Katalysatortests der Firma Degussa AG(Hanau–Wolfgang), während die andere Datenbank aus der Warenwirtschaft derFirma Quitmann (Hagen) stammte. Beide Datenbanken sind unterschiedlich di-mensioniert und verfügenuber entgegengesetzte Datencharakteristika.

Von besonderem Interesse war auch die Frage, inwieweit sich die Standardverfah-ren auf eine diagnostische Domäne anwenden lassen. Hierfür wurden Falle auseiner Wissensbasis zur Pflanzenerkennung herangezogen.

6.1 Synthetische Daten

Die Evaluation des Data Mining Programms MISTRAL wurde mit synthetischenDaten durchgeführt. So wurden Datensätze mit unterschiedlicher Größe, abergleicher Charakteristik generiert. Als Charakteristik konnte der Support einigerausgezeichneter Artikelmengen bestimmt werden. Alle übrigen freien Artikelpo-sitionen wurden in der Datenbank durch Dummy-Artikel aufgefüllt. Durch dieFestlegung des Supports konnte auch die Konfidenz von Regeln vordefiniert wer-

79

80 6. Auswertung der Daten und Ergebnisse

den. Denn die Konfidenz einer RegelA) B berechnet sich aus dem Support derArtikelmengenfAg undfA;Bg.

Baum Tiefe BlatterMilchprodukte 3 15Gemuse 2 5Obst 2 6Brot 2 6Susswaren 2 8Wurst 2 3Nudel 1 4Fruhstuck 2 5Getranke 4 10

Abbildung 6.1: Taxonomiebäume der synthetischen Daten

Die Transaktionsgröße wurde sowohl poissionverteilt (mit Mittelwert� = 10)als auch gleichverteilt (pro Transaktion 10 Artikel) gewählt. Fur jede Verteilungentstanden jeweils fünf Datensätze zu 1000 (1K), 5000 (5K), 10000 (10K), 50000(50K) und 100000 (100K) Transaktionen. Jeder Datensatz verfügteuber 1055 ver-schiedene Einzelartikel, 55 ausgezeichnete und 1000 zufällige Fullartikel. Die 55ausgezeichneten Artikel wurden mit Namen aus der Warenkorbdomäne beschrif-tet.

Transaktionen Verteilung Artikelzahl Trans.große

1Kgleich 10000 10.0000

poisson 9908 9.9080

5Kgleich 50000 10.0000

poisson 49900 9.9800

10Kgleich 100000 10.0000

poisson 99897 9.9897

50Kgleich 500000 10.0000

poisson 499951 9.9990

100Kgleich 1000000 10.0000

poisson 999902 9.9990

Abbildung 6.2: Große der synthetischen Daten

Abbildung 6.2 zeigt für jeden Datensatz die Anzahl der darin enthaltenen Artikel.

6.1. Synthetische Daten 81

Die durchschnittliche Transaktionsgröße definiert sich aus dem Quotienten derTransaktionenanzahl und der Artikelanzahl.

Transaktionen Verteilung Dateigroße Zeit (m. Tax.) Zeit (o. Tax.)

1Kgleich 75 548 Byte 20,17 min. 1,27 min.

poisson 71 968 Byte 22,71 min. 1,31 min.





50Kgleich 3 782 862 Byte 152,63 min. 45,42 min.

poisson 3 733 776 Byte 152,63 min. 44,02 min.

100Kgleich 7 565 725 Byte 338,33 min. 95,18 min.

poisson 7 467 553 Byte 320,30 min. 88,06 min.

Abbildung 6.3: Performanz von MISTRAL mit synthetischen Daten (Tabelle)

Zusatzlich wurden für die 55 ausgezeichneten Artikel noch Generalisierungenin Form von neun Taxonomiebäumen verfügbar gemacht. Die Tiefe und derBlatterbestand der einzelnen Bäume ist in Abbildung 6.1 verzeichnet.

0

50

100

150

200

250

300

350

0 10 20 30 40 50 60 70 80 90 100

Zei

t (m

in.)

Datenbankgroesse (in KB)

gleichverteilt (mit Tax.)poisson verteilt (mit Tax.)gleichverteilt (ohne Tax.)

poisson verteilt (ohne Tax.)

Abbildung 6.4: Performanz von MISTRAL mit synthetischen Daten (Graphik)

Zur Evaluation wurden die 10 Datensätze sowohl mit Taxonomien als auch ohneAngabe von Taxonomien untersucht. Da die Charakteristik der Daten (Häufigkeit


der Artikelmengen) bekannt war, konnten Korrektheit und Vollständigkeit der Re-geln uberpruft und bestätigt werden. Folglich erzeugt MISTRAL auch fur alleDatengroßen die gleichen Regeln.

Die Tabelle in Abbildung 6.3 zeigt die Performanz der Implementierung in denunterschiedlichen Testläufen. Abbildung 6.4 zeigt sehr deutlich, wie der Zeitbe-darf fast linear mit der Datenbankgröße zunimmt. Der etwas höhere Zeitbedarfder gleichverteilten Daten im Vergleich zu den poissonverteilten Transaktionenlasst sich mit dem entsprechend größeren Datenumfang begründen. Die gleich-verteilten Daten enthalten jeweils geringfügig mehr Artikel in den Transaktionenals die poissonverteilten Datensätze. Dies verdeutlicht die Tabelle in Abbildung6.2. Eine weitere interessante Eigenschaft lässt sich in Abbildung 6.4 beobach-ten: Der Zeitbedarf der Testläufe mit Taxonomien steigt merklich steiler an alsder Zeitbedarf der Testläufe ohne Verwendung von Taxonomien. Einen paralle-len Verlauf zu den Kurven ohne Taxonomien würde man zuerst erwarten. DieseKurven erklaren sich aber in folgender Weise: Die Verfahren müssen bei Taxo-nomien nicht einfach nur mehr Artikel verarbeiten, sondern fügen auch bei jedemDatenbankdurchlauf in jeder Transaktion die Vorfahren hinzu. Nach jedem Da-tenbankdurchgang werden die nicht mehr benötigten Vorfahren eliminiert. Diesschlagt sich in dem wesentlich hö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–jahriges Bestehen und ist vielen als Edelmetallverarbeiter ein Begriff. Seit 1968 istdie Degussa jedoch auch in der Entwicklung von Autoabgas-Katalysatoren tätig.Heute halt sie als Lieferant für diese Katalysatoren 20% des Weltmarktanteils.

Die Entwicklung neuer Katalysatoren umfasst viele Einzelschritte und eine An-zahl von Tests und Auswertungen. Am Ende dieser Kette stehen Testfahrten, dieein Katalysator — in einen realen PKW eingebaut — auf dem Rollband absolvie-ren muss. Bei jeder Testfahrt entsteht eine Vielzahl von Meßergebnissen.

Die untersuchten Daten stellen eine Teilmenge dieser Testfahrten dar. Der Daten-satz lag in einer relationalen Datenbank (MS-Access) vor und umfasste 2769 Test-fahrten aus den Jahren 1996 und 1997. Für jede Fahrt wurden 18 Attribute erfasst,die sich wie folgt aufschlüsseln: Datum der Fahrt, Motortyp (Otto/Diesel), Mo-tornummer (Art und Größe des Motors), Fahrer, Analytiker, weitere Parameter,die den Katalysator beschreiben und vier Auswertungsergebnisse der Testfahrt.Die Inhalte und Namen der Felder wurden teilweise verschlüsselt, da es sich umbetriebssensible Daten handelt.

6.2.1 Vorverarbeitung der Daten

Fachleute der Degussa AG überfuhrten die quantitativen Attribute in Intervalle,die mit Buchstaben oder Zahlen symbolisiert wurden. Taxonomien waren nichtbekannt. Da die Testfahrten in einer relationalen Datenbank vorlagen, gestaltetesich die Vorverarbeitung sehr einfach: Jede Testfahrt wurde als eine Transakti-on betrachtet, deren Artikel sich als Kombination des Feldnamens und des Feld-werts definierten. So entstanden beispielsweise die ArtikelDATUM-19970228oderFAHRERNR-6.

Durch die obige Transformation entstanden 737 verschiedene Einzelartikel (Aus-pragungen der Feldnamen), verteilt auf 2769 Transaktionen. Jede Transaktionenthielt genau 18 Artikel und eine fortlaufende Zahl als Transaktionsidentifikation(TID).


6.2.2 Ergebnisse

Es ist leicht ersichtlich, dass der zeitliche Ausschnitt von nur zwei Jahren dieVielfalt der Attributverteilung begrenzt. Gespeichert wurden im Grunde genom-men die Entwicklung weniger Katalysator–Typen und deren verschiedene Proto-typenergebnisse. Daher variieren die Attributkombinationen meist nur minimal.Hieraus folgt aber, dass sehr viele Artikelkombinationen als ,,häufig” gekenn-zeichnet werden. So überraschten die vielen Regeln trotz hoher Support– undKonfidenzwerte wenig.

0

200

400

600

800

1000

1200

1400

1600

1800

2000

30 40 50 60 70 80 90 100

Anz

ahl d

er R

egel

n

Support (in %)

Konfidenz 70%Konfidenz 80%Konfidenz 90%

0

50

100

150

200

250

300

350

400

450

40 50 60 70 80 90 100

Anz

ahl d

er R

egel

n

Support (in %)


Abbildung 6.5: Anzahl der Regeln (Degussa Testfahrten)

Die Abbildung 6.5 zeigt, wie die Anzahl der Regeln bei fester Konfidenz undvariablem Support variiert. Dabei sind die Werte für eine feste Konfidenz von70%, 80% und 90% aufgetragen.

Man sieht, dass die Anzahl der Regeln unter einem Support von etwa 60% nichtmehr fur eine manuelle Auswertung geeignet ist. Ebenso ist deutlich zu erkennen,dass die Regelgröße unter 40% Support exponentiell ansteigt.

Eine Vorstellung von der Regelgröße gibt die folgende Tabelle in Abbildung 6.6,welche die Größe der Regeln nach Support und Konfidenz aufgeschlüsselt dar-stellt. Dabei bedeutet2er Regel, dass die Regel von zwei Artikeln aufgespanntwird (z.B. MOTOR TYP-C) KAT ERGEBNIS-A).

Die gefundenen Regeln wurden von Degussa wieder rekodiert und bewertet. ZumZeitpunkt der Drucklegung der vorliegenden Arbeit war die Auswertung der Er-gebnisse noch nicht fertiggestellt. Eine Bewertung der Regeln ist also leider nichtmoglich.

6.3. Die Warenwirtschaft der Firma Quitmann 85

Anzahl der Regeln nach Regelgröße

Konfidenz Support 2er 3er 4er Gesamt

70% 60% 17 55 58 13070% 12 36 40 8880% 8 9 0 1790% 4 0 0 4

80% 60% 14 37 33 8470% 11 25 18 5480% 8 9 0 1790% 4 0 0 4

90% 60% 12 31 30 7370% 9 19 15 4380% 7 7 0 1490% 4 0 0 4

Abbildung 6.6: Verteilung der Regelgrößen (Degussa)

6.3 Die Warenwirtschaft der Firma Quitmann

Als mittelstandischer Betrieb aus Hagen mit 85 Mitarbeitern und 25 Millio-nen DM Umsatz im Jahr vertreibt die Firma Quitmann Büroeinrichtungen, –maschinen und –bedarf. Alle Aufträge werden in einem Warenwirtschaftssystemerfasst und gespeichert. Im Rahmen dieser Arbeit sollte die AbteilungBurobedarfuntersucht werden, da sich die Firma hier interessante Ergebnisse versprach.


Die elektronische Erfassung der Warenwirtschaft wird durch das System UBISder Firma Haas aus Gummersbach geregelt. Da das System bis jetzt noch ei-ne proprietare, filesystem-ähnliche Datenhaltung einsetzt, mussten die Daten ineine flache Textdatei exportiert werden. Diese enthielt Umsatz und Rohgewinnaller Kunden in den Jahren 1996 und 1997, aufgeschlüsselt in die sieben Bereichedes Unternehmens: Möbel, Burobedarf, Kopierer, Computer, Postbearbeitungs-maschinen, sonstige Maschinen und technischer Kundendienst.

Ausgehend von dieser gut 255 MB großen Datei mit 785246 Zeilen wurde eineKonvertierung in ein MISTRAL kompatibles Format durchgeführt. Weiter wur-den die Auftrage nach Kundennummer und Auftragsdatum sortiert. Aufträgeder gleichen Kunden selben Datums wurden zusammengeführt. Als Transakti-


ons ID wahlte man eine Kombination zwischen Kundennummer und Auftragsda-tum. Ubrig blieb eine knapp 6 MB große Textdatei mit 121412 Transaktionen, diedurch 25196 Einzelartikel aufgespannt wurden. Die durchschnittliche Transakti-onsgroße betrug 3,22 Artikel.

Eine weitere Datei wurde bereitgestellt, die alle Artikel aus der AbteilungBuro-bedarf in 42 Produktgruppen unterteilte. Diese wurden benutzt, um alle Arti-kel aus den Transaktionen zu entfernen, die keinerBurobedarf–Produktgruppezugehorig waren. Daraufhin artikellose Transaktionen wurden entfernt. Diesdezimierte die Transaktionenzahl von 121412 auf 70309 Datensätze mit 9803Einzelartikeln. Die durchschnittliche Transaktionsgröße blieb mit 3,28 Artikelnetwa gleich. Dies erklärt sich daraus, dass Transaktionen ohne Bürobedarf–Produktgruppen in der Regel sehr klein waren (1–2 Artikel) und sich damitdie durchschnittliche Transaktionsgröße erst einmal erhöhte. Weil die ,,Nicht–Burobedarfs–Artikel” aus den verbliebenen Transaktionen allerdings entferntwurden, verringerte sich aber die Transaktionsgröße wieder.

6.3.2 Ergebnisse

Die Anzahl der verwendeten Einzelartikel (9803 Artikel), die sich auf nur 70309Transaktionen verteilen, und die kleine durchschnittliche Transaktionsgröße von3,28 Artikeln ließen keine großen Erwartungen bezüglich der zu findenden Regelnaufkommen. Bei einem ersten Testlauf stellte sich heraus, dass nur 22 Einzelarti-kel (0.2% von 9803) einen Support von 0.5% erreichen würden. Kombinationenzwischen diesen ,,häufigen” Artikeln ließen den Support weiter drastisch fallen(unter 0.02% Support), so dass an eine Regelgenerierung nicht mehr zu denkenwar. Durch die Verwendung der Produktgruppen als Artikel-Taxonomien konntenjedoch in der Voranalyse einige häufige Artikelmengen gefunden werden.

Daraufhin wurde ein Data Mining Lauf mit 0.3% Support und 60% Konfidenzdurchgefuhrt. Das Verfahren CUMULATE entdeckte 719 Regeln, die in Abbildung6.7 nach ihrer Größe und Anzahl detailliert aufgeschlü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 (Regelnmit nur einer Vorbedingung und einer Nachbedingung) und Regeln mit Einzelar-tikeln von Interesse waren. Assoziationsregeln mit größeren Vor– und Nachbe-dingungen, die ausschließlich aus Produktgruppen bestanden, ließen keine befrie-digende Analyse der Zusammenhä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% 51 155 256 213 44 7190.6% 10 65 110 37 0 2221.0% 3 42 43 0 0 88

70% 0.3% 11 67 156 146 25 4050.6% 1 24 64 19 0 1081.0% 0 13 27 0 0 40

80% 0.3% 0 9 62 78 10 1590.6% 0 3 21 12 0 361.0% 0 0 6 0 0 6

Abbildung 6.7: Verteilung der Regelgrößen (Quitmann)

Nachdem die Regeln des vorherigen Data Mining Laufs nach diesen Kriterien ge-filtert worden waren, verblieben 110 Assoziationen in der Ergebnismenge. Darinwaren 54 2er Regeln, 53 3er Regeln und drei 4er Regeln enthalten.

Bis auf zwei Ausnahmen bildeten die 2er Regeln grundsätzlich Einzelartikel aufdie Produktgruppe [101] (Ordnungsmittel) ab. Dies ist wenig verwunderlich, dadiese Produktgruppe mit einem Support von 49.68% in der Datenbasis außeror-dentlich stark vertreten ist. Nur zwei Regeln zeigten Assoziationen zwischen zweiProduktgruppen:

(Rund um den Schreibtisch) ) (Ordnungsmittel) [sup: 3,57%; con: 61,86%]

(KL-Rund um den Schreibtisch) ) (Ordnungsmittel) [sup: 1,05%; con: 61,82%]

Das PrafixKL bezeichnet eine Produktgruppe, deren Artikel nicht auf Lager warenund somit bestellt werden mussten. Ebenso waren Regeln mit hoher Konfidenzvon Interesse. Die Regel

DOR9778) (Rund um den Schreibtisch) [sup: 0,34%; con:78,18%]

beispielsweise hatte den höchsten Konfidenzwert aller 2er Regeln. Der Einzel-artikel DOR9778 gliedert sich in die Produktgruppe (Schreiben/Zeichnen (Büro))ein.

Als Folgerung auf die gefundenen Regeln und die Ergebnisse der Auswertunguberlegt die Firma Quitmann momentan, ihren Warenkatalog umzustellen. Arti-kel bzw. Produktgruppen, die häufig miteinander konsumiert werden, sollen dann


0

20

40

60

80

100

120

140

0 0.5 1 1.5 2 2.5 3

Anz

ahl d

er R

egel

n

Support (in %)


Abbildung 6.8: Anzahl der Regeln (Quitmann)

auch nahe beieinander im Katalog vertreten sein, um so dem Kunden die Bestel-lung zu erleichtern. Langfristig wird eineUberprufung der Produktstandorte imLadengeschäft angestrebt. Auch hier sollen assoziative Artikel und Produktgrup-pen naher zusammenrücken.

6.4 Pflanzenwissensbasis

Als Beispiel fur eine Datensammlung in diagnostischer Domäne wurde eine Pflan-zenwissensbasis aus dem Expertensystem D3 [PGPB96] verwendet. Diese Wis-sensbasis wurde im Rahmen einer Praktikumsarbeit (siehe dazu auch [Ern96]) er-stellt und beinhaltet 13101 Fälle. Jeder Fall ist hierbei in 3 Fragebögen (,,Blute”,,,Blatter”, ,,Stengel”) aufgeteilt, die zusammen 40 Merkmalsbeschreibungen um-fassen. Darüber hinaus ist zu jeder Pflanze eine Abbildung verfügbar.


Fur den Data Mining Lauf wurden die Fälle in eine flache Textdatei exportiert.Jeder Fall erhielt eine eigene Zeile, welche eine eindeutige Fallidentifikation, eineDiagnose des Pflanzentyps und 40 Merkmalsausprägungen enthielt. Die Daten-basis wurde somit in ein transaktionelles Format mit 41 Artikeln und einer ID proTransaktion überfuhrt.

6.4. Pflanzenwissensbasis 89

6.4.2 Ergebnisse

Es sind 74 verschiedene Diagnosen und 102 verschiedene Merkmalsausprägungenin der Datenbasis gespeichert. Da Regeln mit Diagnoseattributen von besonderemInteresse waren, wurde die Verteilung der 74 Diagnosen näher betrachtet.

Die haufigste Diagnose ist mit 396 Fällen (3,02% Support) in der Wissensbasisgespeichert. Die seltenste Diagnose ist nur mit 125 Fällen vertreten, was einemSupport von circa 0,95% entspricht. Damit also alle Diagnosen in den zu generie-renden Regeln vertreten wären, musste der minimale Support unter 0.95% gesetztwerden.

Die Anzahl der Attribute pro Fall und einige Voranalysen ließen eine große An-zahl von Regeln vermuten. Daher wurden zunächst alle Fälle mit der Diagno-sep6355(Duftlose Kamille�Matricaria inodora�) aus der Wissensbasis extra-hiert. Diese Testmenge sollte probeweise untersucht werden. Die Diagnose p6355wurde gewahlt, da sie mit 396 Fällen am stärksten vertreten war. Der minimaleSupport wurde auf 80%, die minimale Konfidenz auf 90% gesetzt. Der Testlaufermittelte 20768 Regeln, die diesen Schwellwert erfüllten; 10213 Regeln davonbeinhalteten die Diagnose. Einen genauenUberblick verschafft die Tabelle in Ab-bildung 6.9, welche die Diagnoseregeln nach ihrer Regelgröße aufschlüsselt. DieSpaltenVorbedingungund Nachbedingunggeben an, wieviele Regeln das Dia-gnoseattribut in der Vor– bzw. Nachbedingung beinhalten.

Anzahl der Regeln pro Regelgroße

Vorbedingung Nachbedingung Gesamt

2er Regel 11 8 193er Regel 194 124 3184er Regel 1787 888 26755er Regel 5182 2019 7201

Abbildung 6.9: Verteilung der Regelgrößen (Pflanzen)

Es ist verständlich, dass die große Anzahl der Regeln für eine manuelle Auswer-tung unbrauchbar ist. Sogar die minimale Konfidenz von 100% wird immer nochvon 4926 Regeln erfüllt.

Testlaufe mit anderen Diagnose-Clustern (bspw. mit dem DiagnoseattributKorn-blume�Centaurea cyanus�) errechneten eine ähnlich große Anzahl von Regeln.

Zusatzlich wurde ein Lauf mit dem Standardverfahren CUMULATE uber der ge-


samten Datenbasis durchgeführt. Der minimale Support wurde auf 50% und dieminimale Konfidenz auf 70% gesetzt. Mit diesen hohen Schwellwerten erzeug-te das Verfahren 409 Assoziationsregeln. Roman Ernst vom Biologischen Insti-tut (Universitat Wurzburg), der die untersuchte Pflanzenwissensbasis erstellt hat-te, sichtete die Resultate und bestätigte die Vermutung, dass nur triviale Zusam-menhange gefunden wurden. Als Beispiel soll folgende Regel aus der Ergebnis-menge dienen:

netznervige oder fiedernervige Blattveratur^ kein Stengelmilchsaftkein gefarbter Milchsaft) keine Blattranken[sup: 64,35%; con: 96,1%]

Diese Regel ist nicht besonders verwunderlich, da in der Natur die Attribute inder vorliegenden Kombination häufig auftreten. Folglich assoziieren die Attributeauch in der Wissensbasis stark.

Die erfolgreiche Implementierung des APRIORINTERVAL–Verfahrens (siehe 7.2,Seite 96) ermöglichte die Untersuchung der Datenbasis in einem beschränktenSupportintervall.

Konfidenz 100% 95% 90% 85% 80% 75% 70%Regelanzahl 17 21 22 25 25 29 32

Abbildung 6.10: Anzahl der Regeln nach Konfidenz (Pflanzen)

So wurde das zulässige Supportintervall auf [0,1%; 3,5%] gesetzt und eine mini-male Konfidenz von 70% verlangt. APRIORINTERVAL fand 32 Regeln, welchedie vorgegebenen Schwellwerte erfüllten.

16

18

20

22

24

26

28

30

32

70 75 80 85 90 95 100

Anz

ahl d

er R

egel

n

Konfidenz (in %)

Abbildung 6.11: Anzahl der Planzen–Regeln nach Konfidenz

Die Tabelle 6.10 schlü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 bestätigte die gefundenen Regeln. Im Wesentlichen handeltees sich hierbei um Regeln, die auch in der Wissensbasis eingegeben waren. Somitkonnte das Data Mining Verfahren zur maschinellen Wissens–Reproduktion die-nen. Herr Ernst vermutete, dass die bestehende Datenbasis mit 13101 Fällen zuklein fur Zusammenhänge sei, die überraschend für einen Biologen wären.

7

Regelfindung in diagnostischenDomanen

Die Anwendung des Verfahrens in diagnostischen Domänen, wie der Pflanzen-Wissensbasis, konnte zu keinem befriedigenden Ergebnis führen. Der Grunddafur liegt in der ungewöhnlichen Ausgangslage: Oftmals sind im Vergleich zurtraditionellen Warenkorbdomäne relativ wenige Transaktionen vorhanden. Zu-satzlich ist das Ziel selten das Finden der häufigsten Korrelationen. Vielmehr sindmeist die oft auftretenden Assoziationen am wenigsten interessant. So treten bei-spielsweise in der Medizin häufige Symptome in vielen Diagnosen auf und sinddaher in einer Regel wenig bedeutungsrelevant. Interessanter wäre es also, Asso-ziationen mit vergleichsweise wenig Support, aber hoher Konfidenz zu finden.

Die bekannten Assoziationsregel–Verfahren in der aktuellen Forschung untersu-chen nur das Finden von Regeln mit hohem Support und hoher Konfidenz. In denfolgenden Absätzen soll beschrieben werden, wie Regeln mit niedrigem Support,aber hoher Konfidenz gefunden werden können.

7.1 Clusterbildung unter Verwendung vonStandardverfahren

Um schon bestehende Standardverfahren weiter verwenden zu können, müsstendie Daten zuvor in geeigneter Weise vorverarbeitet werden.

93

94 7. Regelfindung in diagnostischen Domänen

7.1.1 Vorgehensweise

Kennt der Anwender signifikante Untergruppen innerhalb der Datenbasis, so bie-tet es sich an, diese in Clustern zu gruppieren. Auf solche Weise ließe sichbeispielsweise in einer medizinischen Domäne nach Ausprägung der Diagnosengruppieren. Auf jeden einzelnen Cluster könnte dann ein Standardverfahren, wieAPRIORI, zum Finden von Regeln verwendet werden. Nachdem die Regeln fürdie einzelnen Cluster gefunden worden sind, werden sie in Bezug auf die gesamteDatenbasis überpruft. Im Folgenden wird die Vorgehensweise näher betrachtet:

ClusterbildungBei dieser Vorgehensweise hat eindeutig die Vorverarbeitung, also die Cluster-bildung, eine Schlüsselposition inne. Nicht immer ist es ersichtlich, ob vorge-nommene Gruppierungen sinnvoll oder erfolgversprechend sind. Eine manuelleClusterbildung nach dem diagnostizierenden Attribut scheint hier jedoch am sinn-vollsten. Das clusterbildende Attribut wird im folgenden alssignifikantes Attributbzw. die Ausprägung alssignifikanter Artikelbezeichnet.

StandardverfahrenEin Standardverfahren, wie beispielsweise APRIORI, generiert fur jeden Clustereinzeln die entsprechenden Assoziationsregeln. Bei der Generierung der Regelnsollte dann darauf geachtet werden, dass der signifikante Artikel stets enthalten ist.Dadurch wird gesichert, dass nur für diesen Cluster interessante Regeln erzeugtwerden.

Abschließender ScanSind die Regeln für die jeweiligen Cluster generiert worden, so sollten sie im Kon-text der gesamten Datenbasis überpruft werden. Die Dezimierung des Support-wertes bereitet aus oben angeführten Grunden keine Probleme. Der Veränderungdes Konfidenzwertes sollte aber Beachtung geschenkt werden:

Befindet sich der signifikante Artikel in der Vorbedingung der Regel, so bleibtder Konfidenzwert im Vergleich Cluster$ Gesamtdaten gleich. Dies ist leichtersichtlich, da der signifikante Artikel als einziger in dem berechneten Clusterenthalten gewesen sein kann. Folglich muss der Konfidenzwert gleich bleiben.Auf eine interessante Regel deutet jedoch ein unveränderter Konfidenzwert hin,wenn sich der signifikante Artikel in der Nachbedingung der Regel befindet. Dar-aus kann man schließen, dass alle Attribute der Regelvorbedingung nur in diesemeinen Cluster enthalten waren. Hieraus folgt eine starke Assoziation mit demsignifikanten Artikel. Wird der Konfidenzwert im Gesamtvergleich jedoch klei-ner, so muss ein anzugebender Schwellwert entscheiden, ob die Regel noch in-teressant erscheint. Dieser Schwellwert könnte beispielsweise auf die Differenz

7.1. Clusterbildung unter Verwendung von Standardverfahren 95

[KonfidenzCluster �KonfidenzD] bezogen sein.

Abschließend sollte man sich allerdings des Nachteils bewußt sein, dass durch diestrikte Unterteilung in Cluster keine Assoziationsregeln gefunden werden können,die zwei oder mehrere signifikante Artikel enthalten.

7.1.2 Komplexit at

Der Aufwand dieses Verfahrens errechnet sich aus der Summe der Komplexitätzur Clusterbildung und der Komplexität des Standardverfahrens. Im Folgendensei die DatenbasisD gegeben, die Menge der Cluster seiC und es seiR dieMenge der gefundenen Regeln. Zunächst wird der Aufwand für jeden einzelnenPunkt betrachtet und anschließend zusammenfassend die gesamte Komplexität.

ClusterbildungGruppiert man die Transaktionen nach der Ausprägung des diagnostischen At-tributs, so beschränkt sich der Aufwand der Clusterbildung auf einen komplet-ten Durchlauf durch die Datenbasis. Pro Transaktion werden eine Suchoperationnach dem signifikanten Attribut und eine Hashoperation benötigt. Die Hashope-ration weist der jeweiligen Transaktion gemäß ihrem signifikanten Artikel denpassenden Cluster zu. Der Rechenaufwand der Hashfunktion wird bei optimalemHashing als konstant angenommen.

Bei separater Speicherung der Cluster wird ein Speicherbereich benötigt, welcherder Große der Datenbasis entspricht. Eine im Zugriff auf die Cluster wenigerschnelle aber speichersparende Lösung stellt die Verzeigerung der Transaktionendar. Im jeweiligen Cluster werden dann nicht die kompletten Transaktionen ge-speichert, sondern nur ein Zeiger auf die entsprechende Transaktion in der Da-tenbasis. Da auf jede Transaktion nur ein Zeiger gerichtet sein kann, ergibt sichals Speicherbedarf ersichtlicherweise (es wird als Speicherbedarf von 1 Byte proZeiger angenommen):jDj � 1 Byte.

StandardverfahrenNach der Verwendung der Clusterbildung ist der für das Standardverfahren be-kannte Aufwand zu betrachten. Dadurch, dass die einzelnen Cluster im Durch-schnitt relativ kleine Datenbasen darstellen und somit der Datenbankdurchlaufschneller vollzogen wird, ist eine schnelle Berechnung der Artikelmengen zu er-warten. Fur eine genaue Betrachtung der Komplexität des APRIORI–Verfahrenswird auf Abschnitt 3.5 (Seite 55) verwiesen.

Abschließender ScanDen Abschluss des Verfahrens bildet ein zusätzlicher Durchlauf durch die gesam-


te Datenbasis, um die gefundenen Regeln im Hinblick auf ihre Konfidenzwertezu bewerten. Dabei ist der Aufwand vonO (2 � jRj) Vergleichen pro Transakti-on zu verrechnen. Dies erschließt sich daraus, dass sich die Konfidenz aus demSupport der zwei erzeugenden Artikelmengen ermittelt. Insgesamt ist also mitO (2 � jRj � jDj) Vergleichen zu rechnen.

GesamtaufwandDer gesamte Aufwand für dieses Verfahren berechnet sich also wie folgt:

O (jDj � SuchOperation) Such–Operationen

(Bildung des Clusters)

O (jCj � (Aufwand APRIORI)) (Standardverfahren)O (2 � jRj � jDj) Vergleiche (Abschließender Scan)

Die Speicherverbrauch variiert nach der Speicherart der Cluster: Werden die Clu-ster separat gespeichert, so wird ein der Datenbankgröße entsprechender Speicher-bereich benötigt, bei Verzeigerung nurjDj � 1 Byte. Die Speicherung der Regelnbenotigt zusatzlich jRj � 10 Byte, wenn man davon ausgeht, dass die Speicherungeiner einzelnen Regel höchstens10 Byte beansprucht.

7.2 Support in Intervallen (A PRIORINTERVALL )

Wie schon besprochen sind Artikelmengen mit niedrigem Support für die Regel-bildung von Interesse. Das Finden von ,,seltenen Artikelmengen” ist also eine lo-gische Folgerung. Alleine das Herabsetzen des minimalen Supports ist jedoch ei-ne wenig erfolgversprechende Maßnahme. Durch die exponentielle Vergrößerungder Artikelmengenanzahl würde dann auch die Regelmenge unü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 abhelfensoll: Zusatzlich zum bekannten minimalen Support wird einmaximaler Supporteingefuhrt, welchen die Artikelmengen nicht überschreiten dürfen. Dieser spanntmit dem minimalen Support ein Intervall auf, in dem die untersuchten Artikel-mengen liegen. Diese Artikelmengen werden im Folgenden alsIntervallmengenbezeichnet.

Nach Bestimmen der im Intervall liegenden Einzelartikel kann das gewohnte Stan-dardverfahren zum Finden der Artikelmengen eingesetzt werden. Nachdem alle

7.2. Support in Intervallen (APRIORINTERVALL) 97

Intervallmengen gefunden wurden, können wie gewohnt die Regeln generiert undnach Konfidenz sortiert werden.

Man sollte aber bedenken, dass der maximale Support schon bei der Bestimmungder Einzelartikel angewandt wird. Folglich werden überhaupt nur Artikel in denRegelfindungsprozess miteinbezogen, deren individueller Support den maximalenSupport nicht überschreitet. So werden keine Regeln der FormA) B mit Sup-port kleiner dem maximalen Support gebildet werden können, wenn die Einzelar-tikelA undB den maximalen Support überschreiten. Daraus folgt, dass nicht alleRegeln erzeugt werden, die im angegebenen Supportintervall liegen. Dieser Ver-lust der Vollstandigkeit kann aber auch erwünscht sein. Denn gerade durch dieseEigenschaft werden keine Artikel(kombinationen) zur Regelbildung verwendet,die haufiger als im maximalen Support angegeben vorkommen. Dies unterstütztdas Ziel, Regeln zu finden, deren Artikel zwar nicht häufig vertreten sind, die abereine starke Konfidenz aufweisen.

Bestimmen der IntervallgrenzenEin offensichtliches Problem stellt die Bestimmung der Intervallgrenzen dar. DieGroße des Intervalls entscheidet über Anzahl und Qualität der erzeugten Artikel-mengen bzw. Regeln.

Als obere SchrankeImax des Intervalls sollte mindestens der maximale Support-wert der interessanten Einzelartikel herangezogen werden. Wie schon bei derClusterbildung erwähnt, ist es äußerst hilfreich, wenn der Benutzer angibt, wel-che Artikel von besonderem Interesse sind (signifikante Artikel). In einer medi-zinischen Domäne konnten dies beispielsweise Diagnosen sein. Dieser maximaleSupportwert ist ausreichend, da mit steigender Größe der Artikelmengen der Sup-portwert nur noch sinkt. Eine empirische Erhöhung des maximalen Supports kannaber hilfreich sein, um weitere Einzelartikel mit höherem Support in den Prozesseinzubinden.

Einen alternativen Ansatz kann man in einem maximalen Support sehen, derwahrend des Laufes variiert. So würde eine anzugebende Funktion bestimmen,um wieviel der maximale Support in jedem Schritt dezimiert werden müsste. Ei-ne konstante Funktionf(x) = 0; 1 etwa wurde den maximalen Support in jedemSchritt um 0,1% veringern.

Folglich werden mit einem hohen Supportwert beginnend mehr Artikel(mengen)zugelassen, die zur weiteren Artikelmengenbildung herangezogen werdenkonnen.


7.2.2 Komplexit at

Im Wesentlichen kann die Komplexität analog zu der des APRIORI–Verfahrens(Seite 55) betrachtet werden. Durch die Beschneidung des möglichen Support-wertes fur die jeweiligen Artikelmengen tritt jedoch eine Besonderheit im Ver-halten der Cluster auf. Wie in Abschnitt 3.5 beschrieben, stellt ein Cluster ieine großtmogliche haufige Artikelmenge dar. Jede Erweiterung ist keine häufigeArtikelmenge mehr. Dies gilt auch bei der Bestimmung der APRIORINTERVALL–Artikelmengen. Die folgende Teilmengeneigenschaft der APRIORI–Cluster giltjedoch nicht mehr: ,,8c � i : c ist haufig.” Teilmengen eines APRIORIN-TERVALL–Clusters können den maximalen Support überschreiten und somit keinehaufige Intervallmenge mehr sein. WennC die Menge Cluster sei, dann gilt daher:

CAPRIORINTERVALL � CAPRIORI (7.1)

Die Komplexitat des APRIORINTERVALL Verfahrens liegt also in der des APRIO-RI Verfahrens.

7.3 Anmerkungen zum RX-Projekt

Die Idee zur Regelfindung in diagnostischen Domänen ist nicht neu. Schon inden spaten 70er Jahren beschäftigte man sich an der Stanford Universität mit derSuche nach kausalen Abhängigkeiten in einer medizinischen Domäne. Ergebnissesind im RX–Projekt [Blu84] beschrieben.

Betrachtet man das RX-Programm näher, so bemerkt man, dass nicht direkt As-soziationsregeln im Sinne dieser Arbeit gefunden werden, sondern ,,kausale Ab-hangigkeiten”. Eine kausale AbhängigkeitA ! B definiert eine Verbindungzwischen zwei Variablen, für die gilt:

1. A ist grundsatzlich Vorganger vonB (time precedence).

2. Die Intensitat vonA korreliert mit der Intensität vonB (covariation).

3. Es gibt keine dritte VariableC, die fur diese Korrelation verantwortlich ist(nonspuriousness).

Genauer betrachtet treffen also kausale Abhängigkeiten schärfere Aussagen überVerbindungen als Assoziationsregeln.

7.3. Anmerkungen zum RX-Projekt 99

Das RX Programm besteht aus drei wesentlichen Modulen: Dasdiscovery modulezur Produktion von Hypthesen, demstudy modulezur Uberprufung und Validie-rung dieser Hypothesen und einer Wissensbasis, die in allen Phasen des Prozessesmiteinbezogen wird. Die Generierung von kausalen Abhängigkeiten vollzieht sichbei RX in zwei Grundschritten:

1. Discovery moduleFinde Variablen–Paare, die kausale Abhängigkeiten zueinander pflegen. Daalle Variablen mit allen weiteren Variablen geprüft werden, entsteht hier einAufwand vonO(n2).

2. Study moduleSuche aus den Paaren die stärksten Hypothesen und validiere diese. Hierfürwerden die bestehende Wissensbasis und die darin enthaltenenproductionruleseingesetzt. Dasstudy moduleist batch–fahig, kann aber auch interak-tiv ablaufen.

Die besondere Eigenschaft von RX ist die konzeptionelle Integration einer Wis-sensbasis in den Generierungsprozess. Dies ermöglicht zum einen triviale Hy-pothesen zu verwerfen, aber auch zum anderen interessante Korrelationen her-vorzuheben. Bestätigte Korrelationen werden in die Wissensbasis aufgenommenund konnen so im weiteren Verlauf benutzt werden. Weitere Beachtung solltedenproduction rulesgeschenkt werden. In diesen Regeln wird vom ExpertenDomanenwissen abgelegt, welches bei der (automatischen) Auswahl der zu be-trachtenden Daten und der einzusetzenden statistischen Methode unterstützt. DerEinsatz vonproduction rulesbekraftigt nicht nur die Modularität des Systems,sondern erleichtert auch die Eingabe bzw.Uberprufung von neuem Wissen. Wei-ter konnen so Abhängigkeiten im bestehenden Wissen einfacher entdeckt werden.

Die feste Verdrahtung der Wissensbasis mit dem Verfahren birgt jedoch nicht nurVorteile. So sollte man bedenken, dass die Leistungsfähigkeit des Systems starkvom Umfang und der Qualität der Wissensbasis abhängig ist. Im vorliegendenRX Projekt bediente man sich einer Teilmenge der ARAMIS/TOD Datenbank(American Rheumatism Association Medical Information System/Time–OrientedDatabank), welche 1969 an der Stanford Universität entstand und über mehrereJahrzehnte gepflegt wurde.

Zusammenfassend bleibt zu sagen, dass im RX–Projekt einige Konzepte entstan-den sind, die auch im Bezug auf das Finden von Assoziationsregeln untersuchtwerden sollten. Folgende Punkte sollen als Anregung gegeben werden:


1. Intensives Einbringen von Wissen in den ProzessDie Wissensrepräsentation im RX–Projekt wurde speziell an die medizini-sche Domäne angepaßt. Die Bildung eines einheitlichen Frameworks zurDarstellung von Wissen wird dann sinnvoll, wenn auch andere Domänenmit dem Verfahren untersucht werden sollen.

2. Produktion ruleszur EntscheidungsunterstutzungDurch die Definition vonproduction ruleskann das System in wichtigenMomenten die optimale Entscheidung treffen. Dabei bleiben diese Ent-scheidungen durch die Regeln transparent und für den Benutzer wartbarund erweiterbar.

3. Kausale Abhangigkeit$ AssoziationsregelDie RX–Implementierung findet explizit kausale Abhängigkeiten, die nichtdirekt mit Assoziationsregeln vergleichbar sind. Hier wäre zu untersuchen,inwieweit die schärferen statistischen Annahmen von kausalen Abhängig-keiten in anderen Domänen Sinn geben.

4. Generierung der Regeln von Anfang anRX generiert ohne Umwege gleich Regeln. Eine Erzeugung von Asso-ziationsregeln mit niedrigem Support und hoher Konfidenz ohne den Um-weg der haufigen Artikelmengen wäre uberlegenswert. Näher zu unter-suchen bliebe, wie die zu erwartende Flut von Regelmöglichkeiten durchDomanenwissen eingegrenzt werden kann.

8

Zusammenfassung und Ausblick

Das letzte Kapitel blickt auf die vorangegangene Arbeit zurück. Es bewertet dieentstandenen Ergebnisse und gibt Anregungen für zukunftige Aufgaben, die inden Rahmen dieser Arbeit fallen.

8.1 Zusammenfassung

Die vorliegende Arbeit untersuchte das Finden von Assoziationsregeln. Begin-nend mit einer Einführung in den KDD Prozess wurden in Kapitel 2 verschiedeneArten von Data Mining Mustern besprochen. So wurden Anwendungsbereichewie auch bekannte Verfahren zur Klassifikation, Clusteranalyse, Regression undsequentielle Muster genannt.

Danach schuf Kapitel 3 die theoretische Grundlage zum Finden von boolschen,generalisierten und quantitativen Assoziationsregeln und stellte unterschiedlicheVerfahren vor. Mit einer Komplexitätsanalyse des Standardverfahrens (APRIORI)schloss das Kapitel.

Zum Zweck einer Anwendungsstudie wurde das Data Mining Werkzeug MI-STRAL implementiert. Kapitel 4 beschrieb, welche Anforderungen an ein DataMining Werkzeug gestellt werden. Darauf folgend wurde erläutert, wie man mitHilfe von Entwurfsmustern diese Anforderungen bei der Realisierung von MI-STRAL verfolgen kann. Zentrale Architekturstellen sind in UML–Notation ge-zeichnet worden.

Davon ausgehend beschrieb Kapitel 5 schließlich die Bedienung des implemen-

101

102 8. Zusammenfassung und Ausblick

tierten MISTRAL Kerns. Es wurde erklärt, wie ein Data Mining Projekt zu de-finieren und durchzuführen ist, ebenso wie das An– und Abkoppeln von neuenMISTRAL Komponenten.

Kapitel 6 prasentierte die Ergebnisse der Anwendungsstudie. Neben syntheti-schen Daten zur Evaluierung von MISTRAL wurden auch reale Daten der FirmenDegussa AG (Katalysatoren) und Quitmann (Bürobedarfsartikel) untersucht. Ei-ne Pflanzenwissensbasis diente als Beispiel für eine diagnostische Domäne. Ei-ne Bewertung der Katalysator–Regeln war zum Zeitpunkt der Drucklegung nichtverfugbar. Die Firma Quitmann zeigte sich zufrieden mit den gefundenen Regelnunduberdenkt Maßnahmen, diese für ihren Geschäftsprozess zu nutzen. Die Er-gebnisse in der diagnostischen Domäne stellten sich als wenig befriedigend her-aus. Als Reaktion darauf wurde ein in Kapitel 7 vorgestelltes Verfahren imple-mentiert und auf die Pflanzenwissensbasis angewendet. Die so erzeugten Regelnwaren erheblich interessanter, da sie eine Reproduktion derjenigen Regeln dar-stellten, welche zuvor zum Aufbau der Wissensbasis gedient hatten.

Kapitel 7 griff die mangelhaften Ergebnisse in der diagnostischen Domäne auf undzeigte verschiedene Lösungsansätze auf, wie interessantere Assoziationsregeln indiagnostischen Domänen gefunden werden könnten.

8.2 Ausblick

Da in dieser Arbeit sowohl an der theoretischen Grundlage von Assoziationsregelnals auch an einer Implementierung eines Data Mining Kerns gearbeitet wurde,muss sich auch der Ausblick in zwei Gebiete teilen:

Der praktische Teil beschäftigte sich ausgiebig mit dem Werkzeug MISTRAL undseinen Komponenten. Bei der Implementierung von MISTRAL wurde in ersterLinie auf Modularitat und Wiederverwendbarkeit geachtet. Die Laufzeit der MI-STRAL Projekte ist aber sicherlich noch zu verbessern. So würde der Austauscheiniger Module (wie etwa der dateiorientierten Speicherverwaltung) durch effizi-entere Klassen die Performanz des Programms erheblich steigern.

Ein Standardverfahren zum Finden von (generalisierten) Assoziationsregeln(CUMULATE) wurde sorgfaltig in Kapitel 6 evaluiert. Das implementierteAPRIORINTERVAL–Verfahren konnte nur im Rahmen der Pflanzenwissensbaisgetestet werden. Von Interesse wäre es, die Güte von APRIORINTERVAL inVerbindung mit anderen diagnostischen Wissensbasen zu evaluieren. Eine Im-plementation des in Kapitel 7 vorgestellten Cluster–Verfahrens könnte hier Ver-

8.2. Ausblick 103

gleichsmoglichkeiten bilden.

Die interessanteste Richtung im theoretischen Zweig beschreibt sicherlich dasFinden von ,,speziellen Assoziationsregeln”, wie sie in Kapitel 7 definiert sind. ImRahmen dieser Diplomarbeit wurden zwei Verfahren angedacht. Die Forschungnach alternativen und effizienteren Algorithmen ist ein erfolgversprechendes Ziel.

Zur schnelleren und einfacheren Implementierung der Assoziationsregel–Verfahren ware eine ,,Assoziationsregel–Hochsprache” von großem Nutzen.Durch eine einheitliche Syntax könnten neue Algorithmen schnell definiert undgetestet werden. Eine effiziente Implementation der Standardbefehle würde zumVorteil aller darin entwickelten Verfahren sein.

Als logische Fortsetzung dieser Idee kann die in Abschnitt 2.3 (Seite 16) vor-geschlagene ,,Data Mining–Hochsprache” gesehen werden. Dieser Punkt scheintmir personlich von großer Bedeutung zu sein: Eine einheitliche Data Mining Spra-che konnte ebenfalls, wie SQL für die Datenbankforschung, einen gewaltigen In-novationsschub leisten. Der Entwurf einer umfassenden Syntax zur Bewältigungvon Data Mining Aufgaben und die Implementation eines entsprechenden Inter-preters/Compilers bedürfte allerdings sicherlich ausgiebiger Studien.

Beschreibung der beigelegten CD–ROM

Auf der beigelegten CD–ROM findet sich im VerzeichnisMistral das ProgrammMISTRAL im Quellcode und in einer vorkompilierten JAR–Datei. Die Dokumen-tation der MISTRAL Klassen liegt im HTML–Format vor.

Ebenso kann die vorliegende Arbeit in verschiedenen Formaten im VerzeichnisDiplomarbeiteingesehen werden.

Die verwendeten Daten der Firmen Quitmann und Degussa AG, sowie die Pflan-zenwissensbasis sind im VerzeichnisDatenvertreten.

Ein aktuelles Inhaltsverzeichnis der CD–ROM gibt die Dateiindex.htmlim Haupt-verzeichnis wieder.

Danksagung

Am Ende angelangt, ist nun der richtige Zeitpunkt gekommen, um mich bei eini-gen Menschen zu bedanken, welche meine Arbeit in den letzten Monaten erheb-lich beeinflusst haben.

Ein Dank geht an Carsten Bange, der die Daten der Firma Quitmann beschaffte,und an Herrn Dr. Jürgen Giesshoff von der Degussa AG. Ebenso bedanken möchteich mich bei Roman Ernst, der mir den Einstieg in die Welt der Pflanzen erheblicherleichterte.

Naturlich soll meinem Betreuer Ioannis ,,The grill–man” Iglezakis gedankt wer-den, welcher auch mal locker nach Dienstschluss fünf Stunden über Data Miningdiskutieren konnte. Auch ANSI–C Dreizeiler gegen 2 Uhr morgens sorgten beieinem Diplomanten mit Mauszeiger–Horizont für Erstaunen. Ebenfalls bedankenmochte ich mich bei Herrn Prof. Frank Puppe, der in seinen ausgiebigen Sprech-stunden viele Ideen und Anregungen gab. Nicht zu vergessen sind Rüdiger ,,rue-dee” Hain, der Besorgungen aller Art tätigte, und selbstverständlich der restlichehumanoide Lehrstuhl–VI–Inventar. Standardgehn?

Hermann Pfanner soll hier auch ein Dankeschön ausgesprochen werden: Trotzdieser wirtschaftlich schwierigen Zeit schafft er es Eistee aus direkt aufgebrühtemTee zu erstellen und nicht, wie die Konkurrenz, billigen Instant–Tee unters Volkzu bringen. So diente sein Tee während der Erstellung dieser Arbeit als magen-schonender Kaffee–Ersatz und erzeugte unverständliches Kopfschütteln in meinerUmgebung. Peach rules!

Ein Dank geht an meine Eltern, die mich während meines Studiums mit allenerdenklichen Dingen unterstützt haben und nie Zweifel an meiner ,,Intelligenz”hegten.

Meiner FreundinK mochte ich zum Schluss einen dicker smile und ein Dan-keschoon fur all die schonen Momente schenken.Nothing heals me like you do.

Literaturverzeichnis

[AIS92] Rakesh Agrawal, Tomasz Imiclinski, and Arun Swami. Databasemining: A performance perspective. Technical report, IBM ResearchDivision, Almaden Research Center, San Jose, CA, USA, 1992.

[AIS93] Rakesh Agrawal, Tomasz Imielinski, and Arun Swami. Mining asso-ciation rules between sets of items in large databases. InProceedingsof the 1993 ACM SIGMOD Conference, 1993.

[AS94a] Rakesh Agrawal and Ramakrishnan Srikant. Fast algorithms for mi-ning association rules. InProceedings of the 20th VLDB Conference,1994.

[AS94b] Rakesh Agrawal and Ramakrishnan Srikant. Fast algorithms for mi-ning association rules. Technical report, IBM Research Division,Almaden Research Center, San Jose, CA, USA, 1994.

[AS94c] Rakesh Agrawal and Ramakrishnan Srikant. Mining sequential pat-terns. InProceedings of the 11th Intl. VLDB Conference, Santiago,Chile, 1994.

[Blu84] Robert L. Blum. Discovery, Confirmation, and Incorporation ofCausal Relationships from a Large Time-Oriented Clinical Data Ba-se: The RX Project, pages 399–425. In [CS84], 1984.

[Bol96] Toni Bollinger. Assoziationsregeln - Analyse eines Data Mining Ver-fahrens. InInformatik 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: Anincremental updating technique. Technical report, The University ofHong Kong, Hong Kong, 1996.

108 Literaturverzeichnis

[CHY96] Ming-Syan Chen, Jiawei Han, and Philip S. Yu. Data Mining: Anoverview from database perspective. 1996.

[CM96] Peter Coad and Mark Mayfield.Java Design. Building better Appsand Applets. Prentice Hall, Upper Saddle River, NJ 07458, USA,1996.

[CS84] William J. Clancey and Edward H. Shortliffe.Readings in MedicalArtificial Intelligence. Addison-Wesley, 1984.

[CS96] Peter Cheeseman and John Stutz.Bayesian Classification (Auto-Class): Theory and Results. In [FPSSU96], 1996.

[Ern96] Roman Ernst. Untersuchung verschiedener Problemlösungs-methoden in einem Experten– und Tutorsystem zur makroskopi-schen Bestimmung krautiger Blütenpflanzen. Master’s thesis, Biolo-gisches Institut, Universität Wurzburg, Deutschland, 1996.

[Fis90] D. H. Fisher.Knowlegde Aquisition via Incremental Conceptual Clu-stering. In [SD90], 1990.

[Fla97] David Flanagan.Java in a Nutshell, Second Edition. O’Reilly, Se-bastopol, CA 95472, USA, 1997.

[FPSSU96] Usama M. Fayyad, Gregory Piatetsky-Shapiro, Padhraic Smyth, andRamasamy Uthurusamy.Advances in Knowledge Discovery and Da-ta Mining. AAAI Press / The MIT Press, Menlo Park, California,1996.

[Fri91] J. H. Friedman. Multivariate Adaptive Regression Splines. InAnnalsof Statistics, 19:1, 1991.

[Gam96] Erich Gamma.Entwurfsmuster: Elemente wiederverwendbarer ob-jektorientierter Software. Addison-Wesley, Bonn, 1996.

[Goo95] Klaus Goos.Fallbasiertes Klassifizieren. Methoden, Integration undEvaluation. PhD thesis, Universität Wurzburg, Deutschland, 1995.

[Han97] Jiawei Han. Data Mining: Where is it heading? InProc. of 1997Intl. Conference on Data Engineering (ICDE ´97), 1997.

[HP96] Jia Liang Han and Ashley W. Plank. Background for association ru-les and cost estimate of selected mining algorithms. Technical report,The University of Southern Queensland, Australia, 1996.

Literaturverzeichnis 109

[HS93] Maurice Houtsma and Arun Swami. Set-oriented mining for asso-ciation rules. Technical report, IBM Research Division, AlmadenResearch Center, San Jose, CA, USA, 1993.

[KMR+94] Mika Klemettinen, Heikki Mannila, Pirjo Ronkainen, Hannu Toi-vonen, and A. Inkeri Verkano. Finding interesting rules from largesets of discovered association rules. Technical report, Department ofComputer 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 approachto Data Mining. InProc. of 21th Intl. Conference on Very Large DataBases, p. 478–489, 1995.

[Man96] Heikki Mannila. Methods and problems in data mining. Techni-cal report, Department of Computer Science, University of Helsinki,1996.

[MAR96] M. Metha, R. Agrawal, and J. Rissanen. SLIQ: A fast scalable classi-fier for Data Mining. InProc. of 1996 Intl. Conference on Extendingdatabase 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. Improvedmethods for finding association rules. Technical report, Departmentof 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 Kauf-mann, 1993.

[Rei94] Y. Reich.Macro and Micro Perspectives of Multiystrategy Learning,pages 379–401. In [Mic94], 1994.

110 Literaturverzeichnis

[SA95] Ramakrishnan Srikant and Rakesh Agrawal. Mining generalized as-sociation rules. Technical report, IBM Research Division, AlmadenResearch Center, San Jose, CA, USA, 1995. Also in Proceedings ofthe 21st VLDB Conference 1995.

[SA96] Ramakrishnan Srikant and Rakesh Agrawal. Mining quantitative as-sociation rules in large relational tables. Technical report, IBM Rese-arch Division, Almaden Research Center, San Jose, CA, USA, 1996.

[SD90] Jude Shavlil and Thomas G. Dietterich.Readings in Machine Lear-ning. Morgan Kaufmann, 1990.

[SON95] Ashok Savasere, Edward Omiecinski, and Shamkant Navathe. Anefficient 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 Ru-les And Sequentiel Patterns. PhD thesis, University of Wisconsin -Madison, 1996.

[ST96] Avi Silberschatz and Alexander Tuzhilin. User-assisted knowledgediscovery: How much should the user be involved. Technical report,Bell Laboratories, Murray Hill, NJ, USA, 1996.

[SVA97] Ramakrishnan Srikant, Quoc Vu, and Rakesh Agrawal. Miningasssocition rules with item constraints. Technical report, IBM Rese-arch Division, Almaden Research Center, San Jose, CA, USA, 1997.

Data Mining Verfahren zum Finden von...

Documents

Transcript of Data Mining Verfahren zum Finden von...