Studienarbeit. Maria Soldatova

Transkript

1 Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Fachgebiet Datenbanken und Informationssysteme im Studiengang Mathematik mit Studienrichtung Informatik Diskussion und Implementierung von Varianten des FP-Growth Algorithmus in relationalen Datenbanksystemen Maria Soldatova Matr.-Nr Prüfer: Prof. Dr. Udo Lipeck Betreuer: Dipl.-Math. Christian Stahlhut 28. September 2007

2 Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel verwendet habe. Hannover, den 28. September 2007 Maria Soldatova

3 Danksagung Ich bedanke mich bei Herrn Dipl.-Math. Christian Stahlhut für die hervorragende Betreuung meiner.

4 INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung Motivation Gliederung dieser Arbeit Data Mining und Assoziationsanalyse Aufgaben des Data Mining Assoziationsanalyse Apriori-Algorithmus Assoziationsanalyse ohne Kandidatengenerierung Konstruktion des Frequent-Pattern Tree Mining von frequenten Mustern mit Hilfe des FP-trees Top Down FP-Growth für Frequent Pattern Mining Implementierung Verschiedene Möglichkeiten der SQL-basierten Implementierung Überblick Vorbereitung der Input-Daten Konstruktion des FP-tree Initialisieren der Header-Tabelle Bestimmung der ersten Items Aufbau der Tabelle für die Darstellung des FP-tree Mining des FP-tree Erzeugung von Muster Bestimmung der Pfade Aktualisieren der SIDELINKS-Attribute Bestimmung der Sub-Header-Tabelle Umwandlung der Ergebnisses Anwendung des Algorithmus am Beispiel (MovieDB) Beispiel Beispiel Zusammenfassung 45 Literatur 46 1

5 1 Einleitung 1.1 Motivation Ansammlungen von Daten sind in der heutigen Zeit nicht mehr wegzudenken und sie werden in Zukunft noch eine viel gröÿere Bedeutung einnehmen. Dabei kann es sich um Kundendaten bei Banken und Versicherungen handeln, um die eingekauften Waren im Supermarkt oder um den Datenverkehr im Internet. Überall dort sammeln sich riesige Datenmengen an. Daraus ergibt sich jedoch das Problem der Verarbeitung der Daten. Es müssen Lösungen gefunden werden, diese Masse an Daten beherrschbar zu machen, um für den Benutzer sinnvolle Informationen aus ihnen gewinnen zu können. Genau mit diesem Problem beschäftigt sich das Data Mining im Allgemeinen. Es soll sich in der vorliegenden Arbeit jedoch auf ein Teilgebiet des Data Mining konzentriert werden, und zwar auf die Suche nach häug vorkommenden Elementen in Datenmengen. Dies stellt die wichtigste Grundlage für weitere Schritte der Verarbeitung im Data Mining dar, wie zum Beispiel für die Bildung von Assoziationsregeln. Die Datenanalyse mittels Assoziationsregeln ist eines der am häugsten eingesetzten Data Mining-Verfahren. Am Forschungszentrum der IBM in Almaden, Kalifornien, USA, wurden Anfang der neunziger Jahre Assoziationsregeln als Methode der Abhängigkeitsanalyse eingeführt und erste Algorithmen zur Assoziationsregelgenerierung entwickelt. Der erste veröentlichte eziente Algorithmus zu dieser Thematik stammt von Agrawal mit dem Namen Apriori (AS94). In dieser Arbeit soll zunächst eine kurze Übersicht über diesen Algorithmus und seine Eigenschaften gegeben werden. Der zweite grundlegende Ansatz, der gemacht wurde, stammt von Han et al. und trägt den Namen FP-Growth (HPY00). Dieser Algorithmus und einige Varianten davon werden in dieser Arbeit ausführlich vorgestellt und anhand von Beispielen analysiert. Weiterhin werden einige Möglichkeiten der SQL-basierten Implementierung dieses Algorithmus besprochen und eines der vorgestellten Verfahren auch getestet. 1.2 Gliederung dieser Arbeit Die nachfolgenden Abschnitte sind folgendermaÿen gegliedert. Kapitel 2 erläutert grundlegende Begrie des Data Mining und insbesondere der Assoziationsanalyse. In diesem Kapitel wird der Apriori-Algorithmus als Ausgangspunkt vorgestellt. Kapitel 3 beschreibt eine neue Datenstruktur (den FP-tree), auf der sich der FP- Growth Algorithmus stützt, die Konstruktion dieses Baums und wichtige Eigenschaften des FP-tree. Weiterhin wird der Prozess des Data Mining mit Hilfe von FP-trees beschrieben. Es werden der Algorithmus FP-Growth und die Eigenschaften, die für ihn bedeutend sind, vorgestellt. Am Schluss dieses Kapitels wird eine weitere Variante des Data Mining mit FP-trees vorgestellt, nämlich Top Down FP-Growth. Im Kapitel 4 werden verschiedene Ansätze zur Implementierung des FP-Growth Algorithmus besprochen. Eine Implementierung wird anhand von Beispielen getestet. 2

6 2 Data Mining und Assoziationsanalyse 2.1 Aufgaben des Data Mining Data Mining bezeichnet den Prozess der Identizierung von versteckten und bisher unbekannten, aber interessanten und potentiell nutzbaren Zusammenhängen und Mustern (engl.: patterns) in groÿen Datenmengen, also die Anwendung ezienter Algorithmen, welche die in einer Datenbank enthaltenen gültigen Muster nden (ES00). Die wichtigsten Data Mining Aufgaben werden im Folgenden kurz erläutert: Clustering/Entdecken von Ausreiÿern: Ziel des Clustering ist die Partitionierung einer Datenbank in Gruppen (Cluster) von Objekten, so dass Objekte eines Clusters möglichst ähnlich, Objekte verschiedener Cluster möglichst unähnlich sind. Ausreiÿer sind Objekte, die zu keinem der gefundenen Cluster gehören. Klassikation: Gegeben sind hier Trainingsobjekte mit Attributwerten, die bereits einer Klasse zugeordnet sind. Es soll eine Funktion gelernt werden, die zukünftige Objekte aufgrund ihrer Attributwerte einer der Klassen zuweist. Assoziationsanalyse: Gegeben ist eine Datenbank von Transaktionen. Assoziationsanalyse hilft die häug auftretenden und starken Zusammenhänge innerhalb der Transaktionen zu nden. 2.2 Assoziationsanalyse Das klassische Beispiel für die Anwendung der Assoziationsanalyse ist die sogenannte Warenkorbanalyse. Ein einzelner Warenkorb ist eine Menge von zusammen eingekauften Artikeln, Dienstleistungen oder Informationen eines Anbieters. Gegeben ist dabei eine Datenbank von Warenkörben, die gewisse Kundentransaktionen repräsentieren. Als Beispiel für eine solche Transaktionsdatenbank kann die Sammlung der Daten, die durch die Scannerkassen eines Supermarkts erhoben werden, dienen. Assoziationsregeln drücken Zusammenhänge innerhalb der Transaktionen aus, die in der gesamten Datenmenge häug vorkommen. Im Supermarkt-Beispiel können Zusammenhänge zwischen häug gemeinsam gekauften Artikeln etwa durch Regeln der folgenden Art ausgedrückt werden: (Mehl, Eier) Butter. Diese Regel gilt, wenn in allen Warenkörben, die schon Mehl und Eier enthalten, häug auch noch Butter enthalten ist. Diese Regel wäre natürlich nur dann interessant, wenn genügend viele Warenkörbe sowohl Mehl und Eier als auch Butter enthalten. Das Wissen um solche Zusammenhänge kann auf vielfältige Weise angewendet werden, beispielsweise Cross Marketing, für verbessertes Katalog- Design und Laden-Layout, oder etwa auch für eine automatische Kundensegmentierung anhand von gemeinsamen, durch Assoziationsregeln ausgedrücktem Einkaufsverhalten. Im Folgenden werden die wichtigsten Begrie erläutert: Sei I = {i 1,..., i m } eine Menge von Literalen, genannt Items. Eine Menge von Items X I wird auch Itemset genannt. Typischerweise sind die Items in I Bezeichnungen oder Identikatoren von einzelnen Waren. D sei eine Menge von Transaktionen T, wobei T I. Typischerweise repräsentiert eine Transaktion T einen einzelnen Einkauf oder Warenkorb, und D repräsentiert eine Datenbank, die alle Einkäufe eines Geschäfts in einem bestimmten Zeitraum abspeichert. 3

