数据挖掘CHAPTER4数据挖掘原语语言和系统结构.docx

数据挖掘CHAPTER4数据挖掘原语语言和系统结构.docx

《数据挖掘CHAPTER4数据挖掘原语语言和系统结构.docx》由会员分享，可在线阅读，更多相关《数据挖掘CHAPTER4数据挖掘原语语言和系统结构.docx（25页珍藏版）》请在冰豆网上搜索。

数据挖掘CHAPTER4数据挖掘原语语言和系统结构

第四章数据挖掘原语、语言和系统结构

关于数据挖掘，一个流行的错误观点是：

期望数据挖掘系统能够自动地挖掘出埋藏在给定的大型数据库中的所有有价值的知识，而不需要人的干预或指导。

尽管有一个自动数据挖掘系统看上去是吸引人的，但在实践中，它将不可能涵盖大部分模式集。

所产生的全部模式的大小很容易超过给定的数据库。

让数据挖掘系统“放纵”地去发现模式，而不提供用户希望探查数据库的哪些部分，什么样的模式用户感兴趣，就是放纵数据挖掘“怪物”。

所发现的大部分模式与用户的分析任务无关。

此外，尽管有些模式与分析任务有关，但是它们可能太难理解，或缺乏有效性、新颖性或实用性——使得它们不令人感兴趣。

这样，产生、存放或提供由给定的数据库可能发现的所有模式既不现实，又不是所期望的。

一个更现实的做法是：

希望用户能够通过使用一组数据挖掘原语与数据挖掘系统通讯，以支持有效的和有成果的知识发现。

这组原语包括说明数据库的部分或用户感兴趣的数据集（包括感兴趣的数据库属性或数据仓库维），要挖掘的知识类型，用于指导挖掘过程的背景知识，模式评估兴趣度量和如何显示所发现的知识。

这些原语允许用户在知识发现时与数据挖掘系统通讯，从不同的角度和深度审查发现结果，并指导挖掘过程。

可以设计数据挖掘查询语言集成这些原语，允许用户自由地与数据挖掘系统交互。

数据挖掘查询语言也为建立友好的图形用户界面提供了基础。

此外，为了实现数据挖掘系统，一个精心设计的系统结构是非常重要的。

这将有助于数据挖掘系统与其它信息系统通讯，有利于它与整个信息处理环境的集成。

本章，你将详细学习数据挖掘原语，研究根据这些原则设计数据挖掘查询语言。

此外，你还将学习数据挖掘系统的系统结构。

4.1数据挖掘原语：

什么定义数据挖掘任务？

每个用户脑袋里都有一个数据挖掘任务，即，他想要进行的数据分析形式。

一个数据挖掘任务可以用数据挖掘查询的形式说明，它是数据挖掘系统的输入。

数据挖掘查询用以下原语定义，如图4.1所示。

图4.1定义数据挖掘任务或查询

⏹任务相关的数据：

这是要考察的数据库部分。

例如，假定你是AllElectronics的经理，负责美国和加拿大的销售。

特殊地，你想研究加拿大顾客的购买趋势。

你可能说明只提取加拿大顾客的购买数据，以及相关顾客的简要信息，而不是挖掘整个数据库。

你还可以说明挖掘过程中需要考虑的感兴趣的属性。

这些属性称为相关属性。

例如，如果你只关心顾客购买的商品与其年收入和年龄之间的可能联系，则关系item的属性name，关系customer的属性income和age可能被说明为挖掘任务相关的属性。

⏹要挖掘什么类型的知识：

这是说明要执行的数据挖掘函数，如特征、区别、关联、分类、聚类或演变分析。

例如，如果研究加拿大顾客的购买习惯，你可能选择挖掘顾客和他们喜爱买的商品之间的关联规则。

⏹背景知识：

用户可以说明背景知识，或关于挖掘领域的知识。

对于指导知识发现过程和评估发现的模式，这些知识是非常有用的。

有多种类型的背景知识。

本章，我们将注意力集中在一种称作概念分层的流行的背景知识上。

