学习笔记（杂记）——关联规则算法

关联分析又称关联挖掘，就是在交易数据、关系数据或其他信息载体中，查找存在于项目集合或对象集合之间的频繁模式、关联、相关性或因果结构。或者说，关联分析是发现交易数据库中不同商品（项）之间的联系。关联分析是一种简单、实用的分析技术，就是发现存在于大量数据集中的关联性或相关性，从而描述了一个事物中某些属性同时出现的规律和模式。
关联分析是从大量数据中发现项集之间有趣的关联和相关联系。关联分析的一个典型例子是购物篮分析。该过程通过发现顾客放人其购物篮中的不同商品之间的联系，分析顾客的购买习惯。通过了解哪些商品频繁地被顾客同时购买，这种关联的发现可以帮助零售商制定营销策略。其他的应用还包括价目表设计、商品促销、商品的排放和基于购买模式的顾客划分。
可从数据库中关联分析出形如“由于某些事件的发生而引起另外一些事件的发生”之类的规则。如“67%的顾客在购买啤酒的同时也会购买尿布”，因此通过合理的啤酒和尿布的货架摆放或捆绑销售可提高超市的服务质量和效益。又如“C语言课程优秀的同学，在学习‘数据结构’时为优秀的可能性达88%”，那么就可以通过强化“C语言”的学习来提高教学效果。

1、关联规则挖掘定义

大多数关联规则挖掘算法通常采用的一种策略是，将关联规则挖掘任务分解为如下两个主要的子任务：
（1）频繁项集产生（Frequent Itemset Generation）其目标是发现满足最小支持度阈值的所有项集，这些项集称作频繁项集。
（2）规则的产生（Rule Generation）其目标是从上一步发现的频繁项集中提取所有高置信度的规则，这些规则称作强规则。

2、关联分析的目标

（1）发现频繁项集；
（2）由频繁项集产生强关联规则，这些规则必须大于或等于最小支持度和最小置信度。

3、Apriori算法

（1）基本术语:
项集：项集是项的集合。包含k个项的项集称为k项集，如集合{面包}，{牛奶}都是一个单项集（一般人们买了面包都会买一些牛奶）。
支持度:项集A和B同时发生的概率（联合概率），反应出某种规则出现的是否重要。

置信度：当项集A发生的情况下，项集B发生的概率（条件概率），反应出某种规则是否可靠。

等价于：

最小支持度和最小置信度：最小支持度是用户或专家定义的衡量支持度的一个阈值，表示项目集在统计意义上的最低重要性；最小置信度是用户或专家定义的衡量置信度的一个阈值，表示关联规则的最低可靠性。同时满足最小支持度阈值和最小置信度阈值的规则称作强规则。
（2）核心思想与步骤：
支持度和置信度越高，说明规则越强，关联规则算法就是挖掘出满足一定强度的规则。在执行算法之前，我们需要先给定最小的支持度和最小的置信度，生成关联规则一般被划分为如下两个步骤：
1）利用最小支持度从所有事物中找到频繁项集。给定一个事物 D ，寻找频繁项集流程如下图所示：

C1 中 {1} 的支持度为 2/4 = 0.5 表示在 D 中的 4 条事务中，{1} 出现在其中的两条事务中，以后几个步骤的支持度计算方式也是类似的。假定给定的最小支持度为 0.5，那么最后我们可以得到一个包含 3 个项的频繁项集 {2 3 5}。这里没有出现{1 2 3}和{1 3 5}的原因就是{1 2}和{1 5}在C2中不是频繁项集。这样我们可以引申出一条定律：如果一个集合不是频繁项集，则它的所有超集都不是频繁项集。举例：假设集合{A}不是频繁项集，即A出现的次数小于min_support，则它的任何超集如{A,B}出现的次数必定小于min_support，因此其超集必定也不是频繁项集。同样可推理另一条定律是：如果一个集合是频繁项集，则它的所有子集都是频繁项集。举例：假设一个集合{A,B}是频繁项集，即A、B同时出现在一条记录的次数大于等于最小支持度min_support，则它的子集{A},{B}出现次数必定大于等于min_support，即它的子集都是频繁项集。另外，从图中我们可以看到 itemset 中所包含的 item 是从1增长到3的。并且每次增长都是利用上一个itemset 中满足支持度的 item 来生成的，这个过程称之为候选集生成（candidate generation）。比如说C2里就不包含C1中的4 。
2）利用最小置信度从频繁项集中找到关联规则。
同样假定最小的置信度为0.5，从频繁项集 {2 3 5} 中我们可以发现规则 {2 3} ⇒ {5} 的置信度为 1 > 0.5 ，所以我们可以说 {2 3} ⇒ {5} 是一个可能感兴趣的规则。
（3）优缺点：
优点：易编码实现
缺点：在大数据集上可能较慢
适用数据类型：数值型或者标称型数据。