7 Ein Itemset X, das aus den Items x 1, x 2,..., x k besteht, kann geschrieben werden als X = (x 1, x 2,..., x k ). Die Anzahl der Elemente in einem Itemset heiÿt Länge des Itemsets, und ein Itemset der Länge k heiÿt auch k-itemset. Für eine Menge X I von Items ist der Support der Menge X in D deniert als der prozentualle Anteil der Transaktionen in D, die X enthalten. Der Support einer Menge X ist also die relative Häugkeit, mit der die in X vorkommenden Waren zusammen gekauft wurden. Eine Itemset gilt als frequent, wenn diese den denierten minimalen Support für die Assoziationsregel übersteigt. Eine Assoziationsregel ist eine Implikation der Form X Y, wobei X und Y zwei Itemsets sind, die kein gemeinsames Element haben, das heiÿt es gilt: X I, Y I und X Y =. Der Support s einer Assoziationsregel X Y in D ist der Support der Vereinigung X Y in D, das heiÿt die relative Häugkeit des gemeinsamen Auftretens aller Items oder Waren, die in der Assoziationsregel vorkommen. Die Condence c einer Assoziationsregel X Y in D ist deniert als der prozentualle Anteil der Transaktionen, die die Menge Y enthalten, in der Teilmenge aller Transaktionen aus D, welche die Menge X enthalten. Man kann auch sagen, eine Assoziationsregel X Y gilt mit der Condence c in der Menge D von Transaktionen, wenn c% aller Transaktionen in D, die X enthalten, auch Y enthalten. Die folgende Tabelle illustriert den Support und die Condence einer Assoziationsregel in einer kleinen Beispieldatenbank D. Transaktion gekaufte Items 1 Brot, Kaee, Milch, Kuchen 2 Kaee, Milch, Kuchen 3 Brot, Butter, Kaee, Milch 4 Milch, Kuchen 5 Brot, Kuchen 6 Brot Support von X = {Kaffee, Milch}: 3 von 6 = 50% Support von R = {Kaffee, Kuchen, Milch}: 2 von 6 = 33% Support von Milch, Kaffee Kuchen: = Support(R) = 33% Condence von Milch, Kaffee Kuchen: 2 von 3 = 67% [= Support(R)/Support(X)] Die Assoziationsanalyse wird normalerweise in zwei Phasen aufgeteilt: die erste Phase besteht aus der Bestimmung der frequenten Itemsets in der Datenbank und in der zweiten Phase werden die Assoziationsregeln aus den frequenten Itemsets generiert. Für die Bestimmung der frequenten Itemsets wurden verschiedene Methode entwickelt und einige davon werden in den nächsten Abschnitten beschrieben. 2.3 Apriori-Algorithmus Der Apriori-Algorithmus ist einer der bekanntesten Algorithmen für das Mining von den frequenten Items für Assoziationsregeln und wurde 1994 von R.Agrawal und R.Srikant 4

8 vorgeschlagen (AS94). Der Apriori-Algorithmus basiert auf der folgenden Monotonie- Eigenschaft für frequente Itemsets, die Apriori-Eigenschaft genannt wird: Jede Teilmenge eines frequenten Itemsets muss selbst auch frequent sein. Um diese Eigenschaft auszunutzen, müssen frequente Itemsets der Gröÿe nach bestimmt werden, das heiÿt es müssen zuerst die einelementigen frequenten Itemsets bestimmt werden, dann die zweielementigen usw. Allgemein werden zum Finden von (k+1)-elementigen frequenten Itemsets nur solche (k + 1)-elementigen Teilmengen gezählt, die durch einen Join-Schritt aus k-elementigen Itemsets gebildet werden können, von denen man schon weiÿ, dass sie häug in der Datenbank vorkommen. Der Algorithmus durchläuft mehrmals die Datenmenge, solange bis bei einer bestimmten Länge keine frequenten Itemsets mehr gefunden werden können. L k bezeichnet dabei die Menge aller häug vorkommenden Itemsets der Länge k, und C k bezeichnet die zu zählenden Kandidaten-Itemsets der Länge k. Im ersten Schritt werden die einelementigen Itemsets bestimmt, die minimalen Support haben. In allen folgenden Durchläufen werden aus den im jeweils vorhergehenden Durchlauf bestimmten frequenten Itemsets (mit k 1 Elementen) neue Kandidaten-Itemsets (mit k Elementen) gebildet. Der Support dieser Kandidaten wird gezählt, indem für jede Transaktion T in der Datenbank geprüft wird, welche der aktuellen Kandidaten in T enthalten sind. Anschlieÿend werden aus den Kandidaten diejenigen Itemsets für den nächsten Durchlauf ausgewählt, die minimalen Support haben. Dies sind gleichzeitig die frequenten Itemsets der Länge k. Die Kandidatengenerierung ist das Kernstück des Apriori-Algorithmus. Die Kandidaten der Länge k + 1 werden in zwei Schritten gebildet, wobei vorausgesetzt wird, dass die Items in den Itemsets lexikographisch sortiert sind. Im ersten Schritt (Join) wird ein Join der k-elementigen frequenten Itemsets mit sich selbst durchgeführt. Dabei wird jedes k-elementige frequente Itemset p jeweils um das letzte Item aller k-elementigen frequenten Itemsets q verlängert, welche mit p in den ersten k 1 Items übereinstimmen. Im zweiten Schritt (Pruning) werden aus der Menge der im Join-Schritt generierten Kandidaten alle Itemsets entfernt, welche eine k 1-elementige Teilmenge enthalten, die nicht in der Menge der (k 1)-elementigen frequenten Itemsets vorkommt. Die folgenden Tabellen illustrieren den Ablauf des Apriori-Algorithmus mit dem minimalen Support 40% oder absoluten minimalen Support 1,6. Datenbank D C1 L1 Trans-ID Items Itemset Sup. Itemset Sup. 100 A C D (A) 2 (A) B C E DB- (B) 3 (B) A B C E Skan. (C) 3 (C) B E (D) 1 (E) 3 (E) 3 5

