（4.05）>lev:
（0.0
[45]conv:
（1.85）
根据前边介绍进行结果分析，归纳出此规则的含义，并进行度量。
篇二：
关联规则说明
关联规则说明
1.研究关联规则的数据结构
关联规则用于研究用户同时购买/使用不同产品的关联性，用于与产品的使用关系数据一般以如下的“长表”来存储，以用户下载铃音为例：
2.关联规则说明
关联规则的形式一般是“产品一”?
“产品二”，但是不仅仅局限于A?
B,也包括A&B?
C,A?
B&C，A&B?
C&D等情况。
（A、B、C、D代表不同的产品）
一般使用三个指标来度量一个关联规则，根据这三个指标可以筛选出满足条件的关联规则。
这三个指标是：
Support（支持度）、Confidence（可信度）、Lift（提升度）。
以A?
B这个关联规则为例来说明：
Support（支持度）：
表示A、B同时使用的人数占所有用户数（研究关联规则的“长表”中的所有有使用的产品的用户数）的比例。
如果用P（A）表示使用A的用户比例，其他产品类推，那么Support=P（A&B）Confidence（可信度）：
表示使用A的用户中同时使用B的比例，即同时使用A和B的人占使用A的人的比例。
公式表达：
Confidence=P（A&B）/P（A）Lift（提升度）：
表示“使用A的用户中同时使用B的比例”与“使用B的用户比例”的比值。
公式表达：
Lift=（P（A&B）/P（A））/P（B）=P（A&B）/P（A）*P（B）。
提升度反映了关联规则中的A与B的相关性，提升度>1且越高表明正相关性越高，提升度<1且越低表明负相关性越高，提升度=1表明没有相关性。
通过专门的数据挖掘软件（如SAS/EM、SPSS/Clementine…）可以生成关联规则集。
在生成关联规则集之前，所有的软件都要求指定生成满足某些条件的规则集，可根据三个指标来指定，如Support>1%；也可指定只生成关联规则中涉及的产品数=2个的，即A?
B,B?
C，而不能生成A?
B&C，A&B?
C。
3.关联规则筛选
往往数据挖掘软件生成的关联规则很多，即使在生成之前指定了某些条件，这些条件我们一般也只是用于粗筛，比较精细的筛选往往都是在生成众多关联规则之后再进行手工的筛选。
筛选指标主要还是前面提到的三个度量关联规则的指标，一般的筛选顺序是这样的：
（1）首先筛选高Lift的规则：
Lift的高低代表了A与B的关联性高低。
Lift的大小会受
到P（B）的影响，如果P（B）=50%，Lift必定<=2;P（B）=10%,Lift必定<=10…
（2）进一步筛选Confidence高的规则：
Confidence越高表明规则越准确。
（3）最后再筛选Support相对较高的规则：
Support的高低代表AB同时购买的用户比例，
表明该产品组合是否为主流购买组合。
（4）Lift*conf*support排序取最高的。
篇三：
关联规则
在数据挖掘的知识模式中，关联规则模式是比较重要的一种。
关联规则的概念由
Agrawal、Imielinski、Swami提出，是数据中一种简单但很实用的规则。
关联规则模式属于描述型模式，发现关联规则的算法属于无监督学习的方法。
一、关联规则的定义和属性
考察一些涉及许多物品的事务：
事务1中出现了物品甲，事务2中出现了物品乙，事务3中则同时出现了物品甲和乙。
那么，物品甲和乙在事务中的出现相互之间是否有规律可循呢？
在数据库的知识发现中，关联规则就是描述这种在一个事务中物品之间同时出现的规律的知识模式。
更确切的说，关联规则通过量化的数字描述物品甲的出现对物品乙的出现有多大的影响。
现实中，这样的例子很多。
例如超级市场利用前端收款机收集存储了大量的售货数据，这些数据是一条条的购买事务记录，每条记录存储了事务处理时间，顾客购买的物品、物品的数量及金额等。
这些数据中常常隐含形式如下的关联规则：
在购买铁锤的顾客当中，有70％的人同时购买了铁钉。
这些关联规则很有价值，商场管理人员可以根据这些关联规则更好地规划商场，如把铁锤和铁钉这样的商品摆放在一起，能够促进销售。
有些数据不像售货数据那样很容易就能看出一个事务是许多物品的集合，但稍微转换一下思考角度，仍然可以像售货数据一样处理。
比如人寿保险，一份保单就是一个事务。
保险公司在接受保险前，往往需要记录投保人详尽的信息，有时还要到医院做身体检查。
保单上记录有投保人的年龄、性别、健康状况、工作单位、工作地址、工资水平等。
这些投保人的个人信息就可以看作事务中的物品。
通过分析这些数据，可以得到类似以下这样的关联规则：
年龄在40岁以上，工作在A区的投保人当中，有45％的人曾经向保险公司索赔过。
在这条规则中，“年龄在40岁以上”是物品甲，“工作在A区”是物品乙，“向保险公司索赔过”则是物品丙。
可以看出来，A区可能污染比较严重，环境比较差，导致工作在该区的人健康状况不好，索赔率也相对比较高。
设R={I1,I2……Im}是一组物品集，W是一组事务集。
W中的每个事务T是一组物品，TR。
假设有一个物品集A，一个事务T，如果AT，则称事务T支持物品集A。
关联规则是如下形式的一种蕴含：
A→B，其中A、B是两组物品，AI，BI，且A∩B=。
一般用四个参数来描述一个关联规则的属性：
1．可信度（Confidence）
设W中支持物品集A的事务中，有c％的事务同时也支持物品集B，c％称为关联规则A→B的可信度。
简单地说，可信度就是指在出现了物品集A的事务T中，物品集B也同时出现的概率有多大。
如上面所举的铁锤和铁钉的例子，该关联规则的可信度就回答了这样一个问题：
如果一个顾客购买了铁锤，那么他也购买铁钉的可能性有多大呢？
在上述例子中，购买铁锤的顾客中有70％的人购买了铁钉,所以可信度是70％。
2．支持度（Support）
设W中有s％的事务同时支持物品集A和B，s％称为关联规则A→B的支持度。
支持度描述了A和B这两个物品集的并集C在所有的事务中出现的概率有多大。
如果某天共有1000个顾客到商场购买物品，其中有100个顾客同时购买了铁锤和铁钉，那么上述的关联规则的支持度就是10％。
3．期望可信度（Expectedconfidence）
设W中有e％的事务支持物品集B，e％称为关联规则A→B的期望可信度度。
期望可信度描述了在没有任何条件影响时，物品集B在所有事务中出现的概率有多大。
如果某天共有1000个顾客到商场购买物品，其中有200个顾客购买了铁钉，则上述的关联规则的期望可信度就是20％。
4．作用度（Lift）
作用度是可信度与期望可信度的比值。
作用度描述物品集A的出现对物品集B的出现有多大的影响。
因为物品集B在所有事务中出现的概率是期望可信度；而物品集B在有物品集A出现的事务中出现的概率是可信度，通过可信度对期望可信度的比值反映了在加入“物品集A出现”的这个条件后，物品集B的出现概率发生了多大的变化。
在上例中作用度就是70％/20％=3.5。
可信度是对关联规则的准确度的衡量，支持度是对关联规则重要性的衡量。
支持度说明了这条规则在所有事务中有多大的代表性，显然支持度越大，关联规则越重要。
有些关联规则可信度虽然很高，但支持度却很低，说明该关联规则实用的机会很小，因此也不重要。
期望可信度描述了在没有物品集A的作用下，物品集B本身的支持度；作用度描述了物品集A对物品集B的影响力的大小。
作用度越大，说明物品集B受物品集A的影响越大。
一般情况，有用的关联规则的作用度都应该大于1，只有关联规则的可信度大于期望可信度，才说明A的出现对B的出现有促进作用，也说明了它们之间某种程度的相关性，如果作用度不大于1，则此关联规则也就没有意义了。
二、关联规则的挖掘
在关联规则的四个属性中，支持度和可信度能够比较直接形容关联规则的性质。
从关联规则定义可以看出，任意给出事务中的两个物品集，它们之间都存在关联规则，只不过属性值有所不同。
如果不考虑关联规则的支持度和可信度，那么在事务数据库中可以发现无穷多的关联规则。
事实上，人们一般只对满足一定的支持度和可信度的关联规则感兴趣。
因此，为了发现有意义的关联规则，需要给定两个阈值：
最小支持度和最小可信度，前者规定了关联规则必须满足的最小支持度；后者规定了关联规则必须满足的最小可信度。
一般称满足一定要求的（如较大的支持度和可信度）的规则为强规则（Strongrules）。
在关联规则的挖掘中要注意以下几点：
1、充分理解数据。
2、目标明确。
3、数据准备工作要做好。
能否做好数据准备又取决于前两点。
数据准备将直接影响到问题的复杂度及目标的实现。
4、选取恰当的最小支持度和最小可信度。
这依赖于用户对目标的估计，如果取值过小，那么会发现大量无用的规则，不但影响执行效率、浪费系统资源，而且可能把目标埋没；如果取值过大，则又有可能找不到规则，与知识失之交臂。
5、很好地理解关联规则。
数据挖掘工具能够发现满足条件的关联规则，但它不能判定关联规则的实际意义。
对关联规则的理解需要熟悉业务背景，丰富的业务经验对数据有足够的理解。
在发现的关联规则中，可能有两个主观上认为没有多大关系的物品，它们的关联规则支持度和可信度却很高，需要根据业务知识、经验，从各个角度判断这是一个偶然现象或有其内在的合理性；反之，可能有主观上认为关系密切的物品，结果却显示它们之间相关性不强。
只有很好的理解关联规则，才能去其糟粕，取其精华，充分发挥关联规则的价值。
发现关联规则要经过以下三个步骤：
1、连接数据，作数据准备；
2、给定最小支持度和最小可信度，利用数据挖掘工具提供的算法发现关联规则；
3、可视化显示、理解、评估关联规则。
三、关联规则挖掘的过程
关联规则挖掘过程主要包含两个阶段：
第一阶段必须先从资料集合中找出所有的高频项目组（FrequentItemsets），
第二阶段再由这些高频项目组中产生关联规则（AssociationRules）。
关联规则挖掘的第一阶段必须从原始资料集合中，找出所有高频项目组（LargeItemsets）。
高频的意思是指某一项目组出现的频率相对于所有记录而言，必须达到某一水平。
一项目组出现的频率称为支持度（Support），以一个包含A与B两个项目的2-itemset为例，我们可以经由公式
（1）求得包含{A,B}项目组的支持度，若支持度大于等于所设定的最小支持度（MinimumSupport）门槛值时，则{A,B}称为高频项目组。
一个满足最小支持度的k-itemset，则称为高频k-项目组（Frequentk-itemset），一般表示为Largek或Frequentk。
算法并从Largek的项目组中再产生Largek+1，直到无法再找到更长的高频项目组为止。
关联规则挖掘的第二阶段是要产生关联规则（AssociationRules）。
从高频项目组产生关
联规则，是利用前一步骤的高频k-项目组来产生规则，在最小信赖度（Minimum
Confidence）的条件门槛下，若一规则所求得的信赖度满足最小信赖度，称此规则为关联规则。
从上面的介绍还可以看出，关联规则挖掘通常比较适用与记录中的指标取离散值的情况。
如果原始数据库中的指标值是取连续的数据，则在关联规则挖掘之前应该进行适当的数据离散化（实际上就是将某个区间的值对应于某个值），数据的离散化是数据挖掘前的重要环节，离散化的过程是否合理将直接影响关联规则的挖掘结果。
四、关联规则的分类
按照不同情况，关联规则可以进行分类如下：
1.基于规则中处理的变量的类别，关联规则可以分为布尔型和数值型。
布尔型关联规则处理的值都是离散的、种类化的，它显示了这些变量之间的关系；而数值型关联规则可以和多维关联或多层关联规则结合起来，对数值型字段进行处理，将其进行动态的分割，或者直接对原始的数据进行处理，当然数值型关联规则中也可以包含种类变量。
例如：
性别=“女”=>职业=“秘书”，是布尔型关联规则；性别=“女”=>avg（收入）=2300，涉及的收入是数值类型，所以是一个数值型关联规则。
2.基于规则中数据的抽象层次，可以分为单层关联规则和多层关联规则。
在单层的关联规则中，所有的变量都没有考虑到现实的数据是具有多个不同的层次的；而在多层的关联规则中，对数据的多层性已经进行了充分的考虑。
例如：
IBM台式机=>Sony打印机，是一个细节数据上的单层关联规则；台式机=>Sony打印机，是一个较高层次和细节层次之间的多层关联规则。
3.基于规则中涉及到的数据的维数，关联规则可以分为单维的和多维的。
在单维的关联规则中，我们只涉及到数据的一个维，如用户购买的物品；而在多维的关联规则中，要处理的数据将会涉及多个维。
换成另一句话，单维关联规则是处理单个属性中的一些关系；多维关联规则是处理各个属性之间的某些关系。
例如：
啤酒=>尿布，这条规则只涉及到用户的购买的物品；性别=“女”=>职业=“秘书”，这条规则就涉及到两个字段的信息，是两个维上的一条关联规则。
5.关联规则挖掘的相关算法
篇四：
weka关联规则使用
前面几篇介绍了关联规则的一些基本概念和两个基本算法，但实际在商业应用中，写算法反而比较少，理解数据，把握数据，利用工具才是重要的，前面的基础篇是对算法的理解，这篇将介绍开源利用数据挖掘工具weka进行管理规则挖掘。
weka数据集格式arff
arff标准数据集简介
weka的数据文件后缀为arff（Attribute-RelationFileFormat，即属性关系文件格式），arff文件分为注释、关系名、属性名、数据域几大部分，注释用百分号开头%，关系名用@relation申明，属性用@attribute什么，数据域用@data开头，看这个示例数据集（安装weka后，可在weka的安装目录/data下找到weather.numeric.arff）：
%weatherdataset
@relationweather
@attributeoutlook{sunny,overcast,rainy}
@attributetemperaturenumeric
@attributehumiditynumeric
@attributewindy{TRUE,FALSE}
@attributeplay{yes,no}
@data
sunny,85,85,FALSE,no
sunny,80,90,TRUE,no
overcast,83,86,FALSE,yes
rainy,70,96,FALSE,yes
rainy,68,80,FALSE,yes
rainy,65,70,TRUE,no
overcast,64,65,TRUE,yes
sunny,72,95,FALSE,no
sunny,69,70,FALSE,yes
rainy,75,80,FALSE,yes
sunny,75,70,TRUE,yes
overcast,72,90,TRUE,yes
overcast,81,75,FALSE,yes
rainy,71,91,TRUE,no
当数据是数值型，在属性名的后面加numeric，如果是离散值（枚举值），就用一个大括号将值域列出来。
@data下一行后为数据记录，数据为矩阵形式，即每一个的数据元素个数相等，若有缺失值，就用问号?
表示。
arff稀疏数据集
我们做关联规则挖掘，比如购物篮分析，我们的购物清单数据肯定是相当稀疏的，超市的商品种类有上10000种，而每个人买东西只会买几种商品，这样如果用矩阵形式表示数据显然浪费了很多的存储空间，我们需要用稀疏数据表示，看我们的购物清单示例（basket.txt）：
freshmeatdairyconfectionery
freshmeatconfectionery
cannedvegfrozenmealbeerfish
dairywine
freshmeatwinefish
fruitvegsoftdrink
beer
fruitvegfrozenmeal
fruitvegfish
fruitvegfreshmeatdairycannedvegwinefish
fruitvegfish
dairycannedmeatfrozenmealfish
数据集的每一行表示一个去重后的购物清单，进行关联规则挖掘时，我们可以先把商品名字映射为id号，挖掘的过程只有id号就是了，到规则挖掘出来之后再转回商品名就是了，retail.txt是一个转化为id号的零售数据集，数据集的前面几行如下：
012345678910111213141516171819202122232425262728
303132
333435
3637383940414243444546
38394748
38394849505152535455565758
324159606162
33948
636465666768
3269
这个数据集的商品有16469个，一个购物的商品数目远少于商品中数目，因此要用稀疏数据表，weka支持稀疏数据表示，但我在运用apriori算法时有问题，先看一下weka的稀疏数据要求：
稀疏数据和标准数据的其他部分都一样，唯一不同就是@data后的数据记录，示例如下（basket.arff）：
@relation'basket'
@attributefruitveg{F,T}
@attributefreshmeat{F,T}
@attributedairy{F,T}
@attributecannedveg{F,T}
@attributecannedmeat{F,T}
@attributefrozenmeal{F,T}
@attributebeer{F,T}
@attributewine{F,T}
@attributesoftdrink{F,T}
@attributefish{F,T}
@attributeconfectionery{F,T}
@data
{1T,2T,10T}
{1T,10T}
{3T,5T,6T,9T}
{2T,7T}
{1T,7T,9T}
{0T,8T}
{6T}
{0T,5T}
{0T,9T}
{0T,1T,2T,3T,7T,9T}
{0T,9T}
{2T,4T,5T,9T}
可以看到
freshmeatdairyconfectionery
freshmeatconfectionery
表示为了：
{1T,2T,10T}
{1T,10T
稀疏数据的表示格式为：
{<属性列号><空格><值>,...,<属性列号><空格><值>}，注意每条记录要用大括号，属性列号不是id号，属性列号是从0开始的，即第一个@attribute后面的属性是第0个属性，T表示数据存在。
升级会员 