4、FpGrowth算法

Aprori算法利用频繁集的两个特性，过滤了很多无关的集合，效率提高不少，但是我们发现Apriori算法是一个候选消除算法，每一次消除都需要扫描一次所有数据记录，造成整个算法在面临大数据集时显得无能为力。今天我们介绍一个新的算法挖掘频繁项集，效率比Aprori算法高很多。
FpGrowth算法通过构造一个树结构来压缩数据记录，使得挖掘频繁项集只需要扫描两次数据记录，而且该算法不需要生成候选集合，所以效率会比较高。我们还是以上一篇中用的数据集为例：
TID Items
T1 {牛奶,面包}
T2 {面包,尿布,啤酒,鸡蛋}
T3 {牛奶,尿布,啤酒,可乐}
T4 {面包,牛奶,尿布,啤酒}
T5 {面包,牛奶,尿布,可乐}
（1）构造FpTree
FpTree是一种树结构，树结构定义如下：

public class FpNode {

    String idName;// id号
    List<FpNode> children;// 孩子结点
    FpNode parent;// 父结点
    FpNode next;// 下一个id号相同的结点
    long count;// 出现次数
} 

树的每一个结点代表一个项，这里我们先不着急看树的结构，我们演示一下FpTree的构造过程，FpTree构造好后自然明白了树的结构。假设我们的最小绝对支持度是3。
Step 1：扫描数据记录，生成一级频繁项集，并按出现次数由多到少排序，如下所示：
Item Count
牛奶 4
面包 4
尿布 4
啤酒 3
可以看到，鸡蛋和可乐没有出现在上表中，因为可乐只出现2次，鸡蛋只出现1次，小于最小支持度，因此不是频繁项集，根据Apriori定理，非频繁项集的超集一定不是频繁项集，所以可乐和鸡蛋不需要再考虑。
Step 2：再次扫描数据记录，对每条记录中出现在Step 1产生的表中的项，按表中的顺序排序。初始时，新建一个根结点，标记为null；
1）第一条记录：{牛奶,面包}，按Step 1表过滤排序得到依然为{牛奶,面包}，新建一个结点，idName为{牛奶}，将其插入到根节点下，并设置count为1，然后新建一个{面包}结点，插入到{牛奶}结点下面，插入后如下所示：

2）第二条记录：{面包,尿布,啤酒,鸡蛋}，过滤并排序后为：{面包,尿布,啤酒}，发现根结点没有包含{面包}的儿子（有一个{面包}孙子但不是儿子），因此新建一个{面包}结点，插在根结点下面，这样根结点就有了两个孩子，随后新建{尿布}结点插在{面包}结点下面，新建{啤酒}结点插在{尿布}下面，插入后如下所示：

3）第三条记录：{牛奶,尿布,啤酒,可乐}，过滤并排序后为：{牛奶,尿布,啤酒}，这时候发现根结点有儿子{牛奶}，因此不需要新建结点，只需将原来的{牛奶}结点的count加1即可，往下发现{牛奶}结点有一个儿子{尿布}，于是新建{尿布}结点，并插入到{牛奶}结点下面，随后新建{啤酒}结点插入到{尿布}结点后面。插入后如下图所示：

4）第四条记录：{面包,牛奶,尿布,啤酒}，过滤并排序后为：{牛奶，面包,尿布,啤酒}，这时候发现根结点有儿子{牛奶}，因此不需要新建结点，只需将原来的{牛奶}结点的count加1即可，往下发现{牛奶}结点有一个儿子{面包}，于是也不需要新建{面包}结点，只需将原来{面包}结点的count加1，由于这个{面包}结点没有儿子，此时需新建{尿布}结点，插在{面包}结点下面，随后新建{啤酒}结点，插在{尿布}结点下面，插入后如下图所示：