9 C2 C2 L2 Itemset Sup. Itemset Sup. Itemset Sup. (A B) (A B) 1 (A C) 2 (A C) DB- (A C) 2 (B C) 2 (A E) Skan. (A E) 1 (B E) 3 (B C) (B C) 2 (C E) 2 (B E) (B E) 3 (C E) (C E) 2 C3 C3 L3 Itemset Sup. DB- Itemset Sup. Itemset Sup. (B C E) Skan. (B C E) 2 (B C E) 2 Im Folgenden wird der Pseudo-Code des Algorithmus vorgestellt und erläutert (Han05). Zeile 1 des Apriori-Algorithmus ndet L 1 - frequente 1-Itemsets. In den Zeilen 2-12 wird L k 1 für k 2 benutzt um Kandidaten C k zu generieren um L k zu nden. Die Kandidaten werden in der Zeile 3 generiert. Wenn alle Kandidaten generiert wurden, wird die Datenbank durchlaufen (Zeile 4). Für jede Transaktion wird eine Funktion benutzt, um alle Teilmengen der Transaktion zu nden, die in Frage kommen (Zeile 5), 6

10 und der Zähler wird für jeden der Kandidaten erhöht (Zeile 6, 7 und 8). Anschlieÿend bilden alle Kandidaten, die den minimalen Support haben (Zeile 11), die Menge L von frequenten Itemsets (Zeile 13). 7

11 3 Assoziationsanalyse ohne Kandidatengenerierung In den meisten Fallen hat der Apriori-Algorithmus eine gute Performance, die durch das Reduzieren der Gröÿe der Kandidatenmengen zustande kommt. Aber es gibt Situationen, z.b. bei groÿer Anzahl von Mustern, bei langen Mustern oder bei kleinem minimalem Support, in denen der Apriori-Algorithmus enormen Aufwand hat (HPY00): Es kann nötig sein eine enorme Anzahl von Kandidatenmengen zu generieren; z.b. wenn es 10 4 frequente 1-Itemsets gibt, dann muss der Algorithmus mehr als Kandidaten generieren. Auÿerdem braucht er mindestens Kandidaten, um ein frequentes Muster der Länge 100 zu nden. Es kann nötig sein, die Datenbank mehrmals zu durchlaufen und groÿe Kandidatenmengen zu prüfen, aber es kostet sehr viel Aufwand, jede Transaktion in der Datenbank zu prüfen, um den Support der Kandidaten-Itemsets zu bestimmen. Um diese Probleme zu beheben, wurde ein Algorithmus entwickelt, der in diesem Kapitel vorgestellt wird. Dieser Algorithmus heiÿt Frequent-Pattern Growth oder FP-Growth und stützt sich auf einen divide and conquer Ansatz: Die Datenbank wird in mehrere kleinere Datenbanken aufgeteilt und anschlieÿend wird für jede dieser Datenbanken das Mining durchgeführt. Der Algorithmus vermeidet bei dem Mining der frequenten Itemsets die aufwändige Kandidatengenerierung und wandelt die Transaktions-DB in eine komprimierte Form - einen Baum um, den sog. Frequent-Pattern Tree oder FP-tree, was den Vorteil hat, dass die Datenbank nicht mehrmals durchsucht werden muss. 3.1 Konstruktion des Frequent-Pattern Tree Für den FP-Growth Algorithmus muss zuerst eine neue Datenstruktur, nämlich der FP-tree, ausgehend von folgenden Beobachtungen deniert werden: Es ist notwendig, die Transaktions-DB einmal zu durchsuchen, um die Menge von frequenten Items zu bestimmen. Die Transaktions-DB muss nur einmal durchsucht werden, wenn die Menge von frequenten Items für jede Transaktion in einer kompakten Datenstruktur gespeichert werden kann. Wenn einige Transaktionen gleiche Teilmengen von frequenten Items besitzen, ist es möglich diese Teilmengen gemeinsam zu speichern. Es ist leichter zu prüfen ob zwei Mengen identisch sind, wenn die frequenten Items in bestimmter Reihenfolge sortiert sind; zum Beispiel wenn die frequenten Items in der absteigenden Häugkeit des Auftretens sortiert sind. Basierend auf diesen Beobachtungen kann diese Datenstruktur folgendermaÿen deniert werden: 8

12 1. Sie enthält einen Baum, der eine leere Wurzel, eine Menge von item-prex Teilbäumen (von der Wurzel ausgehende Teilbäume) und eine frequent-item-header Tabelle hat. In der frequent-item-header Tabelle wird ein Zeiger auf das erste Auftreten jedes Items in dem Baum gespeichert. 2. Jeder Knoten in einem item-prex Teilbaum besteht aus drei Feldern: item-name, count und node-link, wobei item-name den Namen des Items enthält, count die Anzahl der Transaktionen, die Items aus den zu diesem Knoten führenden Pfad enthalten und node-link einen Zeiger auf den nächsten Knoten mit dem gleichen item-name, wenn es solche gibt. 3. Jede Zeile in der frequent-item-header Tabelle hat folgende zwei Felder: itemname - Name des Items - und head of node-link - Zeiger auf den ersten (in der Reihenfolge des Einfügens der Transaktionen in den Baum) Knoten in dem FP-tree mit demselben item-name. Der FP-tree wird wie folgt konstruiert: im ersten Durchlauf der Transaktions-DB werden die frequenten 1-Itemsets bestimmt; die frequenten Items werden danach absteigend nach der Häugkeit ihres Auftretens sortiert; die Transaktions-DB wird erneut durchlaufen und der FP-tree aufgebaut. Folgendes Beispiel illustriert die Konstruktion des FP-tree. Sei folgende Transaktions-DB gegeben mit dem minimalen Support gleich 3: TID Gekaufte Items (Sortierte) frequente Items 100 f, a, c, d, g, i, m, p f, c, a, m, p 200 a, b, c, f, l, m, o f, c, a, b, m 300 b, f, h, j, o f, b 400 b, c, k, s, p c, b, p 500 a, f, c, e, l, p, m, n f, c, a, m,p Im ersten Durchlauf der Transaktions-DB werden die frequenten Items bestimmt, die sich jetzt in der rechten Spalte der Tabelle benden. Die Häugkeit des Auftretens (Support) jedes Items wird gezählt, mit dem minimalen Support verglichen und 9