概念分层是有用的，它允许在多个抽象层上挖掘数据。

其它例子包括用户对数据联系的确信。

这些根据模式的非预期程度（这里，非预期的模式被认为是感兴趣的）或预期程度（这里，验证了某种用户假定的模式是有趣的）评估发现的模式。

图4.2说明数据挖掘任务的原语

⏹兴趣度度量：

这些功能用于将不感兴趣的模式从知识中分开。

它们可以用于指导挖掘过程，或在挖掘之后，评估发现的模式。

不同类型的知识需要不同的兴趣度度量。

例如，对于关联规则，兴趣度度量包括支持度（出现规则模式的任务相关元组所占的百分比）和置信度（规则的蕴涵强度估计）。

其支持度和置信度小于用户指定的阈值的规则被认为是不感兴趣的。

⏹发现模式的提供和可视化：

这涉及发现模式的显示形式。

用户可以选择不同的知识表现形式，如规则、表、图、判定树和数据方。

下面，我们仔细考察这些原语。

这些原语的说明总结在图4.2中。

4.1.1任务相关的数据

第一个原语是说明待挖掘的数据。

通常，用户感兴趣的只是数据库的一个子集。

不加区分地挖掘整个数据库是不现实的，特别是由于所产生的模式可能随数据库的大小指数地增长，使得挖掘过程效率很低。

此外，所发现的许多模式与用户的兴趣无关。

在关系数据库中，任务相关的数据集可以通过涉及如选择、投影、连接和聚集等操作的关系查询来收集。

这种数据提取可以认为是数据挖掘任务的一个“子任务”。

数据收集过程产生一个新的数据关系，称作初始数据关系。

初始数据关系可以根据查询中指定的条件排序或分组。

在用于数据挖掘分析之前，数据可能被清理或转换（例如，在某些属性上聚集）。

初始关系可以对应于，也可以不对应于数据库中的物理关系。

由于虚拟关系在数据库领域称为视图，这种用于数据挖掘的任务相关的数据集称作可挖掘的视图。

例4.1如果数据挖掘任务是研究在AllElectronics经常购买的商品和加拿大顾客之间的关联，则任务相关的数据可以由以下信息指定：

⏹所用的数据库或数据仓库的名字（如，AllElectronics_db），

⏹包含相关数据的表或数据方的名字（如，item,customer,purchass和item_sold），

⏹选择相关数据的条件（如，提取关于当年在加拿大进行购买的数据），

⏹相关的属性或维（如，来自item表的name和price，来自customer表的income和age）。

此外，用户可能说明提取的数据按某些属性分组，如“groupbydate”。

给出这些信息，可以用一个SQL查询提取任务相关的数据。

在数据仓库中，数据通常存放在称为数据方的多维数据库中。

数据方可以使用多维数组结构、关系结构或二者的结合来实现，我们在第2章已讨论。

任务相关的数据集可以通过基于条件的过滤，数据方的切片（对于给定的属性值提取数据）或切块（提取若干片的交）来指定。

注意，在数据挖掘查询中，数据选择条件可以在比数据库或数据仓库中的数据更高的概念层上。

例如，用户可以使用概念type=“homeentertainment”在AllElectronics的商品上指定选择，尽管数据库中的商品可能不是按类型存放，而是按较低层的概念，如“TV”、“CD播放机”或“VCR”存放。

在商品上的概念分层将“homeentertainment”说明为较高层概念，由较低层概念{“TV”,“CD播放机”,“VCR”}组成，可以用于收集任务相关的数据。

对于用户，说明相关属性或维可能是一个困难的任务。

对于可能进行的探查，什么属性是感兴趣的，用户可能只有一个粗略的想法。

此外，在说明待挖掘的数据时，用户可能会忽略与之有很强语义联系的数据。

例如，某些商品的销售可能与诸如圣诞节或鬼节，或特定的人群等特定的事件密切相关，但这些因素可能没有包含在一般的数据分析请求中。

对于这种情况，有些机制可以帮助给出任务相关数据的更精确说明。

此外，搜索具有强语义联系属性的技术也可以用来加强用户说明的初始数据集。

