演算法效能比較

AFPIM 演算法將舊的樹狀結構建立出來後，再進行調整項目；而我們的作法是 在樹還沒有從關聯式資料表建立出來之前，就先針對項目順序變動做處理，再把 這個資料表建成樹，所以時間上快很多。

AFPIM 演算法在調整項目時，針對其順序發生變動的項目，針對這個項目 的 Header Table 中所記錄的每個節點，去進行相對應的處理動作，可是像這樣的 樹狀結構，通常情況下優先順序越低的項目，分布在樹中的節點位置越多，原因 來自於這個項目一定排在優先權比它高的項目之後，當優先順序越低，比它大的 項目就越多，也因此使它的分布位置越多。而且，一般越接近門檻值的項目越有 可能發生順序變動，所以幾乎只要發生項目變動要調整節點順序，所要處理的節 點就相當大量。所以在調整項目的耗費時間上，始終與我們的演算法有一段差 距，為了更明顯看出這種差距，我們將演算法比 AFPIM 演算法所節省的時間以 百分比率呈現，最高可以節省探勘所需時間 46%，平均則可以節省時間約 30%，

如圖 5-2：

節省時間百分比

0%

10%

20%

30%

40%

50%

一 二 三 四 五 六 七 八 九 十 十一 十二

月份

百分比 百分比

圖 5-2：較 AFPIM 演算法節省時間百分比

二、支持度 0.3%、準支持度 0.15%設定下，三個演算法的效能比較

這部份的實驗比較中，我們將支持度設定為 0.3%，準支持度為 0.15%，實驗 結果如圖 5-3：

0.3%支持度下的表現

0 500 1000 1500 2000 2500 3000

1 2 3 4 5 6 7 8 9 10 11 12

累積月份

所需時間(秒)

IDFPBT PDBA AFPIM

圖 5-3：DFPBT、AFPIM、PDBA 演算法探勘時間比較(支持度 0.3%) 實驗結果中可以看出我們的演算法與 AFPIM 演算法同樣走勢平緩，與 0.1%

支持度設定下的實驗差不多，因為支持度較大的設定下，需要維護的高頻與準高 頻項目數量較少，樹的結構較小，因此兩者的差距似乎變得較小了，我們一樣將 時間差製成百分比圖來觀察，最高可以節省時間 38%，平均則可節省時間約 23%，如圖 5-4：

節省時間百分比

0%

10%

20%

30%

40%

1 2 3 4 5 6 7 8 9 10 11 12

月份

百分比

百分比

圖 5-4：較 AFPIM 演算法節省時間百分比

不過在 DFPBT 的表現上，卻發現不止七月份的耗費時間表現如 0.1%支持度 設定下的突然升高，九月份亦發生相同的情況，而且狀況更明顯了，這個現象我 們以圖 5-5 來舉例說明，項目順序由高到低表示項目的優先順序排列方向，0.1%

與 0.3%的長條圖則表示符合支持度設定的一次項數量：

圖 5-5：項目變動位置示意圖

由圖 5-5 中我們可以看出因為支持度的設定而影響門檻值的大小，需要維護 及保留的一次項數量也不相同。舉例來說，當交易紀錄有 10000 筆時，在 0.1%

支持度設定下的門檻次數為 10 次，而 0.3%支持度設定下則為 30 次，因此符合 較高支持度的一次項數量會較少。九月的耗費時間突然增加，原因來自於當項目 變動的情況發生在圖 5-5 的箭頭所指位置時，在 0.1%支持下所作的動作只是需 要去調整項目的排列順序，因為項目皆已保留在樹狀結構中，而在 0.3%支持度 的設定下，產生的情況卻是項目由高頻變非高頻、非高頻變為高頻，這時候就須 要去掃描 Infrequent Table，而因為資料探勘已經進行到第九個月，前面累積了八 個月含非高頻項目交易紀錄的龐大資料量，所以在掃描 Infrequent Table 時耗費了 相當多的時間，也因此致使九月份的耗費時間比七月份更加明顯。