13 die Liste der frequenten Items wird absteigend nach dem Support des Items sortiert: (f : 4), (c : 4), (a : 3), (b : 3), (m : 3), (p : 3). Die Reihenfolge dieser sortierten Liste legt die Reihenfolge der Knoten beim Einfügen der Transaktionen in den zu konstruierenden Baum fest. Als Nächstes wird eine leere Wurzel des Baums erstellt. Beim zweiten Durchlauf lässt sich aus der ersten Transaktion der erste Ast des Baums konstruieren: (f : 1), (c : 1), (a : 1), (m : 1), (p : 1). Die Reihenfolge der Knoten entspricht der Reihenfolge der sortierten Liste der frequenten Items. Die zweite Transaktion hat den gemeinsamen Präx f, c, a mit dem schon existierenden Pfad, deshalb wird der Zähler (count) für jeden Knoten in diesem Präx um eins erhöht und es werden die neuen Knoten (b : 1) als Kind-Knoten von (a : 2) und (m : 1) als Kind-Knoten von (b : 1) erstellt. Ähnlich in der dritten Transaktion wird der Zähler von Knoten f um eins erhöht und ein neuer Knoten (b : 1) als Kind-Knoten von (f : 3) erstellt. Die vierte Transaktion liefert den zweiten Ast des Baums: (c : 1), (b : 1), (p : 1). Die letze Transaktion ist identisch mit der ersten, deshalb werden die Zähler für die entsprechenden Knoten inkrementiert. Am Ende ergibt sich der oben angegebene FP-tree. Es kann jetzt der Ablauf der Konstruktion des FP-tree vorgestellt werden: 1. Durchlaufe einmal die Datenbank DB. Sammle F, eine Menge von frequenten Items und den Support von jedem frequenten Item auf. Sortiere F absteigend nach dem Support. Sei FList eine Liste dieser sortierten Items. 2. Erstelle die Wurzel R des Baums. 3. Für jede Transaktion Trans in DB: Wähle frequente Items aus Trans und sortiere sie in der Reihenfolge der Liste FList. Diese sortierte Elementen aus Trans sind von der Form [p P], wobei p der erste Element aus Trans und P die restliche Liste ist. Rufe insert_tree([p P ], R) auf. Die Funktion insert_tree([p P ], R) geht folgendermaÿen vor: Wenn R ein Kind N mit N.item-name = p.item-name hat, dann inkrementiere den Zähler von N. Sonst erstelle einen neuen Knoten N - als Kind-Knoten von R - mit dem Zähler 1 und dem node- Link zu den Knoten mit dem gleichen item-name. Wenn P nicht leer ist, dann rufe insert_tree(p,n) rekursiv auf. 10

14 3.2 Mining von frequenten Mustern mit Hilfe des FP-trees In diesem Abschnitt wird die oben beschriebene Datenstruktur FP-tree benutzt, um das Mining von frequenten Muster durchzuführen; es wird ein rekursiver Mining Algorithmus mit FP-trees vorgestellt. Anschlieÿend werden einige wichtige Eigenschaften des FP-tree dargestellt und anhand von Beispielen erläutert. Um die Vorgehensweise des Mining Algorithmus leichter zu verstehen, nehmen wir an, dass der FP-tree nur einen Pfad enthält. Jetzt können alle frequenten Muster durch die Aufzählung aller Kombinationen von Items bestimmt werden und der Support ist dann der kleinste Support eines in einer Kombination enthalteten Items. Solche Typen von FP-Bäumen heiÿen Single prex path FP-tree. Ein Single prex path FP-tree ist ein FP-tree, der einen einzigen Pfad von der Wurzel bis zum ersten verzweigenden Knoten (branching node) enthält, wobei ein verzweigender Knoten ein Knoten mit zwei oder mehr Kindern ist; zum Beispiel: Das ist ein single prex path FP-tree, der einen Präxpfad (a : 10) (b : 8) (c : 7) von der Wurzel bis zum verzweigenden Knoten (c : 7) hat. Um das Mining durchzuführen, wird dieser Baum in zwei Teile aufgeteilt: single prex path Teil P (a : 10) (b : 8) (c : 7) und multipath Teil Q, wobei die Wurzel des multipath Teils Q durch eine Pseudowurzel R ersetzt wird. Für diese zwei Teile kann das Mining getrennt durchgeführt werden und danach können die Ergebnisse des Mining zusammengeführt werden. 11

15 Alle frequenten Muster, die mit dem single prex path Teil P in Frage kommen, können durch die Aufzählung aller Kombinationen von Items in P gefunden werden. Also liefert der Pfad P folgende Menge von frequenten Mustern: freq_pattern_set(p) = {(a : 10), (b : 8), (c : 7), (ab : 8), (ac : 7), (bc : 7), (abc : 7)}. Das Mining des zweiten multipath Teils Q führt zu folgendem Ergebnis: freq_pattern_set(q) = {(d : 4), (e : 3), (f : 3), (df : 3)}. Aber jedes frequente Itemset in Q bildet auch noch mit jedem Muster aus P verschiedene frequente Muster, zum Beispiel: (d : 4) freq_pattern_set(p) = {(ad : 4), (bd : 4), (cd : 4), (abd : 4), (acd : 4), (bcd : 4), (abcd : 4)}, wobei das -Produkt wie folgt deniert sei: Seien zwei beliebige Mengen R = {a 1 : sa 1, a 2 : sa 2,..., a n : sa n } und S = {b 1 : sb 1, b 2 : sb 2,..., b m : sb m } gegeben, wobei sa i der Support des Itemsets a i und sb i der Support des Itemsets b i ist. Dann ist R S= {a 1 : sa 1, a 2 : sa 2,..., a n : sa n } {b 1 : sb 1, b 2 : sb 2,..., b m : sb m } = {a 1 b 1 : min(sa 1, sb 1 ), a 1 b 2 : min(sa 1, sb 2 ),..., a 1 b m : min(sa 1, sb m ),..., a n b 1 : min(sa n, sb 1 ), a n b 2 : min(sa n, sb 2 ),..., a n b m : min(sa n, sb m )}. Der minimale Support des Ergebnisses wird immer dem minimalen Support des Itemsets aus Q (in dem Beispiel Item d mit dem Support 4) entsprechen, weil die Liste der frequenten Items nach dem Support absteigend sortiert ist und die Items in dieser Reihenfolge aus den Transaktionen in den Baum eingefügt werden, d.h. dass die Items in Q immer den kleineren Support haben als die Items in P. Ähnlich wird mit jedem frequenten Itemset aus Q solange weitergemacht, bis alle Itemsets aus Q berücksichtigt worden sind. Die komplette Menge der frequenten Muster, die durch Zusammenfassen der Ergebnisse von P und Q gewonnen wird, ist also freq_pattern_set(p) freq_pattern_set(q) mit dem Support von Itemsets aus Q. Allgemein sei T ein FP-tree, der einen single prex path Teil P und multipath Teil Q enthält. Dann besteht die komplette Menge der frequenten Muster von T aus folgenden drei Teilen: 1. Die Menge der frequenten Muster aus P, die durch die Aufzählung aller Kombinationen der Items von P erhalten wird. 2. Die Menge der frequenten Muster aus Q. 3. Die Menge der frequenten Muster aus der Zusammenfassung von P und Q, die 12