4.1.2要挖掘的知识的类型

说明挖掘什么类型的知识是非常重要的，因为这决定使用什么数据挖掘功能。

知识类型包括概念描述（特征和区别）、关联、分类、预测、聚类和演变分析。

对于给定的数据挖掘任务，除说明要挖掘的知识类型外，用户可能想进一步说明和提供所有发现模式必须匹配的模式模板。

这些模板，或元模式（又称元规则或元查询）可以用于指导发现过程。

这些元模式的使用在以下例子中解释。

例4.2一个研究AllElectronics的顾客购买习惯的用户可能选择挖掘如下形式的关联规则

其中，X是关系customer的关键字；P和Q是谓词变量，它们可以被例示为作为任务相关数据的一部分说明的相关属性或维；而W，Y和Z是对象变量，它们可以在关于顾客X的谓词上取值。

关联规则的搜索限于匹配给定的元规则的那些，如

[2.2%,60%]（4.1）

和

[1.4%,70%]（4.2）

前一个规则是说30多岁的顾客，其年收入在40K和49K之间，多半（置信度60%）会买VCR，这种情况占事务总数的2.2%。

后一个规则是说20多岁的学生多半（置信度70%）会买计算机，这种情况占事务总数的1.4%。

4.1.3背景知识：

概念分层

背景知识是关于挖掘领域的知识，它们在发现过程中是非常有用的。

本小节，我们将我们的注意力放在一种简单但功能很强，称作概念分层的背景知识上。

概念分层允许在多个抽象层上发现知识。

正如第2章介绍的，概念分层定义了一组由低层概念集到高层概念集的映射。

一个关于location维的概念分层如图4.3所示，将较低层的概念（即，城市）映射到较高层更一般的概念（即，国家）。

注意，概念分层结构以组织成树的结点集表示，其中每个结点本身代表一个概念。

一个特殊的结点all作为树根，它表示给定维的最一般的值。

如果不显式给出，它是蕴涵的。

该概念分层结构由4层组成。

为方便计，概念分层结构中的层自顶向下编号，结点all为0层。

在我们的例子中，层1表示概念country，而层2和3分别表示概念province_or_state和city。

概念分层的树叶对应于维的原始数据值（原始层数据）。

这些是给定属性或维的最细节的值或概念。

尽管概念分层结构通常用树形分类的形式表示，但它们也可以形成一般的格或偏序。

图4.3维location的一个概念分层

概念分层是一种有用的背景知识形式，它使得原始数据可以在较高的、一般化的抽象层上进行处理。

数据的泛化或上卷可以通过用较高层概念（如location的国家，age的诸如“20...39”，“40...59”和“60+”这样的区间）替换较低层的概念（如location的城市，age的数值值）来实现。

这使得用户可以在更有意义、更明显的抽象层观察数据，使得发现的模式更易于理解。

泛化的另一个优点是压缩数据。

与在大的、未压缩的数据上挖掘相比，在压缩的数据集上挖掘需要较少的I/O操作，并将更有效。

如果结果数据过于一般化，概念分层也允许特化或下钻，概念值用较低层的概念替代。

使用上卷和下钻，用户可以用不同的视图来观察数据，洞察隐藏的数据联系。

概念分层结构可以由系统用户、领域专家或知识工程师提供。

通常，这些映射是面向特定数据或应用的。

正如我们在下面将看到的，许多概念分层结构蕴涵在数据库模式中。

此外，概念分层结构通常可以自动地发现，或根据数据分布的统计分析动态地提炼。

概念分层结构的自动产生已在第3章详细讨论。

对于给定的属性或维，根据不同用户的观点，可能有多个概念分层结构。

例如，假定AllElectronics的地区销售经理想要研究不同地方顾客的购买习惯，对于这样的挖掘任务，图4.3关于location的概念分层结构应当是有用的。

然而，市场部经理可能更希望location按语言组织，以利于商业广告的分发。

概念分层有4种类型。

第2章介绍了最常用的类型——模式分层和集合分组分层，这里我们将简略回顾。

