数据挖掘基于约束的挖掘PPT.pptVIP

Apriori算法 — 例子 数据库 D 扫描 D C1 L1 L2 C2 C2 扫描 D C3 L3 扫描 D 如何生成候选集 假定 Lk-1 中的项按顺序排列 第一步: 自连接 Lk-1 insert into Ck select p.item1, p.item2, …, p.itemk-1, q.itemk-1 from Lk-1 p, Lk-1 q where p.item1=q.item1, …, p.itemk-2=q.itemk-2, p.itemk-1 q.itemk-1 第二步: 修剪 For all itemsets c in Ck do For all (k-1)-subsets s of c do if (s is not in Lk-1) then delete c from Ck 计算支持度为什么会成为一个问题？ 候选集的个数非常巨大 一笔交易可能包含多个候选集 生成候选集的例子 L3={abc, abd, acd, ace, bcd} 自连接 : L3*L3 abc 和 abd 得到 abcd acd 和 ace 得到 acde 修剪: ade 不在 L3中，删除 acde C4={abcd} 提高Apriori效率的方法 1.基于Hash的项集计数: 若 k-项集在hash-tree的路径上的一个计数值低于阈值，那他本身也不可能是频繁的。(157页图6-6) 2.减少交易记录: 不包含任何频繁k-项集的交易也不可能包含任何大于k的频繁集，下一步计算时删除这些记录。 3.划分: 一个项集要想在整个数据库中是频繁的，那么他至少在数据库的一个分割上是频繁的。 两次扫描数据。(157页图5-6) 4.抽样: 使用小的支持度+完整性验证方法。在小的抽样集上找到局部频繁项集，然后在全部数据集找频繁项集。 5.动态项集计数: 在添加一个新的候选集之前，先估计一下是不是他的所有子集都是频繁的。 Apriori 够快了吗? — 性能瓶颈 Apriori算法的核心: 用频繁的(k – 1)-项集生成候选的频繁 k-项集 用数据库扫描和模式匹配计算候选集的支持度 Apriori 的瓶颈: 候选集生成 巨大的候选集: 104 个频繁1-项集要生成 107 个候选 2-项集 要找尺寸为100的频繁模式，如 {a1, a2, …, a100}, 你必须先产生2100 ? 1030 个候选集 多次扫描数据库： 如果最长的模式是n的话，则需要 (n +1 ) 次数据库扫描 挖掘频繁集 不用生成候选集 频繁模式增长 (FP--增长)用Frequent-Pattern tree (FP-tree) 结构压缩数据库, 高度浓缩，同时对频繁集的挖掘又完备的 避免代价较高的数据库扫描 开发一种高效的基于FP-tree的频繁集挖掘算法 采用分而治之的方法学：分解数据挖掘任务为小任务 避免生成关联规则: 分别挖掘条件数据库 用 FP-tree挖掘频繁集 基本思想 (分而治之) 用FP-tree地归增长频繁集 方法 对每个项，生成它的 条件模式库, 然后是它的 条件 FP-tree 对每个新生成的条件FP-tree，重复这个步骤 直到结果FP-tree为空, 或只含维一的一个路径 (此路径的每个子路径对应的相集都是频繁集) 挖掘 FP-tree的主要步骤 为FP-tree中的每个节点生成条件模式库 用条件模式库构造对应的条件FP-tree 递归构造条件 FP-trees 同时增长其包含的频繁集 如果条件FP-tree直包含一个路径，则直接生成所包含的频繁集。 步骤1: 建立 FP-tree （159页图6-8） 从FP-tree的头表开始 按照每个频繁项的连接遍历 FP-tree 列出能够到达此项的所有前缀路径，得到条件模式库 步骤2:建立条件FP-tree进行挖掘（159页图6-9） 对每个模式库 计算库中每个项的支持度 用模式库中的频繁项建立FP-tree 为什么 频繁集增长 速度快？ 我们的性能研究显示 FP-growth 比Apriori快一个数量级, 同样也比 tree-projection 快。 原因 不生成候选集，不用候选测试。 使用紧缩的数据结构 避免重复数据库扫描 基本操作是计数和建立 FP-tree 树 FP-growth vs. Apriori: 相对于支持度的扩展性 Data set T25I20D10K FP-growth vs. Tree-Projection:相对于支持度的扩展性 Data set T25I20D100K 关联规则结果显示 (Table Form ) 关联规则可视化Using Plane Graph 关联规则可视化Using Rule Graph 第6章：从大数据库中挖