16 durch das -Produkt der frequenten Muster aus P und Q unter Einschränkung des minimalen Supports erhalten ist (freq_pattern_set(p) freq_pattern_set(q)). Wie die frequenten Muster aus Q bestimmt werden können, wird im Folgenden erläutert, aber vorher müssen noch einige Eigenschaften des FP-tree erötert werden. Eine davon ist die Node-link Eigenschaft. Node-link Eigenschaft : Für ein beliebiges frequentes Item a i können alle möglichen frequenten Itemsets, die a i enthalten, durch das Folgen der node-links von a i erhalten werden. Es wird mit dem node-link von a i in der FP-tree Header Tabelle angefangen. Zum Beispiel für das Item p ergeben sich zwei Pfade: f : 4, c : 3, a : 3, m : 2, p : 2 und c : 1, b : 1, p : 1. Durch das Verfolgen der Knoten entlang die Pfade und Akkumulieren deren Zähler ergibt sich, dass frequent somit ist: c : 3, p : 3. Alle möglichen frequenten Itemsets: p, cp. Eine weitere Eigenschaft des FP-tree, die für das Mining besonders wichtig ist, ist die Präxpfad-Eigenschaft. Präxpfad-Eigenschaft : Zur Bestimmung der frequenten Muster für einen Knoten a i im Pfad P müssen nur die Präxpfade des Knoten a i in P gesammelt werden. Die Häugkeit der Knoten in den Präxpfaden wird mit der Häugkeit des Knotens a i abgeglichen. Die Knoten aus dem Pfad P, die tiefer als der Knoten a i in dem Baum stehen, müssen nicht berücksichtigt werden, weil die frequenten Muster für diese Knoten zu diesem Zeitpunkt schon ermittelt worden sein sollen. Eine Menge solcher Präxpfaden des Knotens a i bildet eine kleine Datenbank der Mustern, die zusammen mit a i auftreten. Eine solche Datenbank der Muster, die zusammen mit a i auftreten, heiÿt conditional pattern-base von a i und wird als pattern_base a i bezeichnet. Diese Präxpfade kann man wiederum als Menge von Transaktionen betrachten. Mit einem vorgegebenen Support aus diesen conditional pattern-bases von a i wird ein kleiner FP-tree gebildet, der conditional FP-tree von a i heiÿt und als FP-tree a i bezeichnet wird. Zum Beispiel wäre für das Item p der conditional FP-tree {(c : 3)} p. Basierend auf den oben beschriebenen Eigenschaften kann das Mining wie folgt durchgeführt werden: 13

17 1. Bestimme die frequenten 1-Items in der Transaktions-DB und erstelle für jedes Item seine conditional pattern-base. 2. Aus den conditional pattern-bases bilde die entsprechenden conditional FP-trees. 3. Führe das Mining in den conditional FP-trees rekursiv durch und füge die Ergebnisse in die Menge der bisher gefundenen frequenten Items ein. Dieser Mining Prozess wird jetzt an einem Beispiel ausführlicher erläutert. 1. Bestimmung der conditional pattern-base für jedes Item: Für jedes Item a i folge dem node-link aus der frequent-item-header Tabelle um den ersten Knoten mit diesem Item zu bestimmen. Folge den Pfad von dem Knoten a i bis zur Wurzel über die Kanten und den node-link von diesem Knoten bis zum anderen mit dem gleichen Namen. Sammle transformierte Präxpfade und erstelle für jedes Item seine conditional pattern-base. Item p m b a c f Conditional pattern-base {(fcam:2), (cb:1)} {(fca:2), (fcab:1)} {(fca:1), (f:1), (c:1)} {(fc:3)} {(f:3)} 2. Erstellung der entsprechenden conditional FP-trees: wie schon oben erläutert wurde, können die Präxpfade aus conditional pattern-bases wiederum als Transaktionen betrachtet werden. Zum Beispiel für das Item a: {(f, c), (f, c), (f, c)} f : 3, c : 3. Der Prozess der Konstruktion der conditional FP-trees erfolgt dann nach dem schon bekannten Algorithmus der Konstruktion des FP-tree. Für jedes Item a i zähle die Summen der counts der Knoten mit diesem Item auf und sortiere die Items nach dieser Häugkeit absteigend. 14

18 Für die Items erstelle die conditional FP-trees, welche hier alle Single prex path FP-trees sind. Item Conditional pattern-base Conditional FP-tree p {(fcam:2), (cb:1)} {(c:3)} p m {(fca:2), (fcab:1)} {(f:3, c:3, a:3)} m b {(fca:1), (f:1), (c:1)} a {(fc:3)} {(f:3, c:3)} a c {(f:3)} {(f:3)} c f 3. Rekursives Mining in den conditional FP-trees: Erstelle für jedes Item die conditional pattern-base und die conditional FPtree und führe diesen Schritt für jeden conditional FP-tree rekursiv durch (Ergebnis bezeichne als Menge Q). Dieses Vorgehen setzt sich rekursiv fort, bis ein FP-tree entsteht, der nur einen Pfad enthält, aus dem man dann die darin enthaltenen frequenten Itemsets (Menge P) direkt durch die Aufzählung aller Kombinationen der Items ermitteln kann. Das passiert immer, weil sich die Menge der Items in den conditional FP-trees mit jedem rekursiven Aufruf verkleinert. Wie oben schon erläutert wurde ist dann das endgültige Ergebnis: P Q (P Q). Item p m a c frequente Itemsets cp am, cm, fm, cam, fam, fcam, fcm fa, ca, fca fc Jetzt kann der Pseudocode des FP-Growth Algorithmus vorgestellt werden. 15

19 In diesem Abschnitt wurden die Konstruktion des FP-tree und die Arbeitsweise des FP- Growth Algorithmus vorgestellt. Es lassen sich folgende wichtige Vorteile des FP-tree kurz zusammenfassen: Kompaktheit wird durch die absteigende Sortierung des frequenten Items ermöglicht: die am häugsten auftretenen Items werden mit der gröÿeren Wahrscheinlichkeit gemeinsam benutzt und sie sind also näher an der Wurzel des Baums platziert. Vollständigkeit wird durch den Prozess der Konstruktion des FP-tree ermöglicht: die frequenten Items aus jeder Transaktion aus der DB werden in einen Pfad in dem Baum umgewandelt und somit enthält der FP-tree nach der Konstruktion die vollständige Information für das Mining. Laut der Studie die von J. Han et al. geleitet wurde ist der FP-Growth Algorithmus deutlich schneller als die Apriori-basierten Methoden. Besonders auällig sind die Unterschiede wenn die Datenmengen lange Muster enthalten (HPY00). Als Gründe dafür sind folgende Vorteile des FP-Growth Algorithmus zu nennen: keine Kandidatengenerierung und Kandidatentests. kein wiederholter Durchlauf der Datenbank. Zerlegen der Mining-Aufgaben laut divide-and-conquer Ansatz. kompakte und vollständige Datenstruktur. 16

20 3.3 Top Down FP-Growth für Frequent Pattern Mining In diesem Abschnitt wird der Top Down FP-Growth (TD-FP-Growth) Algorithmus vorgestellt, der von Tang (WTHL02) vorgeschlagen wurde und für das Mining der frequenten Mustern benutzt wird. Dieser Algorithmus durchläuft den FP-tree top-down, von oben nach unten, wobei das oben erläuterte Verfahren den FP-tree bottom-up, von unten nach oben durchsucht. Der Vorteil dieses Algorithmus besteht darin, dass die Konstruktion der conditional pattern-bases und der zugehörigen conditional FP-trees dadurch vermieden wird und somit Zeit und Speicher gespart werden. Zuerst wird wie auch bei dem originalen FP-Growth ein FP-tree konstruiert. Das geschieht in zwei Durchläufe der Transaktionsdatenbank. Beim ersten Durchlauf werden die Zähler für jedes Item bestimmt und beim zweiten wird der FP-tree erstellt. Der Prozess der Konstruktion des FP-tree unterscheidet sich nicht von dem entsprechenden Prozess im originalen FP-Growth Algorithmus. Es existiert auch eine frequent-itemheader-tabelle, wo die Items mit den Zähler und node-links gespeichert werden. Das folgende Beispiel erklärt die grundlegende Idee des TD-FP-Growth Algorithmus. Sei folgende Transaktionsdatenbank gegeben mit dem minimalen Support gleich 2: TID Items 1 a, b, c, e 2 b, e 3 b, c, e 4 a, c, d 5 a Mit dem Algorithmus für die Konstruktion des FP-tree lassen sich die folgenden FP-tree und frequent-item-header-tabelle erstellen. Der Mining Prozess beginnt am Anfang der frequent-item-header-tabelle, in dem Beispiel ist das Item a. Das Item a ist frequent und es lässt sich durch das Verfolgen des node-links des Items a zeigen, dass Item a nur auf einer Ebene des Baums erscheint. 17

