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