求救各位一道vb程序题，题目是《关联规则的分层组织和表达》，下面是一篇关于关联规则的论文，要做的程序就是将关联规则分层表达，谁能帮我一下，万分感谢！

0 引言
数据挖掘技术能从大量原始数据中提取出有价值的、事先未知的、隐含的、潜在有用的知识[1]。在实际应用中，数据挖掘应用的数据库一般是大型数据库，许多挖掘算法（特别是关联规则挖掘）会产生大量规则，而用户往往只关心他们“感兴趣”的规则。要理解数千甚至上万条规则，并从中识别出重要的规则，对用户来说太困难了，这已成为数据挖掘中一个普遍存在的问题。许多学者已对此问题展开研究，提出的解决方法主要有如下几种：
在关联规则挖掘过程中提高相关参数（如关联规则的最小支持度和置信度）的阈值，或增加一些约束条件，减少挖掘出的规则数。但这种方法可能造成挖掘结果丢失一些重要信息。
另一类方法是对挖掘结果进行处理,减少规则数目。如利用X2 检验和IP(Integer Programming)技术约简规则[2][3]，或用挖掘结果子集(如Rule Cover[4] 或DS规则集[2])代替挖掘出的全部规则。它们的共同特点是用户看到的是表示领域知识的主要规则或总结后规则，而无法得知一些具体规则的细节。
也有人通过提供模板、查询语言[6]等工具为用户管理和选择规则提供方便。用户先利用模板指定自己感兴趣的规则模式，系统再从挖掘结果中找出与之匹配的规则[7]；或者用户描述已知的领域知识，由系统发现挖掘结果中的例外规则[8][9]。这些方法都要求用户能确切描述他所关心或已知的知识，但这对一般用户来说也很困难。
本文希望在不改变关联规则挖掘结果的前提下，通过对挖掘结果进行分析，提出根据规则的通用性，按照由概括到具体的方式分层表达关联规则。先找出挖掘结果中能代表基本领域知识的最概括的规则，让用户对挖掘结果有一总体认识。如果用户对某些规则感兴趣，再有选择地分层查看概括规则下面更具体的规则。这种分层表达方式，既标识出重要规则，又保持了规则的完整性，使大量规则更容易管理和被人理解。

1  关联规则挖掘简介
关联规则概念是1993年R.Agrawal提出的[1]:令I ={i1,i2,i3,...,im}为一组属性的可能取值，称为数据项集，其中ik（1≤k≤n）称为数据项，通常是数据库中记录某一属性的值。I中元素的个数称为数据项集的长度，长度为n的数据项集称为n维数据项集。T是一个包含多个数据项的集合，即T I，称为一个事务。D是全体事务组成的数据集合，即整个数据库。 
一条关联规则是如下形式的蕴涵式X →Y，其中X,Y I且X∩Y=Ф，则称规则X →Y在事务集合D中成立，X称为规则的先决条件，Y称为规则的结果。描述一条关联规则至少需要两个参数：
1）支持度(Support) 
设D中有S% 的事务同时包含数据项集X和Y，则称S% 为关联规则X→Y的支持度,即 S%=|XY|/|D|。其中|D|表示事务集D包含的事务总数，|XY|表示同时出现X和Y的事务数。支持度描述了X和Y在所有事务中同时出现的概率有多大。
2）置信度（Confidence）
如果D中包含X的事务有C% 也同时包含Y，则称C%为关联规则X →Y的置信度,即 C%=|XY|/|X|。简单地说，置信度是指在出现了X的事务T中，Y也同时出现的概率有多大。
用目前已知的任何关联规则挖掘算法产生关联规则时，用户必须指定两个阈值：规则必须满足的最小支持度(MinSupp)和最小置信度(MinConf)。挖掘关联规则的过程就是在给定事务集D中产生所有满足MinSupp和MinConf关联规则的过程。一般的做法是：先寻找支持度超过用户给定MinSupp的所有各维数据项集，称为频繁集，然后应用频繁集产生规则，即对每一频繁项都要验证其所有可能生成的规则是否成立。例如，如果ABC是频繁项，那么要通过计算置信度来确定规则A→BC, AB→C, AC→B, B→AC, BC→A, C→AB是否成立。
本文讨论的问题主要针对关系数据库D, 其中数据项可能是一个属性，也可能是属性值对，如attribute = value。所有挖掘出的关联规则都满足用户指定的最小支持度和最小置信度。在此不再讨论关联规则挖掘算法，因为有许多现有的算法可以完成此任务，如Apriori、DHP算法等。