5）第五条记录：{面包,牛奶,尿布,可乐}，过滤并排序后为：{牛奶，面包,尿布}，检查发现根结点有{牛奶}儿子，{牛奶}结点有{面包}儿子，{面包}结点有{尿布}儿子，本次插入不需要新建结点只需更新count即可，示意图如下：

按照上面的步骤，我们已经基本构造了一棵FpTree（Frequent Pattern Tree），树中每天路径代表一个项集，因为许多项集有公共项，而且出现次数越多的项越可能是公公项，因此按出现次数由多到少的顺序可以节省空间，实现压缩存储，另外我们需要一个表头和对每一个idName相同的结点做一个线索，方便后面使用，线索的构造也是在建树过程形成的，但为了简化FpTree的生成过程，我没有在上面提到，这个在代码有体现的，添加线索和表头的Fptree如下：

至此，整个FpTree就构造好了，在下面的挖掘过程中我们会看到表头和线索的作用。
（2）利用FpTree挖掘频繁项集
　FpTree建好后，就可以进行频繁项集的挖掘，挖掘算法称为FpGrowth（Frequent Pattern Growth）算法，挖掘从表头header的最后一个项开始。
1）此处即从{啤酒}开始，根据{啤酒}的线索链找到所有{啤酒}结点，然后找出每个{啤酒}结点的分支：{牛奶，面包，尿布，啤酒：1}，{牛奶，尿布，啤酒:1}，{面包，尿布，啤酒:1}，其中的“1”表示出现1次，注意，虽然{牛奶}出现4次，但{牛奶，面包，尿布，啤酒}只同时出现1次，因此分支的count是由后缀结点{啤酒}的count决定的，除去{啤酒}，我们得到对应的前缀路径{牛奶，面包，尿布：1}，{牛奶，尿布:1}，{面包，尿布:1}，根据前缀路径我们可以生成一颗条件FpTree，构造方式跟之前一样，此处的数据记录变为：
TID Items
T1 {牛奶，面包，尿布}
T2 {牛奶，尿布}
T3 {面包，尿布}
绝对支持度依然是3，构造得到的FpTree为：

构造好条件树后，对条件树进行递归挖掘，当条件树只有一条路径时，路径的所有组合即为条件频繁集，假设{啤酒}的条件频繁集为{S1,S2,S3}，则{啤酒}的频繁集为{S1+{啤酒},S2+{啤酒},S3+{啤酒}}，即{啤酒}的频繁集一定有相同的后缀{啤酒}，此处的条件频繁集为：{{}，{尿布}}，于是{啤酒}的频繁集为{{啤酒}{尿布，啤酒}}。
2）接下来找header表头的倒数第二个项{尿布}的频繁集，同上可以得到{尿布}的前缀路径为：{面包：1}，{牛奶：1}，{牛奶，面包：2}，条件FpTree的数据集为：
TID Items
T1 {面包}
T2 {牛奶}
T3 {牛奶，面包}
T4 {牛奶，面包}

注意{牛奶，面包：2}，即{牛奶，面包}的count为2，所以在{牛奶，面包}重复了两次，这样做的目的是可以利用之前构造FpTree的算法来构造条件Fptree，不过这样效率会降低，试想如果{牛奶，面包}的count为20000，那么就需要展开成20000条记录，然后进行20000次count更新，而事实上只需要对count更新一次到20000即可。这是实现上的优化细节，实践中当注意。构造的条件FpTree为：

这颗条件树已经是单一路径，路径上的所有组合即为条件频繁集：{{}，{牛奶}，{面包}，{牛奶，面包}}，加上{尿布}后，又得到一组频繁项集{{尿布}，{牛奶，尿布}，{面包，尿布}，{牛奶，面包，尿布}}，这组频繁项集一定包含一个相同的后缀：{尿布}，并且不包含{啤酒}，因此这一组频繁项集与上一组不会重复。重复以上步骤，对header表头的每个项进行挖掘，即可得到整个频繁项集。

绝对支持度： 3
频繁项集： 
面包 尿布     3
尿布 牛奶     3
牛奶     4
面包 牛奶     3
尿布 啤酒     3
面包     4