数据挖掘CHAPTER5概念描述特征与比较Word文件下载.docx
《数据挖掘CHAPTER5概念描述特征与比较Word文件下载.docx》由会员分享，可在线阅读，更多相关《数据挖掘CHAPTER5概念描述特征与比较Word文件下载.docx（45页珍藏版）》请在冰点文库上搜索。
相反，对于概念形成，数据库属性可以是各种各样的数据类型，包括数值的、非数值的、空间的、文本的或图象的。
此外，数据库中属性的聚集也可能包括复杂的数据类型，如非数值数据的集合，空间区域的合并，图象的合成，文本的集成，和对象指针分组等。
这样，由于可能的维和度量类型的限制，OLAP只表现为一种简单的数据分析模型。
需要时，数据库中的概念描述可以处理具有复杂数据类型的属性和它们的聚集。
用户控制与自动处理：
数据仓库中的联机分析处理纯是用户控制的过程。
维的选择和诸如下钻、上卷、切块和切片等OLAP操作的使用都由用户指挥和控制。
尽管在大部分OLAP系统中，用户控制的界面是相当友好的，但用户确实需要对每个维的作用有透彻的理解。
此外，为了找到一个满意的描述，用户需要使用一长串OLAP操作。
相反，数据挖掘系统中的概念描述努力成为更自动化的过程，帮助用户确定哪些维（或属性）应当包含在分析中，给定的数据应当泛化到什么程度，以便产生有趣的数据汇总。
正如第2章所讨论的，最近，数据仓库和OLAP技术正在朝着处理更复杂的数据类型和嵌入更多的知识发现机制方向进化。
随着技术的进一步发展，预期更多的描述性数据挖掘功能将集成到未来的OLAP系统中。
本章，你将学习概念描述的方法，包括多层泛化、汇总、特征和比较。
这些方法形成实现数据挖掘的两个主要功能模块的基础：
多层特征和比较。
此外，你还将考察以多种形式表示概念描述的技术，包括表、图表、图和规则。
5.2数据泛化和基于汇总的特征
数据库中的数据和对象通常包含原始概念层的细节信息。
例如，sales数据库中的item关系可能包含描述商品的低层信息，如item_ID,name,brand,category,supplier,place_made和price。
能够对大的数据集合进行汇总并在高层概念提供结果是有用的。
例如，圣诞节期间销售的大量商品的汇总提供这些数据的一般描述，对于销售和市场经理都是非常有帮助的。
这要求一个重要的数据挖掘功能：
数据泛化。
数据泛化是一个过程，它将大的、任务相关的数据集从较低的概念层抽象到较高的概念层。
大的数据集有效的、灵活的泛化方法可以分为两类：
（1）数据方（或OLAP）方法，和
（2）面向属性归纳方法。
数据方方法已在第2章介绍。
本节，我们介绍面向属性的归纳方法。
5.2.1面向属性归纳
对于数据泛化和基于汇总的特征，面向属性的归纳于1989年首次提出，比数据方方法的提出早几年。
数据方方法可以认为是基于数据仓库的、面向预计算的、物化视图的方法。
它在OLAP或数据挖掘查询提交处理之前，脱机计算聚集。
另一方面，面向属性的归纳，至少在它被提出时，是面向关系数据库查询、基于泛化的、联机的数据分析处理技术。
然而，根据联机聚集和脱机预计算区分两种方法并非是固有的。
数据方中有些聚集也可以联机计算，而多维空间的脱机预计算也可以加快面向属性的归纳速度。
让我们先介绍面向属性的归纳方法。
然后，我们将讨论该方法的细节，它的变形和扩充。
面向属性归纳的基本思想是：
首先使用关系数据库查询收集任务相关的数据；
然后，通过考察任务相关数据中每个属性的不同值的个数，进行泛化。
泛化或者通过属性删除，或者通过属性泛化进行。
聚集通过合并相等的泛化元组，并收集它们对应的计数值进行。
这压缩了泛化后的数据集合。
结果泛化关系可以映射到不同形式，如图表或规则，提供用户。
下面一系列例子解释面向属性归纳的处理过程。
例5.1用DMQL说明特征数据挖掘查询。
假定用户想描述Big-University数据库中研究生的一般特征。
给定的属性有name,gender,major,birth_place,residence,phone#（电话号码）和gpa（平均等级分）。
该特征的数据挖掘查询可以用数据挖掘查询语言DMQL表示如下：
useBig_University_DB
minecharacteristicsas“Science_Students”
inrelevancetoname,gender,major,birth_place,birth_date,residence,phone#,gpa
fromstudent
wherestatusin“graduate”
我们将看看这个典型的数据挖掘查询例子如何使用面向属性的归纳挖掘特征描述。
“面向属性归纳的第一步做什么？
”首先，在面向属性归纳之前进行数据聚焦。
这一步对应于第4章介绍的说明任务相关数据（或用于分析的数据），根据数据挖掘查询提供的信息进行数据收集。
由于数据挖掘查询通常只涉及数据库的一部分，选择相关的数据集不仅使得挖掘更有效，而且与在整个数据库挖掘相比，能够产生更有意义的规则。
对于用户来说，指定相关的数据集（即，挖掘的属性，如DMQL的inrelevanceto子句所指出的）可能是困难的。
有时，用户只能选择少量他感到可能重要的属性，而遗漏在描述中可能起作用的其它属性。
例如，假定birth_place由属性city,province_or_state和country定义。
这些属性，用户只想到说明city。
为了能在birth_place维上泛化，定义该维的其它属性也应当包括进来。
换一句话说，系统自动地包括province_or_state和country作为相关属性，使得city可以在归纳过程中泛化到较高的概念层。
另一个极端是，用户可能引进太多属性，如用“inrelevanceto*”指定所有可能的属性。
在这种情况下，被from子句说明的关系的所有属性将包含在分析中。
许多属性对于有趣的描述是没有用的。
5.3节介绍一种方法，通过过滤掉统计不相关或弱相关属性来处理这种情况。
“子句‘wherestatusin“graduate”’是什么意思？
”该where子句意味在属性status上存在概念分层。
这种概念分层将status的原始层的值，如”M.Sc”,”M.A”,M.B.A”,”Ph.D”,”B.Sc”,”B.A”组织成较高层次的概念，如”graduate”和”undergraduate”。
这种概念分层在传统的关系查询语言中没有，而在数据挖掘语言中是普遍的。
例5.2转化数据挖掘查询为关系查询。
例5.1的数据挖掘查询被转换成如下关系查询，收集任务相关的数据集。
useBig_university_DB
selectname,gender,major,birth_place,birth_date,residence,phone#,gpa
wherestatusin{”M.Sc”,”M.A”,M.B.A”,”Ph.D”}
转换后的查询在关系数据库Big_university_DB上执行，返回表5.1所示数据。
该表称作（任务相关）初始工作关系，是要进行归纳的数据。
注意，事实上每个元组是属性-值对的合取。
因此，我们可以认为关系的元组是合取规则，而关系上的归纳是这些规则的一般化。
表5.1：
初始工作关系：
任务相关数据集合
name
gender
major
birth_place
birth_date
residence
phone#
gpa
JimWoodman
ScottLachance
LauraLee
...
M
F
CS
physics
Vancouver,BC,Canada
Montreal,Que,Canada
Seattle,WA,USA
8-12-76
28-7-75
25-8-70
3511,MainSt.,Richmand
345,IstAve.,Vancouver
125,AustinAve.,Burnaby
687-4598
253-9106
420-5232
3.67
3.70
3.83
“对于面向属性归纳，现在数据已经准备好，如何进行面向属性归纳？
”面向属性归纳的基本操作是数据泛化，它可以用两种方法之一在初始关系上进行：
属性删除，属性泛化。
属性删除基于如下规则：
如果初始工作关系的某个属性有大量不同的值，但是
（1）在此属性上没有泛化操作符（例如，对该属性没有定义概念分层），或者
（2）它的较高层概念用其它属性表示，则该属性应当从工作关系中删除。
该规则的理由何在？
一个属性-值对表示泛化元组或规则的一个合取。
删除一个合取就删除了一个限制，从而泛化了规则。
如果是情况1，属性具有大量的不同值，但对它没有泛化操作符，应当将属性删除，因为它不能被泛化，保留它就意味着保留与产生的简洁规则相矛盾的大量不同值。
另一方面，考虑情况2，属性的高层次概念用其它属性表示。
例如，假定该属性是street，它的高层次概念被属性（city,province_or_state,country）表示。
删除street等价于使用泛化操作。
该规则对应于机器学习中示例学习的删除条件。
属性泛化基于如下规则：
如果初始工作关系的某个属性有大量不同的值，并且该属性上存在泛化操作符，则应当选择该泛化操作符，并将它用于该属性。
该规则基于如下理由：
使用泛化操作符泛化工作关系中元组的属性值或规则，将使得规则涵盖更多的原数据元组，从而泛化了它所表示的概念。
这对应于泛化规则，在示例学习中称为沿泛化树攀升或沿概念树攀升。
属性删除和属性泛化两个规则都表明，如果某属性有大量的不同值，应当进行进一步泛化。
这就提出了一个问题：
多大才算“属性具有大量不同值”？
这取决于属性或应用，有的用户愿意让有些属性留在较低的抽象层，而另一些用户愿意将它们泛化到较高的抽象层。
控制将属性泛化到多高的抽象层通常是相当主观的。
该过程的控制称为属性泛化控制。
如果属性泛化得“太高”，可能导致过分泛化，产生的规则可能没有多少信息。
另一方面，如果属性不泛化到“足够高的层次”，可能泛化不足，得到的规则可能也不含多少信息。
这样，面向属性的泛化应当把握好尺度。
有一些方法控制泛化过程。
我们介绍两种常用的方法。
第一个技术称作属性泛化阈值控制，或者对所有的属性设置一个泛化阈值，或者对每个属性设置一个阈值。
如果属性的不同值个数大于属性泛化阈值，则应当进行进一步的属性删除或属性泛化。
典型地，数据挖掘系统有一个省缺的属性阈值（取值范围一般为2到8），并且也允许用户或专家修改该阈值。
如果用户感到对于一个特定的属性，泛化达到的层次太高，他可以加大阈值；
这对应于沿着属性下钻。
为进一步泛化关系，用户也可以减小属性阈值；
这对应于沿属性上卷。
第二种技术称作泛化关系阈值控制，为泛化关系设置一个阈值。
如果泛化关系中不同元组的个数超过该阈值，则应当进行进一步泛化；
否则，不再进一步泛化。
这样的阈值也可以在数据挖掘系统中预先设定（通常取值范围为10到30），或者由用户或专家设置，并且允许调整。
例如，如果用户感到泛化的关系太小，他可以加大阈值；
这意味下钻。
否则，为进一步泛化关系，他可以减小阈值；
这意味上卷。
这两种技术可以顺序使用：
首先使用属性泛化阈值控制技术泛化每个属性，然后使用关系阈值控制进一步压缩产生的关系。
无论使用哪种泛化控制技术，都应当允许用户调整泛化阈值，以便得到有趣的概念描述
在许多面向数据库的归纳过程中，用户感兴趣的是在不同的抽象层得到数据的量化或统计信息。
这样，在归纳过程中收集计数和其它聚集值是非常重要的。
概念上讲，这件事可以用如下办法做。
一个特殊的度量或数值属性为聚集函数count，它与每个数据库元组相关联。
对于初始工作关系的每个元组，它的值被初始化为1。
通过删除属性和属性泛化，在初始关系中的元组可能被泛化，导致相等的元组分组。
在这种情况下，形成一组的所有相等元组应当合并成一个元组。
泛化的元组的新计数设置成初始关系中被新的泛化元组代表的元组的计数和。
例如，假定根据面向属性归纳，初始关系中52个数据元组被泛化成同一个元组T。
即，这52个元组的泛化产生元组T的52个相等的实例。
这52个相等的元组合并，形成T的一个实例，其计数设置成52。
其它流行的聚集函数包括sum和avg。
对于一个给定的泛化的元组，sum包含产生该泛化元组的初始关系的给定数值属性值的和。
假定元组T包含sum（units_sold）作为聚集函数，元组T的sum值应当设置为53个元组的units_sold总和。
聚集函数avg根据公式avg=sum/count计算。
例5.3面向属性归纳。
这里，我们看看面向属性归纳如何在例5.2得到的初始工作关系表5.1上进行归纳。
对于关系的每个属性，泛化过程如下：
1.name：
由于name存在大量不同值，并且其上没有泛化操作符，该属性被删除。
2.gender：
由于gender只有两个不同值，该属性保留，并且不对其进行泛化。
3.major：
假定已定义了一个概念分层，允许将属性major泛化到值{arts&
science,engineering,business}。
还假定该属性的泛化阈值设置为5，并且初始关系中major有20不同值。
根据属性泛化和属性泛化控制，沿概念分层向上攀升，major被泛化。
4.birth_place：
该属性有大量不同值，因此应当泛化它。
假定存在birth_place的概念分层，定义为city<
province_or_state<
country。
如果初始工作关系中country的不同值个数大于属性泛化阈值，则birth_place应当删除，因为尽管存在泛化操作符，泛化阈值也不会满足。
如果假定country的不同值个数小于泛化阈值，则birth_place应当泛化到birth_country。
5.birth_date：
假定存在概念分层，可以将birth_date泛化到age，而age到age_range，并且age_range的不同值（区间）数小于对应的属性泛化阈值，则应当对birth_date进行泛化。
6.residence：
假定residence被属性number,street,residence_city,residence_province_or_state和residence_country定义。
number和street的不同值多半很多，因为这些概念的层次相当低。
因此，number和street应当删除，将residence泛化到residence_city，其包含较少的不同值。
7.phone#：
从名字可以看出，该属性包含太多不同值，因此应当在泛化中删除。
8.gpa：
假定存在gpa的概念分层，将等级分分成数值区间，如{3.75-4.0,3.5-3.75,...}，它又被用描述值{excellent,verygood,...}分组。
这样，该属性可以被泛化。
泛化过程将产生相等元组的组。
例如，表5.1的前两个元组被泛化成相同的元组（即，表5.2的第一个元组）。
这些相同的元组被合并成一个，同时累计它们的计数值。
这一过程导致表5.2所示的泛化关系。
表5.2：
通过对表5.1的数据进行面向属性归纳得到的泛化关系
birth_country
age_range
residence_city
count
Science
Canada
Foreign
20...25
25...30
Richmond
Burnaby
very_good
excellent
16
22
根据OLAP的术语，我们可以把count看作度量，而其它属性看作维。
注意，聚集函数，如sum，可以用于如salary,sales等数值属性。
这些属性称为度量属性。
在下面的小节，提供泛化的实现技术和方法。
5.2.2面向属性归纳的有效实现
“面向属性的归纳如何实际实现？
”前一小节介绍了面向属性的归纳。
一般过程总结在图5.1中。
算法的有效性分析如下：
⏹算法的第1步基本上是关系查询，将任务相关的数据收集到工作关系W中。
其有效性依赖于所用的查询处理方法。
有大量成功实现的商品化数据库系统，该步可望具有很好的性能。
⏹第2步收集初始关系上的统计。
这最多需要对该关系扫描一次。
对每个属性计算最低期望层和确定映射对（v,v’）依赖于每个属性的不同值数量，它比初始关系的元组数n小。
算法：
面向属性归纳。
根据用户的数据挖掘请求，在关系数据库上挖掘泛化特征。
输入：
（i）关系数据库DB；
（ii）数据挖掘查询DMQuery；
（iii）属性表a_list（包含属性ai等）；
（iv）概念分层或属性ai上的泛化操作符的集合Gen（ai）；
（v）每个属性ai的泛化阈值a_gen_thresh（ai）。
输出：
主泛化关系P。
方法：
方法如下。
1．Wget_task_relevant_data（DMQuery,DB）；
//工作关系W存放任务相关的数据。
2．prepare_for_generalization（W）；
//该步实现如下。
（a）扫描W，收集每个属性ai的不同值。
（注意：
如果W很大，可以通过考察W的样本来做。
）
（b）对于每个属性ai，根据给定的或省缺的属性阈值，确定ai是否应当删除；
如果不删除，则计算它的最小期望层次Li，并确定映射对（v,v’），其中，v是W中ai的不同值，而v’是其对应的在层Li的泛化值。
3．Pgeneralization（W）；
通过用其在映射中对应的v'
替换W中每个值v，累计计数并计算所有聚集值，导出主泛化关系P。
这一步可以用两种方法有效地实现：
（a）对于每个泛化元组，通过二分检索将它插入主关系P中。
如果元组已在P中，则简单地增加它的计数值并相应地处理其它聚集值；
否则，将它插入P。
（b）在大部分情况下，由于主关系不同值的个数很少，可以将主关系编码，作为m-维数组，其中m是P中的属性数，而每个维包含对应的泛化属性值。
如果有的话，数组的每个元素存放对应的计数和其它聚集值（如果有的话）。
泛化元组的插入通过对应的数组元素上的度量聚集进行。
图5.1面向属性归纳的基本算法
⏹第3步导出主关系P。
这通过将泛化元组插入到P中完成。
W中有n个元组，P中有p个元组。
对于W中的每个元组t，根据导出的映射对替换它的属性值，产生泛化元组t’。
如果采用方法（a），每个t’需要O（logp）时间找到计数增值或插入位置。
这样，所有泛化元组总的时间复杂性为O（nlogp）。
如果采用方法（b），每个t’需要O
（1）时间找到计数增值元组。
这样，所有泛化元组的时间复杂性为O（n）。
许多数据分析任务需要考察很多维或属性。
例如，交互式数据挖掘系统可能动态地引入和测试属性，而不仅仅是挖掘查询中说明的那些属性。
高级的描述数据挖掘任务，如解析特征（5.3节讨论）,需要大量属性的属性相关分析。
此外，不太知道真正的相关数据集的用户可能简单地在挖掘查询中指定“inrelevanceto*”。
在这些情况下，聚集值的预计算将加快大量维或属性的分析。
因此，数据方实现是以上介绍的数据库实现的一种吸引人的替换。
面向属性归纳的数据方实现可以采用两种方法进行。
对给定的数据挖掘查询临时构造数据方：
该方法根据任务相关的数据集，动态地构造数据方。
如果任务相关的数据集太特殊，不能与任何预定义的数据方匹配，或者任务相关的数据集不太大时，该方法是所期望的。
由于这种数据方仅当查询提交之后才计算，构造这种数据方的主要动机是便于有效地下钻。
有了这种数据方，下钻到主关系层之下，只需要简单地从方中提取数据，或由存放在方中的某中间层稍做泛化，而不是从基本层数据进行泛化。
然而，由于面向属性的数据泛化涉及查询相关的数据方的计算，与简单地计算主关系相比，这可能涉及更多的处理，从而增加了响应时间。
二者之间的一个折衷是计算方结构的“次主”关系，其泛化关系的每个维层次比主关系的层次稍深一点。
这将便于以合理的存储和处理开销下钻到这些层，尽管超过这些层的进一步下钻仍然需要从原始层数据泛化。
注意，这种下钻多半是局部的，而不是散布在整个数据方上。
使用预定义的数据方：
另一种方法是：
在数据挖掘查询提交系统之前构造数据方，并对其后的数据挖掘使用预定义的数据方。
如果任务相关的数据的粒度与预定义的数据方一致，并且任务相关的数据量相当大，该方法是所期望的。
由于这种数据方是预计算的，它便于属性相关的分析、面向属性归纳、切片和切块、上卷和下钻。
必须付出的代价是不容忽视的数据方计算开销和存储开销。
计算/存储开销和访问速度之间的一个折衷是，选择性地预计算所有可能物化的方体的一个子集，如第2章所述。
5.2.3导出泛化的表示
“面向属性归纳产生一个或一组泛化描述。
如何直观地表示这些描述？
”可以用多种不同的形式将描述提供给用户。
由面向属性归纳方法产生的泛化描述通常以泛化关系形式显式。
例5.4假定在AllElectronics的sales关系上进行面向属性归纳，产生1999年销售的泛化描述表5.3。
该描述以泛化关系的形式给出。
例5.3的表5.2是泛化关系的另一个例子。
表5.3:
1997年销售的泛化关系
location
item
sales（$1,000,000）
count（1,000）
亚洲
TV
15
300
欧洲
12
250
北美
升级会员 