此外，我们还研究操作导出的分层和基于规则的分层。

模式分层：

模式分层（或更严格地，模式定义的分层）是数据库模式属性间的全序或偏序。

模式分层可以形式地表示属性间的语义联系。

通常，一个模式分层指定了数据仓库的一个维。

例4.3给定关系模式address，包含属性street,city,province_or_state和country，我们可以用如下全序定义location模式分层结构：

streetcityprovince_or_statecountry

这意味street的概念层低于city，city低于province_or_state，而province_or_state低于country。

模式分层提供元数据（即，关于数据的数据）信息。

使用全序或偏序的说明比列出所有街道、省或州、国家的等价定义要简明得多。

集合分组分层：

集合分组分层将给定属性或维的值组织成常量组或区间值。

组之间可以定义全序或偏序。

当两种类型的分层结构结合时，集合分组分层可以用于精炼或丰富模式定义的分层。

通常，集合分组分层用于定义对象联系的小集合。

例4.4属性age的集合分组分层结构可以用范围来指定,如下所示

{young,middle_aged,senior}all（age）

{20...39}young

{40...59}middle_aged

{60...89}senior

注意，正如3.5节解释的，类似的说明也可以自动产生。

操作导出的分层：

操作导出的分层是根据用户、专家或数据挖掘系统说明的操作分层。

操作可能包括信息编码串的解码，由复杂数据对象提取信息和数据聚类。

例4.5一个e-mail地址或WWW的URL可能包含涉及部门、学校（或公司）和国家的层次信息。

可以使用解码操作来提取信息，形成概念分层。

例如，e-mail地址“dmbook@cs.sfu.ca”给出部分序“login-namedepartmentuniversitycountry”，形成了e-mail地址的一个概念分层。

类似地，可以对URL地址“http:

//www.cs.sfu.ca/research/DB/DBMiner”解码，提供一个形成URL的概念分层的基。

基于规则的分层：

基于规则的分层是指整个概念分层或它的一部分由一组规则定义，并且根据当前数据库数据和规则定义动态地计算。

例4.6下面的规则可以用于将AllElectronics的商品分类为low_profit_margin,medium_profit_margin和high_profit_margin。

其中，商品X的价格差定义为X的销售价格和实际价格的差。

价格差小于$50的商品定义为low_profit_margin商品，获利$50和$250之间的商品定义为medium_profit_margin商品，而获利多于$250的商品定义为high_profit_margin商品。

low_profit_margin（X）price（X,P1）cost（X,P2）（（P1-P2）$50）

medium_profit_margin（X）price（X,P1）cost（X,P2）（（P1-P2）$50）（（P1-P2）$250）

high_profit_margin（X）price（X,P1）cost（X,P2）（（P1-P2）$250）

使用概念分层进行数据挖掘在本书的剩余章节介绍。

4.1.4兴趣度度量

尽管任务相关的数据和要挖掘的知识类型（例如，特征、关联等）的说明可以大幅度减少产生规则的数量，数据挖掘过程仍然可能产生大量模式。

通常，这些模式中只有一小部分是特定用户感兴趣的。

这样，用户需要进一步限制挖掘过程产生的不感兴趣的模式数量。

这可以通过设定兴趣度度量来实现。

兴趣度度量评估模式的简洁性、确定性、实用性和新颖性。

本小节，我们研究模式兴趣度的客观度量。

这种客观度量基于模式的结构和统计。

一般地，每一种度量都有一个可以由用户控制的阈值。

不满足阈值的规则被认为是不感兴趣的，因而不作为知识向用户提供。

简洁性：

模式兴趣度的一个重要因素是对于人的理解，模式的总体简洁性。

模式简洁性的客观度量可以看作模式结构的函数，用模式的二进位位数，或属性数，或模式中出现的操作符数来定义。

例如，一个规则的结构越复杂，它就越难解释，从而就可能对它没多少兴趣。

例如，规则长度是一种简洁性的度量。

对于用合取范式（即，合取谓词的集合）表达的规则，规则的长度简单地定义为规则中合取符的个数。