21 Deshalb wird nur {a} als ein frequentes Muster ausgegeben. Für das nächste Item b aus der frequent-item-header-tabelle werden zwei Knoten durch das Verfolgen des node-links des Item b gefunden: b : 2, b : 1. Von diesen Knoten aus wird der Pfad bis zur Wurzel entlang gegangen und werden die Zähler für die Knoten in diesen Pfad akkumuliert. Die Knoten entlang dieser Pfade bilden eine sog. Sub-header-Tabelle H_x für den aktuell bearbeiteten Eintrag x. Für den Knoten b existieren zwei Pfade: root b und root a b. Aus dem ersten Pfad werden keine weiteren Knoten bestimmt. Aus dem zweiten Pfad ergibt sich der Knoten a mit dem akkumulierten Zähler 1, weil der Pfad root a b nur einmal in der Transaktionsdatenbank vorkommt. Deshalb wird in der Sub-header- Tabelle H_b ein Eintrag mit dem Item a erstellt. Der minimale Support ist 2, deshalb ist das Muster {a, b}, das nur einmal in der Transaktionsdatenbank vorkommt, nicht frequent. Wenn das Muster {a, b} frequent wäre, würde das Verfahren mit der Konstruktion der Sub-header-Tabelle H_ab rekursiv fortgesetzt. Allgemein, wenn der Eintrag I aus der Sub-header-Tabelle H_x gerade bearbeitet wird, wird das Mining für alle frequenten Muster durchgeführt, die auf Ix enden. Auf diese 18

22 Weise ndet der TD-FP-Growth Algorithmus alle frequenten Muster. Für den Eintrag c existieren dann drei Pfade bis zur Wurzel: root b c, root a b c und root a c. Die Knoten entlang dieser Pfade bilden die Sub-header-Tabelle H_c. Aus den Pfaden ergeben sich zwei Knoten a und b mit den akkumulierten Zähler 2. Das Verfahren wird rekursiv fortgesetzt und die frequenten Muster für den Eintrag c sind {c}, {b, c} und {a, c}. Analog sind für den Eintrag e {e}, {b, e}, {c, e} und {b, c, e} die frequenten Muster. Im Unterschied zu dem FP-Growth Algorithmus bearbeitet der TD-FP-Growth Algorithmus zuerst die Knoten auf den oberen Ebenen des Baums. Das ist wichtig, weil so sichergestellt wird, dass Aktualisieren der Zähler auf den oberen Ebenen keinen Einuÿ auf die unteren Ebenen hat. Zu dem Zeitpunkt, als die unteren Ebenen bearbeitet werden, wurden die oberen schon bearbeitet. Um die conditional pattern-base für ein Muster zu erstellen, wird einfach entlang der Pfade bis zur Wurzel gegangen und es werden die Zähler für die Knoten in den Pfaden akkumuliert. Auf diese Weise werden die Zähler in place aktualisiert und es werden keine conditional pattern-bases und conditional FPtrees während des gesamten Mining Prozess gebraucht. Dies ergibt einen groÿen Vorteil im Vergleich zu dem bottom-up FP-Growth, was auch experimentell bestätigt wurde (WTHL02). 19

23 4 Implementierung 4.1 Verschiedene Möglichkeiten der SQL-basierten Implementierung Es gibt einige Varianten wie man den FP-Growth Algorithmus in einem relationalen Datenbanksystem mit SQL implementieren könnte. In allen Methoden, die in diesem Abschnitt vorgestellt werden, wird der FP-tree als eine Tabelle dargestellt. Zuerst ist es wichtig zu bestimmen, in welcher Form die Eingabe für den Algorithmus erfolgt. Dafür gibt es zwei Schemata. Erstens kann als Input die Transaktionsdatenbank vorgegeben sein, eine Tabelle T mit zwei Spalten: Transaktions-ID (tid) und Item-ID (item). Für eine bestimmte tid kann es mehrere Zeilen mit den unterschiedlichen Items in der Transaktionsdatenbank geben. Die Anzahl der Items pro Transaktion ist variabel und unbekannt zum Zeitpunkt der Konstruktion der Tabelle. Das Schema dieser Tabelle ist folgendermaÿen deniert: Spaltenname tid item Bedeutung ID der Transaktion ID des Items Als Alternative kann auch eine Input-Tabelle mit dem folgenden Schema benutzt werden: (tid, item 1, item 2,..., item k ), wobei die Spalte item i das i-te Item der Transaktion enthält. Als eine weitere Alternative kann auch eine Input-Tabelle mit dem folgenen Schema benutzt werden: (tid, item 1, item 2,..., item k ), wobei die Spalte item i ein binäres Attribut enthält, das zeigt, ob das i-te Item in dieser Transaktion vorkommt. Folgendes Beispiel illustriert diese unterschiedlichen Input-Tabellen. Tid Item Tid Item1 Item2 Item3 Item4 1 a 1 a b c d 1 b 2 c d 1 c 3 a d e 1 d 2 c Tid a b c d e 2 d 1 ja ja ja ja nein 3 a 2 nein nein ja ja nein 3 d 3 ja nein nein ja ja 3 e Aber die letzten beiden Tabellenschemata sind in manchen Situationen eher unpraktisch: Die Anzahl der Items pro Transaktion kann gröÿer als die maximale von der Datenbank unterstützte Anzahl der Spalten sein. Wenn die Anzahl der Items pro Transaktion ungleichmäÿig verteilt ist, führt das möglicherweise zu Platzverschwendung. Es wird deshalb die Tabelle mit zwei Spalten für Transaktions-ID und Item-ID als Inputformat benutzt. 20