2  概括规则与具体规则
从关联规则挖掘过程可知，由一个k-频繁项最多可能产生2k-2条规则[10]，因此关联规则挖掘会产生大量规则。但在大量规则中，有些规则与另外一些规则相比只有微小变化，它们的出现没有带来更多新知识。例如：
R1: Job = yes → Loan = approved  
[sup = 60%, conf = 90%]
R2:Job=yes,Credit_history=good→Loan=approved
[sup = 40%, conf = 91%]
如果知道规则R1，那规则R2就没有太大意义，因为除了置信度略高一些，它提供了很少的额外信息。很明显，规则R1 比R2更概括、更简单。

R3: Feathers → Breathes 
[sup = 31%, conf = 100%]
R4: Feathers → Airborne, Breathes
  [sup = 16%, conf = 80%]
这两条规则中，R3覆盖的数据集是R4覆盖数据集的超集，可以说规则R3比R4更通用。为了区分这些规则，本文做如下定义： 
定义1: 如果X Y，则称规则X→A 比规则Y→A 更概括，反过来，称Y→A是比X→A更具体的规则，其中A 是1-数据项，X 是k-数据项集。 
定义2: 如果Y Z，则称规则 X→Y 比规则X→Z 更概括，反过来，称X→Z是比X→Y更具体的规则，其中X,Y,Z 是任意维数据项集。
一般来说，规则越具体，它覆盖的数据集就越小，其预测能力就越小。而用户一般希望看到预测能力较强、能反映数据集最基本关联关系的主要规则，即通用性更强的最概括规则。 
定义3: 最概括规则集(MGRS)是挖掘出关联规则的一个子集。MGRS中的规则比不在MGRS 中的规则更概括，并且如果规则X→Y MGRS,那么不存在X’→Y MGRS且X’ X, 也不存在规则X→Y’ MGRS 且Y’ Y。

3  分层表达关联规则
关联规则挖掘产生大量规则，给理解和使用挖掘结果带来了困难。出现这个问题的原因不仅仅由于大量规则，更主要是因为没有以更容易让用户理解的方式来表达这些规则。因为以传统规则列表形式表达关联规则，用户很难将这些信息片断综合在一起，全面理解数据集的基本关联关系；并且，只在一个层次上描述所发现的知识，这种单调的表达不适合人类理解知识[5]。
从数据库中发现的规则就像一本书中包含的知识，几百页的书包含了大量知识，但如果组织得好，读者很容易理解书中内容。书的内容通常按主题、分层次组织，一般每章先概括介绍本章主要内容，给读者一个总体印象，然后再分节具体阐述细节内容。分层组织的主要好处是读者可以自己控制阅读的内容，将注意力集中在他们感兴趣的部分。
对数据挖掘产生的大量规则，如果也按照从概括到具体的方式分层表达，应该会更有利于用户的理解。具体来说，先显示挖掘结果中最概括的关联规则，这些规则能描述出领域知识的主要内容，之后，如果用户对某些概括规则感兴趣，再根据用户要求逐层显示更具体的规则。

3.1  最概括规则集
分层表达关联规则的关键是找出其最概括规则集(MGRS)。从关联规则挖掘过程可以知道，如果规则A→BC 出现在挖掘结果中，规则A→B 也一定出现在挖掘结果中[12]。换句话说，如果A Z，若规则 X→Z 出现在挖掘结果中，规则 X→A 一定出现在结果中。而按上节定义，规则X→A 比X→Z 更概括。因此，发现最概括规则时，只需要从右侧只有一个数据项的规则中查找。
为了发现最概括规则集，先从挖掘结果中选出右侧只有一个数据项的规则，根据右侧数据项的值将选出的规则分类，再分别找出每类规则中的最概括规则，将全部最概括规则合并在一起，代表原始规则集中最通用的关联关系。

3.2  广度优先搜索最概括规则
对于同一类中的规则，其结果数据项相同，找出其中最概括规则的过程可用图1所示的树型结构描述。图1描述了X→E 规则所有决定条件的可能组合。图中低层结点的条件是双亲结点的超集。因此，如果低层结点存在，它代表的规则是比其双亲结点所代表的规则更具体。因此，低层结点相对于其双亲而言，比上层结点更具体；反过来，双亲结点是比它的全部孩子更概括的结点。

 
图1  X →E规则的决定条件