关联、区别或分类规则的长度超过用户定义的阈值时，被认为是不感兴趣的。

对于以判定树表达的模式，简洁性可以是树叶或树结点的个数的函数。

确定性：

每个发现的模式都应当有一个表示其有效性或“值得信赖性”的确定性度量。

对于形如“AB”的关联规则，其确定性度量是置信度。

给定一个任务相关的数据元组集合（或事务数据库事务的集合），“AB”的置信度定义为：

confidence

（4.3）

例4.7假定任务相关数据由AllElectronics的计算机部的事务数组成。

一个置信度为85%的关联规则

（4.4）

意味买计算机的顾客85%也买软件。

置信度为100%或1意味在数据分析时，该规则总是正确的。

这种规则称为准确的。

对于分类规则，置信度称为可靠性或准确性。

分类规则提出了一个模型，将目标类（如，bigSpenders）的对象或元组与对比类（如，budgetSpenders）的对象相区别。

低可靠性表明不正确的分类，对比类的许多对象也在目标类中。

规则的可靠性也称为规则的强度，规则的质量，确定性因子和区分权。

实用性：

一个模式的潜在的有用性是定义其兴趣度的一个重要因素。

它可以用一个实用性函数（如支持度）来评估。

关联模式的支持度是模式为真的任务相关的元组（或事务）所占的百分比。

对于形如“AB”的关联规则，支持度定义为

support

（4.5）

例4.8假定任务相关数据由AllElectronics的计算机部的事务数组成。

一个支持度为30%的关联规则（4.4）意味计算机部的所有顾客的30%同时购买了计算机和软件。

同时满足用户定义的最小置信度阈值和最小支持度阈值的关联规则称为强关联规则，并认为是有趣的。

具有较低支持度的规则多半是提供噪音，少见或例外的情况。

支持度定义的分子通常称作规则计数。

我们常常显示该值而不是支持度。

支持度容易由它导出。

特征和区分描述基本上是泛化元组。

其代表的元组数少于整个任务相关元组数的Y%的泛化元组都被视为噪音。

因此，这样的元组不向用户提供。

Y值称为噪音阈值。

新颖性：

新颖的模式是那些提供信息或提高给定模式集性能的模式。

例如，一个数据例外可以认为是新颖的，它不同于根据统计模型和用户的信念所期望的模式。

检测新颖性的另一策略是删除冗余模式。

如果发现的规则被已在知识库中或导出的规则集中的另一规则所蕴涵，则两个规则都要重新审查，以便去掉潜在的冗余。

使用概念分层挖掘可能导致大量冗余规则。

例如，假定下列关联规则使用图4.3关于location的概念分层，由AllElectronics的数据库中挖掘出：

[8%,70%]（4.6）

[2%,71%]（4.7）

假定规则（4.6）具有8%的支持度和70%的置信度。

可以预料规则（4.7）也大约有70%的置信度，因为代表的Montreal所有数据对象也是Canada的数据对象。

规则（4.6）比规则（4.7）更一般，因此我们预料前一个规则比后一个规则更常出现。

结果，两个规则不应当具有相同的支持度。

假定的销售大约有四分之一来自Montreal。

我们预料涉及Montreal的规则的支持度是涉及Canada的规则的支持度的四分之一。

换一句话说，我们预料规则（4.7）的支持度为

。

如果规则（4.7）的实际置信度和支持度是可预料的，则它应当是冗余的，因为它不提供附加的信息，并且一般性不如规则（4.6）。

这些思想在第6章关于关联规则挖掘时进一步讨论。

数据挖掘系统应当允许用户自由地、交互地说明、测试和修改兴趣度度量和它们对应的阈值。

除了以上我们研究的基本度量之外，还有许多其它客观度量。

除了客观的统计度量之外，主观度量同样存在。

主观度量考虑用户对数据间联系的信赖。

兴趣度度量更详尽的讨论将在贯穿本书。

图4.4发现的模式的表示和可视化的各种形式

4.1.5发现模式的提供和可视化