24 Variante 1 Als erstes wird der sog. FP-Ansatz (Frequent Pattern Ansatz) (SSG04) erläutert. Ein FP-tree wird wegen seiner Eigenschaften durch eine Tabelle FP repräsentiert, die drei Spalten hat: Item-ID (item); Präxpfad des Items (path); Anzahl der Transaktionen, welche die Items in dem Pfad enthalten (count). Das Schema dieser Tabelle sieht folgendermaÿen aus: Spaltenname item count path Bedeutung ID des Items Anzahl der Transaktionen Präxpfad des Items Das Feld path ist nicht nur für die Konstruktion der FP Tabelle, sondern auch für das Suchen nach den frequenten Mustern in FP sehr vorteilhaft. In der Konstruktion der FP Tabelle ist das Feld path das wichtigste Kriterium um zu entscheiden, ob das Item in die Tabelle eingefügt werden muss. Wenn das Item in der FP Tabelle nicht existiert oder es existieren die gleichen Items aber mit verschiedenen paths, dann muss das Item in die Tabelle eingefügt werden. Sonst wird einfach der Zähler des Items inkrementiert (count). Während des Mining müssen conditional FP-trees und die ihn repräsentierende Tabelle ConFP für jedes Item rekursiv erstellt werden. Mit Hilfe der Spalte path in der FP Tabelle ist es leicht alle Items zu nden, die zusammen mit dem zu untersuchenden Item auftreten. Die FP Tabelle kann folgendermaÿen konstruiert werden: Sortiere die Items aus der Inputtabelle T absteigend nach der Häugkeit ihres Auftretens. Für die erste Transaktion füge alle frequenten Items in die FP Tabelle ein und setze count jeweils auf 1. Der path des ersten Items a 1 wird auf null gesetzt, der path des zweiten Items wird auf null:a 1 gesetzt usw. Für jedes frequente Item aus der zweiten Transaktion prüfe, ob das Item in die Tabelle eingefügt werden muss oder der Zähler des Items inkrementiert werden muss. Für die restlichen Transaktionen wird es genauso weiter gemacht. 21

25 Als Beispiel kann die folgende Transaktionstabelle (mit dem minimalen Support 3) benutzt werden: TID Items Frequente Items 1 a, c, d, f, g, i, m, o c, f, a, m, o 2 a, b, c, f, l, m, n c, f, a, b, m 3 b, f, h, j, n f, b 4 b, c, k, o c, b, o 5 a, c, e, f, l, m, o c, f, a, m, o 22

26 Dann wird die folgende FP Tabelle erhalten: Item Count Path c 4 null f 3 null : c a 3 null: c : f m 2 null : c : f : a o 2 null : c : f : a : m b 1 null : c : f : a m 1 null : c : f : a : b f 1 null b 1 null : f b 1 null : c o 1 null : c : b Nach der Konstruktion der FP Tabelle kann diese Tabelle jetzt für das eziente Mining der frequenten Items benutzt werden. Für jedes frequente Item i wird die conditional pattern base Tabelle P B i konstruiert, die drei Spalten: tid, item, count hat. Das Schema dieser Tabelle wird folgendermaÿen dargestellt: Spaltenname tid item count Bedeutung ID der Transaktion ID des Items Anzahl der Transaktionen Daraus kann die conditional FP-tree Tabelle ConF P i erstellt werden, die das gleiche Schema hat wie die FP Tabelle, nämlich item, count, path. Die Konstruktion der ConF P i Tabelle erfolgt nach demselben Algorithmus wie die Tabelle FP. Das Mining wird gemäÿ des FP-Growth Algorithmus rekursiv in der Tabelle ConF P i durchgeführt. Laut der Studie (SSG04) des FP-Ansatzes wurde festgestellt, dass die Prozedur der Konstruktion der FP Tabelle am zeitaufwändigsten ist. Der wichtigste Grund dafür ist, dass die frequenten Items aus jeder Transaktion nacheinander geprüft werden sollen um zu entscheiden ob sie in die Tabelle eingefügt werden müssen. 23

27 Variante 2 Deshalb wird als nächstes der sog. EFP-Ansatz (extended Frequent Pattern Ansatz) (SSG04) vorgestellt, wo versucht wird die Performance des FP-Ansatzes zu verbessern. Der Unterschied zwischen den zwei Ansätzen besteht in dem Prozess der Konstruktion der FP Tabelle. In dem EFP-Ansatz wird dazu die Tabelle EFP benutzt, die zwei Spalten hat: item und path. Spaltenname item path Bedeutung ID des Items Präxpfad des Items Die EFP Tabelle kann direkt durch die Transformation der frequenten Items aus der Input-Tabelle erhalten werden ohne die Items nacheinander zu prüfen. Zuerst wird der path des ersten frequenten Item i 1 jeder Transaktion auf null gesetzt. Der path des zweiten frequenten Item i 2 wird weiter mit null:i 1 initialisiert, der path des dritten - mit null:i 1 :i 2 usw. Um die FP Tabelle daraus zu bekommen, werden die Items mit den gleichen paths zusammengefasst. Das kann mit der folgenden SQL-Anweisung erfolgen: insert into FP select item, count(*) as count, path from EFP group by item, path Als Beispiel kann wiederum die folgende Transaktionstabelle (mit dem minimalen Support 3) benutzt werden: TID Items Frequente Items 1 a, c, d, f, g, i, m, o c, f, a, m, o 2 a, b, c, f, l, m, n c, f, a, b, m 3 b, f, h, j, n f, b 4 b, c, k, o c, b, o 5 a, c, e, f, l, m, o c, f, a, m, o 24

28 Dann ergibt sich die folgende EFP Tabelle: Item c f a m o c f a b m f b c b o c f a m o Path null null : c null: c : f null : c : f : a null : c : f : a : m null null : c null : c : f null : c : f : a null : c : f : a : b null null : f null null : c null : c : b null null : c null : c : f null : c : f : a null : c : f : a : m Mit der oben eingeführten SQL-Anweisung lässt sich die FP-Tabelle aus der EFP-Tabelle bestimmen. Item Count Path c 4 null f 3 null : c a 3 null: c : f m 2 null : c : f : a o 2 null : c : f : a : m b 1 null : c : f : a m 1 null : c : f : a : b f 1 null b 1 null : f b 1 null : c o 1 null : c : b Nachdem die FP Tabelle erstellt wird, kann jetzt der Mining Prozess durchgeführt werden, wobei sich die Vorgehensweise von dem ersten Ansatz (FP-Ansatz) nicht unterscheidet. Fazit: Der SQL-basierte FP-Ansatz stellt den FP-tree als eine relationale Tabelle FP dar und schlägt eine Methode zur Konstruktion dieser Tabelle vor. Um die Performance dieses Ansatzes zu verbessern, wird eine weitere Tabelle (EFP Tabelle) eingeführt, die alle Informationen über die frequenten Itemsets und deren Präxpfade für jede Transaktion enthält. Daraus kann die FP Tabelle einfach abgeleitet werden. Diese FP Tabelle ist für den anschlieÿenden Mining Prozess zu benutzen. 25