对图1所示的结构可以按照深度优先或广度优先两种方式进行自顶向下的搜索。 
按照深度优先搜索，如果根结点所代表的规则存在，该规则一定是最概括规则；若不存在，它的孩子将作为最概括规则的候选结点。例如，如果挖掘出的关联规则中没有出现A→E，就说结点A不是概括结点，那么提出它的所有孩子结点AB,AC, AD，并验证这些结点所代表的规则是否存在。如果 AB仍然不是最概括结点，继续验证结点 ABC 和 ABD。但是，如果之后经验证结点 C是最概括结点，那么结点 AC 和 ABC 实际上不可能是通用结点，因为 AC→E 和ABC→E 不应该是最概括规则。就是说，如果在验证结点 A 之后验证了结点B和C，并且B,C 都是概括结点，就没有必要去验证结点AB和AC。 
因此，本文基于广度优先搜索发现最概括规则集。用 k 表示树型结构自顶向下不同层次的层号。对于广度优先搜索，结点是逐层搜索和验证的。首先验证第一层中的结点(k=1)，如果某结点不是最概括结点，先不去验证它的孩子结点，而是到这一层的全部结点都验证完之后再提出下一层结点。例如，假设第一层结点全都不是最概括结点，就开始搜索第二层(k=2)，所有子结点 AB, AC, AD, BC, BD, CD作为最概括规则候选结点提出。

3.3  深度优先搜索具体规则
显示具体规则时会遇到一个新问题：同一条规则可能是多条概括规则的具体规则，怎么显示？ 
例如，若已知两条概括规则 A→C 和 B→C，那么规则 AB→C 既可以看作A→C 的具体规则，也可以看作是 B→C 的具体规则。
如果有千万条规则，显然用户不可能全看。可能用户只关注他感兴趣的规则，但系统预先不知道用户关注什么，所以无法提前决定规则 AB→C 应该作为 A→C 还是 B→C 的具体规则出现。 
本文只在用户有请求时才去发现更具体规则。这种方法合理是因为：找到某概括规则的具体规则的计算效率很高；即使显示了所有信息，用户也不可能全部查看[5]。 
查找某概括规则的具体规则，可采用深度优先搜索方式。如果一个结点是概括结点，那么它下面一层的所有超集结点都可以作为更具体规则候选结点。例如，如果用户向查看 A→E 的具体规则，那么应验证它的所有孩子结点 AB, AC, AD 所代表的规则是否存在，如果都存在，应将AB→E, AC→E 和 AD→E 作为 A→E 的具体规则显示。


4  实验及结果分析
实验使用的数据库4个来源于UCI数据集，1个是实际应用数据库。关联规则挖掘采用 Apriori算法，挖掘过程设定的最小支持度为 10%，最小置信度为 60%。实验结果如表1所示：



表1 实验结果 (Minsupp= 10%; Minconf = 60%)
数据集
名称    挖掘出规则数    最概括规则数    执行时间 (秒)
mushroom    4624    207    0.78
audiology    409    39    0.17
zoo    6480    99    0.56
tic-tac    102    23    0.08
sport    6169    320    3.49
表1中第4列的执行时间是发现最概括规则集所用时间，而具体规则是在用户请求时才去发现。实验结果表明，尽管挖掘出的规则非常多，但其最概括规则集一般很小，并且效率比较高。
 
图2  分层表达关联规则的例子
图2是一个分层表达关联规则的例子。系统首先显示给用户的只有第一层的最概括规则。如图所示，如果用户想查看某概括规则的具体规则，只要选中该规则，其第二层具体规则就显示出来；只要更具体的规则存在，单击上一层具体规则前面的加号，就可以查看更具体规则。

5  结束语
在实际应用中，如何使从数据集中挖掘出的关联规则容易被理解和使用对用户来说很重要。本文提出按照从概括到具体的方式分层表达关联规则，这种技术没有减少挖掘出的关联规则数目，而是以更直观的方式组织管理和表达这些规则，使用户先获得领域知识的总体印象，然后再查看具体细节。这种按层次表达关联规则的方式，使用户可以很容易地将注意力集中于感兴趣的规则，比规则列表更易于理解。

和MSDN一样    没什么用     呵呵

真是个好人，谢谢了！

多谢，我已下了

来这收益匪浅啊。。。。。
这么好的东西。。
顶！！！！！！！！！！

感谢兄弟分享！

[em8]辛苦了！[em8]

 [em2],好软件哦，感谢！

太好了，感谢！！！顶！！