本節書摘來自華章社群《python資料挖掘：概念、方法與實踐》一書中的第2章，第2.3節項目—發現軟體項目标簽中的關聯規則，作者[美] 梅甘·斯誇爾（megan squire），更多章節内容可以通路雲栖社群“華章社群”公衆号檢視
2.3 項目—發現軟體項目标簽中的關聯規則
1997年，freshmeat網站創立，它是一個跟蹤免費、自由和開放源碼軟體（floss）項目的目錄。2011年，該網站更名為freecode。在出售、并購和多次網站重新設計之後，2014年，freecode網站的所有更新都停止了。這個網站仍然線上，但是不再更新，目錄中也不再加入任何新項目。現在，freecode是20世紀90年代和21世紀初floss項目相關資訊的快照。每個軟體項目的相關事實包括名稱、描述、下載下傳軟體的url、描述其特征的标簽、代表其流行度的一個數值，等等。
作為我的flossmole項目的一部分，我從2005年起就将來自freshmeat/freecode的資料編目。freshmeat/freecode提供定期的rdf下載下傳，描述網站上的每個項目。我下載下傳了這些rdf，解析出項目資料，将其組織為資料庫表，并提供基本的資料可視化處理。對于本書，我們可使用這個資料回答關于哪些項目标簽在floss項目中最經常同時出現的問題。為此，我們将從項目标簽中找出頻繁項集，并生成後續的關聯規則。頻繁項集将采用{gpl, linux, c}這樣的形式。關聯規則的樣闆形如：gpl, linux -> c [s=.60, c=.90, av=.15]。
首先，登入mysql伺服器，選擇本項目使用的資料庫（我的是test），建立一個資料庫表，儲存項目的主清單及标簽：
在這個資料集中，每個項目由freecode網站提供的一個數字和将項目添加到目錄中的人指定的一個标簽清單辨別。例如，編号為8的項目有标簽gpl、多媒體和語音/音頻标簽。
為了在指令行上将這些資料加載到mysql資料庫中，将該檔案解壓到你的工作目錄，然後登入mysql伺服器，使用正确的資料庫，發出source指令運作所有insert指令。過程如下：
為了回答前面的問題（哪些标簽最經常同時被發現？），我們需要先對資料稍作研究。首先，可以計算項目标簽組合的總數，注意，一個項目可能有多個标簽：
接下來，可以計算項目的總數。按照相關規則的術語，可以将freecode項目視為購物籃或者交易，每個項目标簽等價于購物籃中的一件商品：
資料集中有多少個唯一的項目？
這樣，有46 510個籃子，11 006件商品。為減少可能的相關規則數量，可以計算含有每個标簽的項目有多少個（包含各個産品的籃子有多少個），并删除非常罕見的标簽。下表展示了達到每個可能支援門檻值所需的項目數：
正如已經讨論過的，前面在概述apriori政策時講過，預先用所有可能的候選二進制組填寫資料庫，然後對其進行計數是不切實際的，因為可能的配對太多了。相反，我們在記憶體中生成候選二進制組，計算其支援門檻值，僅保留滿足支援門檻值條件的二進制組。正如前面的單例計數，二進制組和三元組的門檻值都保持為5%（2325個項目），使用常數minsupport儲存這個支援值。此外，依賴itertools.combinations()函數，從allsingletontags清單中生成所有size=2的可能組合。最後，将這些頻繁出現的标簽添加到新清單alldoubletontags中，将在下面的findtripletons()函數中使用這個清單：
得到這些頻繁項集之後，就可以開始從中設計關聯規則，為每條規則指定支援度和置信度了。下面是從三元組中生成規則的例程代碼。首先生成右側有單一項目的規則，這是根據和生成頻繁項集時相同的閉包屬性。換言之，如果{香草威化，香蕉->棉花糖}這樣的規則不令人感興趣，那麼計量其他右側有棉花糖存在的選項（如{香草威化->香蕉，棉花糖}就毫無意義。
最後，這段代碼還列印每條規則的附加值得分，這是通過從整條規則的置信度中減去右側項支援值計算的：從上述代碼生成的freecode規則如下所示。因為每個三元組可能生成3條規則，是以每條的右側都有單一項目。為了顯示的目的，我們将此分為包含3行的組：根據上述結果，我們如何知道哪些規則是有意義的？隻觀察支援值并不能得到特别有意義的線索，因為我們規定所考慮的每條規則至少必須有5%的支援度。
置信度與支援度的組合可能是有趣的計量手段。例如，規則{gpl , linux -> posix}的支援度最高（16%）且置信度超過90%。相反，規則{linux , posix -> c++}的支援度剛好超過門檻值（6%）且置信度最低（22%）。
附加值告訴我們，關聯規則在預測方程右側上與簡單地觀察右側本身相比有多大的優勢。這組規則沒有任何直接負相關的項目，但是有幾條規則極其接近于0，這表明僅使用右側的效果與将其作為規則一部分相同。舉個例子，{internet , web -> gpl}的附加值非常低，這表明僅使用gpl可能起到相同的效果，因為它作為單一項時的得分非常高。規則{linux , posix -> c++}也屬于附加值很低的類别，是清單中第二低的。加上非常低的支援度和置信度得分，使這條規則成為清單上價值最低的規則。
附加值得分較高的規則包括{dynamic content , internet -> web}和{dynamic content , web -> internet}。這兩條規則特别有趣，因為分組中的第三條規則{internet, web -> dynamic content}的附加值（0.53）很平常。接下來我們注意到，清單中最高附加值的規則的右側都有web或者internet，而另一個項目則出現在左側的某個地方。這說明web和internet是本資料集中聯系非常緊密的項目，它們對其他項目的預測能力不如互相預測的能力。
發現這種關系，意味着我們可以更深入地探究web和internet之間的關系。确切地說，我們應該關注規則web -> internet和 internet -> web。由于我們在資料庫中儲存了支援計數，是以可以使用sql查詢找出這兩條規則的支援度、置信度和附加值：
上述sql代碼看起來很吓人，是以這裡用一個小的python腳本對資料庫運作每個單獨查詢，使用得到的數值計算支援度、置信度和附加值。和以前一樣，填寫資料庫連接配接細節，并将想要比較的兩個術語填入常量x和y中：
這些結果似乎沒有給人留下太深刻的印象—畢竟，internet和web緊密相關并不是特别令人震驚的事情。但是，我們從這一過程中得到了一些重要的教訓。首先，結果可用于提出建議，如果有人為項目打上标簽“web”，我們可能也想建議用“internet”作為相關的标簽。此外，我們可能也想向關注internet項目的人們交叉推銷web項目，反之亦然。和在商店中将商品放置在同一位置不同，在數字化環境中作出推薦或者建議的代價沒有那麼高。在任何情況下，找出頻繁項集并生成關聯規則都是有用的工作，其可以确認我們對資料産生的懷疑，或者幫助我們了解資料中的底層模式，而用其他手段不一定能發現這種模式。