29 Variante 3 Im nächsten Ansatz (SL05) wird der FP-tree wieder als eine Tabelle dargestellt, aber statt des Attributes path wird die Eltern-Kind-(parent-child)-Beziehung benutzt um die Pfade von einem Knoten bis zur Wurzel zu bestimmen. Das Schema dieser Tabelle ist das folgende: Spaltenname node_id parent_id item count sidelink Bedeutung ID des Knotens ID des Elternknotens Item-ID Anzahl der Transaktionen node-link des Knotens Wie im Kapitel 3 schon erläutert wurde, wird bei der Konstruktion des FP-tree der neue Pfad in den Baum eingefügt oder wenn die Items schon im Baum vorhanden sind, werden die Zähler der Items inkrementiert. Aber diese Vorgehensweise ist bei der Implementierung in SQL nicht besonders ezient (SL05). In diesem Ansatz wird der FPtree schrittweise erstellt, in dem man alle Knoten, die sich in den Transaktionen auf einer Ebene benden (zum Beispiel, alle ersten Items aus den Transaktionen benden sich auf der gleichen - ersten - Ebene), in eine Ebene des Baums durch eine SQL-Anweisung einfügt. Bei allen Knoten auf der ersten Ebene, welche die Wurzel als Elternknoten haben, ist parent_id auf null gesetzt. Für die Konstruktion des FP-tree werden folgende Tabellen benutzt: Input-Tabelle und Präx-Tabelle. Das Schema der Input-Tabelle entspricht dem ersten vorgestellten Schema für die Input-Tabellen: (tid, item). Die Präx-Tabelle repräsentiert Information über die gerade bearbeiteten Knoten. Wegen der bestimmten Reihenfolge des Einfügens der Knoten in den Baum werden aus der Präx-Tabelle die IDs des Elternknotens für die nächsten zu bearbeitenden Knoten erhalten. Das Schema dieser Tabelle ist folgendes: Spaltenname tid node_id Bedeutung Transaktions-ID ID des Knotens Nach dem die Tabelle für die Darstellung des FP-tree erstellt wurde, wird der Mining Prozess durchgeführt. In diesem Ansatz wird der Top-Down FP-Growth Algorithmus dafür benutzt. Wie es im Kapitel 3 beschrieben wurde, lässt sich dadurch die Konstruktion der conditional pattern-bases und conditional FP-trees vermeiden. 26

30 Für das Mining wird eine frequent-item-header-tabelle mit folgendem Schema gebraucht: Spaltenname header_id item count Bedeutung eindeutige ID ID des Items Zähler des Items Das Mining beginnt mit dem Item, das am Anfang der frequent-item-header-tabelle steht (chronologische Reihenfolge). Durch das Verfolgen der Eltern-Kind Beziehungen für jeden Knoten lassen sich die Präxpfade von einem Knoten bis zur Wurzel des Baums bestimmen und die Zähler der Knoten auf diesen Pfaden akkumulieren. Diese Informationen werden in einer zusätzlichen Tabelle Sub-header-Tabelle, die das gleiche Schema hat, gespeichert und weiterhin bearbeitet. Wenn der Eintrag I aus der Subheader-Tabelle H_x bearbeitet wird (d.h. der Knoten I aus den Präxpfaden des Items x), wird das Mining rekursiv für alle frequenten Muster durchgeführt, die auf Ix enden. Auf diese Weise lassen sich rekursiv alle frequenten Muster bestimmen. Die genauere Vorgehensweise des Mining Prozesses in diesem Ansatz unterscheidet sich nicht von dem in Kapitel 3 beschriebenen TD-FP-Growth Algorithmus. Fazit: dieser SQL-basierte Ansatz schlägt die Methoden zur Konstruktion des FP-tree und zum Top-Down Mining mit dem FP-tree vor und stellt den FP-tree als eine Tabelle dar. Im Vergleich zu den FP- und EFP-Ansätzen wird die Eltern-Kind-Beziehung benutzt um auf den Pfad der Knoten zu zugreifen. Das ist von Vorteil, weil das in den FP- und EFP-Ansätzen benutzte path-attribut die spezielle Implementierung der Prozeduren für die Gewinnung der einzelnen Items aus den Pfaden erfordert. Das lässt sich im diesem Ansatz vermeiden, in dem die Möglichkeiten des hierarchischen SQL benutzt werden können. Im Vergleich zu dem originalen FP-Growth Algorithmus wird in diesem Ansatz das Mining von oben nach unten (top-down) durchgeführt. Dadurch lässt sich die Konstruktion der conditional pattern-bases und conditional FP-trees während des gesamten Mining Prozess vermeiden, was zur Verbesserung der Performance führt 27

31 (WTHL02). Die Implementierung dieses Ansatzes wird weiterhin im nächsten Abschnitt verfolgt und erläutert. 4.2 Überblick In diesem Abschnitt wird ein Überblick über die gesamte Implementierung gegeben. Weitere Abschnitte beschreiben die Aufgaben jeder benötigten Komponente. Die Implementierung wurde vollständig in Oracle 10g vorgenommen, wobei die storedprocedure language PL/SQL verwendet wurde. Eine Übersicht über wichtigen implementierten Funktionen ist anschaulich in der folgenden Abbildung dargestellt. Die Implementierung des Algorithmus besteht aus drei Funktionen. In der ersten Funktion werden die Input-Daten vorbereitet, die zweite Funktion, die den FP-tree konstruiert, und die dritte Funktion, die das Mining durchführt, aufgerufen und die Ergebnisse in die endgültige Form gebracht. Die Implementierung des Algorithmus lässt sich in vier Phasen unterteilen. In der ersten Phase werden die Input-Daten für den Algorithmus vorbereitet. Aus diesen Daten lässt sich in der zweiten Phase der FP-tree konstruieren. Mit Hilfe dieses FP-tree wird in der dritten Phase der Mining Prozess durchgeführt. Anschlieÿend werden die gefundenen Muster endgültig in einer Tabelle dargestellt. In den Abschnitten werden die einzelnen Phasen des Algorithmus erläutert und die für die Implementierung notwendigen Tabellen vorgestellt. Im Abschnitt 4.7 wird die Arbeitsweise des Algorithmus auf einer realen Datenbank demonstriert. Der Algorithmus setzt sich aus folgenden Teilen zusammen: Vorbereitung der Input-Daten. 28

32 Konstruktion des FP-tree. Mining Prozess. Darstellung der Ergebnisses. Der Algorithmus wird mit dem Aufruf folgender Prozedur gestartet: procedure mine(table_name in varchar2, tid_attr varchar2, item_attr varchar2, minsup_perc number) is sqls varchar2(2000); data_count number; minsupabs number; begin -- berechne den absoluten minimalen Support count_minsupabs(); -- Vorbereitung der Input-Daten (Abschnitt 4.3) prepare_input(); -- Konstruktion des FP-tree (Abschnitt 4.4) build_fp_table(minsupabs) ; -- Mining Prozess (Abschnit 4.5) mine_tree(p_header_id => 1, p_minsupabs => minsupabs) ; -- Umwandlung der Ergebnisses (Abschnitt 4.6) get_result(); end; Als Parameter werden der Name der Tabelle übergeben, für die das Mining durchgeführt werden soll, der Spaltenname mit den Transaktions-IDs, der Spaltenname mit den Items und der minimale Support in %. Um den absoluten minimalen Support zu bestimmen, werden zunächst unterschiedliche Transaktions-IDs aufgezählt. Aus dieser Anzahl lässt sich der absolute minimale Support wie folgt bestimmen: data_count := select count(distinct tid_attr) from table_name; minsupabs := data_count * ( minsup_perc /100 ); 4.3 Vorbereitung der Input-Daten Welche Spalten Transaktionen und Items enthalten, wird vom Benutzer deniert, und evtl. sind die Daten nicht von der Form, in der sie sich für die Benutzung im Algorithmus eignen, deshalb müssen diese Daten entsprechend vorbereitet und geändert werden um in dem Algorithmus benutzt werden zu können. In der Implementierung wird angenommen, dass Items mehrmals in einer Transaktion vorkommen können. Deshalb werden nur die 29