“如何‘观看’发现的模式？

”数据挖掘要成为有效的，数据挖掘系统就应当能够以多种形式显示所发现的模式，如规则、表、交叉表、饼图或条图、判定树、数据方或其它可视化表示（图4.4）。

允许发现的模式以多种形式表示可以帮助不同背景的用户识别有趣的模式，并与系统交互或指导进一步的发现。

用户应当能够指定用于显示发现模式的表示形式。

概念分层的使用在帮助用户观察发现的模式中起重要作用。

使用概念分层挖掘允许发现的模式在高层概念表示，这可能比用原始数据概念表达的规则（如，函数或多值依赖规则，或整体性限制）更容易理解。

此外，数据挖掘系统应当能够利用概念分层实现下钻、上卷操作，使得用户可以在多个抽象级审视发现的模式。

转轴（旋转）、切片和切块操作也能帮助用户从不同视角观察泛化数据和知识。

这些操作已在第2章详细讨论。

一个数据挖掘系统应当对任意维，以及每个维的特定值提供这些交互操作。

对于特定的知识类，某些表示形式可能比其它的更合适。

例如，对于特征描述，泛化规则和对应的交叉图或饼图/条图是好的表示形式；而对于分类，判定树是通常的选择。

诸如4.1.4小节介绍的兴趣度度量可以显示在每个发现的模式上，帮助用户识别提供有用知识的那些模式。

4.2一种数据挖掘查询语言

“为什么有一个数据挖掘查询语言很重要？

”回忆一下，数据挖掘系统的期望特点是能够支持特别的和交互的数据挖掘，以利于灵活和有效的知识发现。

可以设计数据挖掘查询语言，来支持这种特点。

通过观察关系数据库系统的历史，也可以明白设计一个好的数据挖掘查询语言的重要性。

关系数据库系统已经主宰数据库市场几十年。

关系查询语言的标准化始于关系数据库开发的早期阶段，广泛认为它对关系数据库的成功起了重要作用。

尽管每个商品化的关系数据库系统都有自己图形用户界面，但是每个界面下面的核都是标准关系查询语言。

关系查询语言的标准化为关系数据库系统的发展和进化提供了基础。

它促进了信息交换和技术转换，推动了关系数据库技术的商品化和广泛接受。

数据库系统最近的标准化活动，如涉及SQL-3的工作，进一步说明具有一种标准的数据库语言对于数据库系统的成功开发和商品化的重要性。

因此，具有一个好的数据挖掘查询语言将有助于数据挖掘系统平台开发标准化。

设计一个易理解的数据挖掘语言是一个挑战，因为数据挖掘任务涉及面宽。

由数据特征到挖掘关联规则、数据分类和进化分析，每种任务都有不同的需求。

有效的数据挖掘语言的设计需要深入理解各种数据挖掘任务的能力、限制和潜在机制。

如何设计数据挖掘查询语言？

在本章的前面，我们考虑了用数据挖掘查询形式的定义数据挖掘任务的原语。

这些原语说明：

⏹待挖掘的相关数据集

⏹要挖掘的数据类型

⏹用于发现过程的背景知识

⏹模式评估的兴趣度度量和阈值

⏹可视化发现模式的期望表示

基于这些原语，我们设计一种数据挖掘查询语言DMQL。

DMQL是DataMiningQueryLanguage（数据挖掘查询语言）的缩写。

DMQL允许在多个抽象层上，由关系数据库和数据仓库进行多种类型知识的特殊挖掘。

该语言采用类似于SQL的语法，因此它易于和关系查询语言SQL集成在一起。

DMQL的语法采用扩充的BNF文法定义，其中“[]”表示0次或1次出现，“{}”表示0次或多次出现，黑体字表示关键词。

由4.2.1到4.2.5小节介绍每种数据挖掘原语的DMQL语法。

在4.2.6小节，我们用该语法给出一个数据挖掘查询的例子。

语言的顶层概述如图4.5所示。

:

:

=;{}

:

:

=

|

|

:

:

=

usedatabase|usedatawarehouse

{usehierachyfor}