热门搜索：
当前位置：
大数据建模需要了解的九大形式
数据挖掘是利用业务知识从数据中发现和解释知识（或称为模式）的过程，这种知识是以自然或者人工形式创造的新知识。
　　当前的数据挖掘形式，是在20世纪90年代实践领域诞生的，是在集成数据挖掘算法平台发展的支撑下适合商业分析的一种形式。也许是因为数据挖掘源于实践而非 理论，在其过程的理解上不太引人注意。20世纪90年代晚期发展的CRISP-DM，逐渐成为数据挖掘过程的一种标准化过程，被越来越多的数据挖掘实践者 成功运用和遵循。　　虽然CRISP-DM能够指导如何实施数据挖掘，但是它不能解释数据挖掘是什么或者为什么适合这样做。在本文中我将阐述我提出数据挖掘的九种准则或&定律&（其中大多数为实践者所熟知）以及另外其它一些熟知的解释。开始从理论上（不仅仅是描述上）来解释数据挖掘过程。　　我的目的不是评论CRISP-DM，但CRISP-DM的许多概念对于理解数据挖掘是至关重要的，本文也将依赖于CRISP-DM的常见术语。CRISP-DM仅仅是论述这个过程的开始。　　第一，目标律：业务目标是所有数据解决方案的源头。　　它定义了数据挖掘的主题：数据挖掘关注解决业务业问题和实现业务目标。数据挖掘主要不是一种技术，而是一个过程，业务目标是它的的核心。 没有业务目标，没有数据挖掘（不管这种表述是否清楚）。因此这个准则也可以说成：数据挖掘是业务过程。　　第二，知识律：业务知识是数据挖掘过程每一步的核心。　　这里定义了数据挖掘过程的一个关键特征。CRISP-DM的一种朴素的解读是业务知识仅仅作用于数据挖掘过程开始的目标的定义与最后的结果的实施，这将错过数据挖掘过程的一个关键属性，即业务知识是每一步的核心。　　为了方便理解，我使用CRISP-DM阶段来说明：
　　商业理解必须基于业务知识，所以数据挖掘目标必须是业务目标的映射（这种映射也基于数据知识和数据挖掘知识）；
　　数据理解使用业务知识理解与业务问题相关的数据，以及它们是如何相关的；
　　数据预处理就是利用业务知识来塑造数据，使得业务问题可以被提出和解答（更详尽的第三条&准备律）；
　　建模是使用数据挖掘算法创建预测模型，同时解释模型和业务目标的特点，也就是说理解它们之间的业务相关性；
　　评估是模型对理解业务的影响；
　　实施是将数据挖掘结果作用于业务过程；
&&&&&&&&&&&&&&&&
责任编辑：Silva
免责声明：
本文仅代表作者个人观点，与
OFweek物联网
无关。其原创性以及文中陈述文字和内容未经本站证实，
对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅
作参考，并请自行核实相关内容。
邮箱/用户名：
忘记密码？
用其他账号登录： QQ
请输入评论
广东省/深圳市
四川省/成都市
广东省/深圳市
广东省/深圳市
广东省/深圳市
广东省/深圳市
北京市/海淀区
广东省/深圳市
广东省/深圳市
广东省/惠州市
*文字标题：
*纠错内容：
联系邮箱：
*验 证 码：　　目前的开发中，我们一般会从数据库查询出来数据，再把数据填充到一个对象中，然后就可以很方便的读取对象信息了。data填充到object这个过程很是繁琐，为简化这个问题，各种框架、组件层出不穷，在此不一一列举，我实在也列举不出 -_- ! &诸多框架用起来固然方便，但我总会想起一句话，原文模糊了，出处忘了，大意是&当到一定程度时技术都会以各自的方式失败&，且不说失败不失败，用框架的同学在某个时刻肯定有过这样的感慨：&要是这个框架支持XX就好了&、&这个功能本来很简单，但我们项目现在用的是这个框架，要实现这个功能看来又要写蹩足的代码了&、&这个框架越来越不符合我们的要求，难道我们要改成YY框架吗？&等等。所以框架都有自身固有的限制，那么我们面临的问题，第一时间真的都要求助于框架吗？
本文想表达的决无轻视框架的意思，只是园里讨论框架的甚多，往往让新手有一种不了解、不会用某某框架就说明自己差人一大截的感觉，同时也让很多新手只因会用很多框架就感觉自己很牛B的样子，不管是哪种情况，都不利于自身技术上的提高。所以此文是只是希望新手们能深刻思考一下自己的现状，给自己一个正确的评估，努力做到看到如何调用时，就大概能想象出内部是如何实现的，说白了就是对语言本身很熟悉，对一些思想有了解，下面不表框架的种种，单用新手都知道的技术组合出一个data到object的实现。
准备及问题：
　　准备1,数据库test1有表MyUser{
　　　　ID (PK, int, not null) &
　　　　UserName (varchar(20), not null)
　　　　Age (tinyint, not null)
　　　　Birthday (datetime, null)
　　准备2,数据库test2有表Message{
　　　　ID (PK, int, not null)
　　　　MyUserID (int, not null)
　　　　Content (nvarchar(200), not null)
　　　　AddTime (datetime, not null)
& & &&准备3,SQLHelper一个，这个自不必说，访问数据库嘛！
　　问题1，一个data到object的填充只实现一次，不管是取多少个字段，不管是取一条数据还是多条数据
　　问题2，关联查询，为了强调演示，关联数据在不同的数据库里，具体就是查用户和他们的消息（可能用动态和评论来举例更合适，呵呵 谅解！）
　　想重用，自然而然的就会想到继承；
　　想统一处理，也要想到抽象；
　　想动态添加数据，要能想到字典，大家一定要记得，字典是一个很好用的数据结构；
　　想用统一的方法得到不同的具体的类型对象，自然是泛型了。
　　下方会一一体现，现在不明所以没关系。
　　data到object的填充，具体到ado.net，一般就是reader到object了，要实现动态字段都用一个方法填充，以MyUser来说，大概可以这样：
public MessageInfo FillModelFromReader(DbDataReader reader, params string[] fields)
var info = new MessageInfo();
if (DALUtil.HasFields("ID", fields)) { info.ID = (int)reader["ID"]; }
if (DALUtil.HasFields("MyUserID", fields)) { info.MyUserID = (int)reader["MyUserID"]; }
if (DALUtil.HasFields("Content", fields)) { info.Content = reader["Content"].ToString(); }
if (DALUtil.HasFields("AddTime", fields)) { info.AddTime = (DateTime)reader["AddTime"]; }
&　　数据库交互无非就那几个方法，我们可以抽象出来一个数据访问的基类，实际运用中还要写几个方法重载，以便于调用
/// &summary&
/// DAL基类
/// &/summary&
/// &typeparam name="T"&&/typeparam&
public abstract class DALBase&T&
/// &summary&
/// 由子类决定用哪个链接
/// &/summary&
protected abstract string ConnName
protected abstract T FillModelFromReader(DbDataReader reader, params string[] fields);
protected string GetConnStr()
return System.Configuration.ConfigurationManager.ConnectionStrings[ConnName].ConnectionS
protected List&T& FindList(string sql, CommandType type, params SqlParameter[] parameters)
using (var reader = SqlHelper.ExecuteReader(GetConnStr(), type, sql, parameters))
List&T& list = new List&T&();
var fields = DALUtil.GetReaderFieldNames(reader);
while (reader.Read())
list.Add(FillModelFromReader(reader, fields));
protected T FindOne(string sql, CommandType type, params SqlParameter[] parameters)
return FindList(sql, type, parameters).FirstOrDefault();
private List&T& FindPage(string tableName, string fields, string query, string orderby, int pageIndex, int pageSize, bool isTotal, out int totalCount, params SqlParameter[] parameters)
if (pageIndex & 1)
throw new ArgumentException("pageIndex参数应&1");
StringBuilder sb = new StringBuilder();
SqlParameter[] newPs;
if (isTotal)
sb.AppendFormat("select count(0) from [{0}]", tableName);
if (!string.IsNullOrWhiteSpace(query))
sb.AppendFormat(" where {0}", query);
totalCount = GetCount(sb.ToString(), parameters);
sb.Clear();
newPs = SqlHelper.CopyParameters(parameters);
totalCount = 0;
if (string.IsNullOrWhiteSpace(orderby))
throw new ArgumentException("orderby参数不应为空");
var fs = string.IsNullOrWhiteSpace(fields) ? "*" : string.Join(",", fields);
sb.AppendFormat("select {0} from (", fs);
sb.AppendFormat(" select top {0} {1},ROW_NUMBER() over(order by {2}) rowid from {3}", pageIndex * pageSize, fs, orderby, tableName);
if (!string.IsNullOrWhiteSpace(query))
sb.AppendFormat(" where {0}", query);
sb.AppendFormat(")t where t.rowid&{0} and t.rowid&={1}", (pageIndex - 1) * pageSize, pageIndex * pageSize);
return FindList(sb.ToString(), CommandType.Text, newPs);
protected object GetScalar(string sql, CommandType type, params SqlParameter[] parameters)
return SqlHelper.ExecuteScalar(GetConnStr(), type, sql, parameters);
protected int GetCount(string sql, CommandType type, params SqlParameter[] parameters)
var obj = GetScalar(sql, type, parameters);
if (obj == null) return -1;
return (int)
protected int Execute(string sql, CommandType type, params SqlParameter[] parameters)
return SqlHelper.ExecuteNonQuery(GetConnStr(), type, sql, parameters);
&　　实现MyUserDAL，继承于DALBase&MyUserInfo&,设置自己的链接名，实现自己的填充方法，而所有的查询直接调用基类的方法即可，不管哪个查询，都会在基类调用自己实现的填充方法！这样问题1算是解决了。（模型和FillModelFromReader都是用MyGeneration）
public class MyUserDAL : DALBase&MyUserInfo&
protected override string ConnName
get { return "sqlconn1"; }
protected override MyUserInfo FillModelFromReader(DbDataReader reader, params string[] fields)
var info = new MyUserInfo();
if (DALUtil.HasFields("ID", fields)) info.ID = (int)reader["ID"];
if (DALUtil.HasFields("UserName", fields)) info.UserName = reader["UserName"].ToString();
if (DALUtil.HasFields("Age", fields)) info.Age = (byte)reader["Age"];
if (DALUtil.HasFields("Birthday", fields) && !(reader["Birthday"] is DBNull)) info.Birthday = (DateTime)reader["Birthday"];
public MyUserInfo FindOne(int id)
var sql = "select * from MyUser where ID=@id";
return FindOne(sql, DALUtil.CreateParameter("id", id));
public List&MyUserInfo& Find1()
var sql = "select ID,UserName from MyUser";
return FindList(sql);
public List&MyUserInfo& Find2()
var sql = "select ID,UserName,Age,Birthday from MyUser";
return FindList(sql);
　　问题2是表关联问题，这个时候要想到字典，字典这个东西真是再强调也不为过啊。对于UI层，我们取数据是从模型来的，所以关联数据也要在模型上，我们为需要关联数据的模型建一个基类，关联数据其实可以理解为附加数据的一种，所以我们以后叫它附加数据：
/// &summary&
/// 模型层附加数据基类
/// &/summary&
[Serializable]
public class ModelBase
private Dictionary&string, object& _exData = new Dictionary&string, object&();
public Dictionary&string, object& ExData
get { return _exD }
set { _exData = }
/// &summary&
/// 得到附加数据
/// &/summary&
/// &typeparam name="T"&&/typeparam&
/// &param name="name"&&/param&
/// &returns&&/returns&
public T GetExData&T&(string name)
if (_exData.TryGetValue(name, out data))
return (T)
return default(T);
/// &summary&
/// 添加附加数据
/// &/summary&
/// &param name="name"&&/param&
/// &param name="obj"&&/param&
public void AddExData(string name, object obj)
_exData.Add(name, obj);
/// &summary&
/// 检测附加数据是否存在
/// &/summary&
/// &param name="name"&&/param&
/// &returns&&/returns&
public bool ExistsExData(string name)
return _exData.ContainsKey(name);
　　MyUserInfo有附加数据，那么就让MyUserInfo继承ModelBase吧，继承后便有了存储附加数据的能力，而附加数据这个操作写到哪里呢？当然是写到BLL里，首先实现Message的相关功能，这里我们需要一个public List&MessageInfo& FindByUserIDs(IEnumerable&int& userids)的方法来根据一串userid得到一个MessageInfo的集合，代码不贴了，下附下载。直接看MyUserBLL里的操作：
public class MyUserBLL
DAL.MyUserDAL dal = new DAL.MyUserDAL();
public MyUserInfo FindOne(int id)
return dal.FindOne(id);
public List&MyUserInfo& Find1()
var list = dal.Find1();
public List&MyUserInfo& Find2()
var list = dal.Find2();
DealMsg(list);
static void DealMsg(List&MyUserInfo& list)
var ids = list.Select(u =& u.ID);
MessageBLL msgbll = new MessageBLL();
var msgs = msgbll.FindByUserIDs(ids);
foreach (var info in list)
info.AddExData("Messages", msgs.Where(msg =& msg.MyUserID == info.ID).ToList());
　　一个DealMsg方法，便来自两个数据库的数据连接到一起了，像DealXX的方法可以根据需要要以有多个，分别附加不的数据，再看测试：
class Program
static MyUserBLL userbll = new MyUserBLL();
static void Main(string[] args)
Console.WriteLine();
Console.WriteLine();
static void F0()
var info = userbll.FindOne(2);
Console.WriteLine(info.ToString());
static void F1()
var list = userbll.Find1();
foreach (var info in list)
Console.WriteLine(info.ToString());
static void F2()
var list = userbll.Find2();
foreach (var info in list)
Console.WriteLine(info.ToString());
var messages = info.GetExData&List&MessageInfo&&("Messages");
foreach (var msg in messages)
Console.WriteLine("\t{0}", msg.ToString());
Console.WriteLine();
至此收工！
很多简单的东西掌握好了，组合起来也能做一些事件吧！
阅读(...) 评论()数据挖掘是利用业务知识从数据中发现和解释知识(或称为模式)的过程，这种知识是以自然或者人工形式创造的新知识。
当前的数据挖掘形式，是在20世纪90年代实践领域诞生的，是在集成数据挖掘算法平台发展的支撑下适合商业分析的一种形式。也许是因为数据挖掘源于实践而非 理论，在其过程的理解上不太引人注意。20世纪90年代晚期发展的CRISP-DM，逐渐成为数据挖掘过程的一种标准化过程，被越来越多的数据挖掘实践者 成功运用和遵循。
虽然CRISP-DM能够指导如何实施数据挖掘，但是它不能解释数据挖掘是什么或者为什么适合这样做。在本文中我将阐述我提出数据挖掘的九种准则或“定律”(其中大多数为实践者所熟知)以及另外其它一些熟知的解释。开始从理论上(不仅仅是描述上)来解释数据挖掘过程。
我的目的不是评论CRISP-DM，但CRISP-DM的许多概念对于理解数据挖掘是至关重要的，本文也将依赖于CRISP-DM的常见术语。CRISP-DM仅仅是论述这个过程的开始。
第一，目标律：业务目标是所有数据解决方案的源头。
它定义了数据挖掘的主题：数据挖掘关注解决业务业问题和实现业务目标。数据挖掘主要不是一种技术，而是一个过程，业务目标是它的的核心。 没有业务目标，没有数据挖掘(不管这种表述是否清楚)。因此这个准则也可以说成：数据挖掘是业务过程。
第二，知识律：业务知识是数据挖掘过程每一步的核心。
这里定义了数据挖掘过程的一个关键特征。CRISP-DM的一种朴素的解读是业务知识仅仅作用于数据挖掘过程开始的目标的定义与最后的结果的实施，这将错过数据挖掘过程的一个关键属性，即业务知识是每一步的核心。
为了方便理解，我使用CRISP-DM阶段来说明：
商业理解必须基于业务知识，所以数据挖掘目标必须是业务目标的映射(这种映射也基于数据知识和数据挖掘知识);
数据理解使用业务知识理解与业务问题相关的数据，以及它们是如何相关的;
数据预处理就是利用业务知识来塑造数据，使得业务问题可以被提出和解答(更详尽的第三条—准备律);
建模是使用数据挖掘算法创建预测模型，同时解释模型和业务目标的特点，也就是说理解它们之间的业务相关性;
评估是模型对理解业务的影响;
实施是将数据挖掘结果作用于业务过程;
总之，没有业务知识，数据挖掘过程的每一步都是无效的，也没有“纯粹的技术”步骤。 业务知识指导过程产生有益的结果，并使得那些有益的结果得到认可。数据挖掘是一个反复的过程，业务知识是它的核心，驱动着结果的持续改善。
这背后的原因可以用“鸿沟的表现”(chasm of representation)来解释(Alan Montgomery在20世纪90年代对数据挖掘提出的一个观点)。Montgomery指出数据挖掘目标涉及到现实的业务，然而数据仅能表示现实的一 部分;数据和现实世界是有差距(或“鸿沟”)的。在数据挖掘过程中，业务知识来弥补这一差距，在数据中无论发现什么，只有使用业务知识解释才能显示其重要 性，数据中的任何遗漏必须通过业务知识弥补。只有业务知识才能弥补这种缺失，这是业务知识为什么是数据挖掘过程每一步骤的核心的原因。
第三，准备律：数据预处理比数据挖掘其他任何一个过程都重要。
这是数据挖掘著名的格言，数据挖掘项目中最费力的事是数据获取和预处理。非正式估计，其占用项目的时间为50%-80%。最简单的解释可以概括为“数据是困 难的”，经常采用自动化减轻这个“问题”的数据获取、数据清理、数据转换等数据预处理各部分的工作量。虽然自动化技术是有益的，支持者相信这项技术可以减 少数据预处理过程中的大量的工作量，但这也是误解数据预处理在数据挖掘过程中是必须的原因。
数据预处理的目的是把数据挖掘问题转化为格式化的数据，使得分析技术(如数据挖掘算法)更容易利用它。数据任何形式的变化(包括清理、最大最小值转换、增长 等)意味着问题空间的变化，因此这种分析必须是探索性的。 这是数据预处理重要的原因，并且在数据挖掘过程中占有如此大的工作量，这样数据挖掘者可以从容 地操纵问题空间，使得容易找到适合分析他们的方法。
有两种方法“塑造”这个问题 空间。第一种方法是将数据转化为可以分析的完全格式化的数据，比如，大多数数据挖掘算法需要单一表格形式的数据，一个记录就是一个样例。数据挖掘者都知道 什么样的算法需要什么样的数据形式，因此可以将数据转化为一个合适的格式。第二种方法是使得数据能够含有业务问题的更多的信息，例如，某些领域的一些数据 挖掘问题，数据挖掘者可以通过业务知识和数据知识知道这些。 通过这些领域的知识，数据挖掘者通过操纵问题空间可能更容易找到一个合适的技术解决方案。
因此，通过业务知识、数据知识、数据挖掘知识从根本上使得数据预处理更加得心应手。 数据预处理的这些方面并不能通过简单的自动化实现。
这个定律也解释了一个有疑义的现象，也就是虽然经过数据获取、清理、融合等方式创建一个数据仓库，但是数据预处理仍然是必不可少的，仍然占有数据挖掘过程一 半以上的工作量。此外，就像CRISP-DM展示的那样，即使经过了主要的数据预处理阶段，在创建一个有用的模型的反复过程中，进一步的数据预处理的必要 的。
有五种因素说明试验对于寻找数据挖掘解决方案是必要的：
数据挖掘项目的业务目标定义了兴趣范围(定义域)，数据挖掘目标反映了这一点;
与业务目标相关的数据及其相应的数据挖掘目标是在这个定义域上的数据挖掘过程产生的;
这些过程受规则限制，而这些过程产生的数据反映了这些规则;
在这些过程中，数据挖掘的目的是通过模式发现技术(数据挖掘算法)和可以解释这个算法结果的业务知识相结合的方法来揭示这个定义域上的规则;
数据挖掘需要在这个域上生成相关数据，这些数据含有的模式不可避免地受到这些规则的限制。
在这里强调一下最后一点，在数据挖掘中改变业务目标，CRISP-DM有所暗示，但经常不易被觉察到。广为所知的CRISP-DM过程不是下一个步骤仅接着上一个步骤的“瀑布”式的过程。事实上，在项目中的任何地方都可以进行任何CRISP-DM步骤，同样商业理解也可以存在于任何一个步骤。业务目标不是简 单地在开始就给定，它贯穿于整个过程。这也许可以解释一些数据挖掘者在没有清晰的业务目标的情况下开始项目，他们知道业务目标也是数据挖掘的一个结果，不是静态地给定。
Wolpert的“没有免费的午餐”理论已经应用于机器学习领域，无偏的状态好于(如一个具体的算法)任何其他可能的问题 (数据集)出现的平均状态。这是因为，如果我们考虑所有可能的问题，他们的解决方法是均匀分布的，以至于一个算法(或偏倚)对一个子集是有利的，而对另一个子集是不利的。这与数据挖掘者所知的具有惊人的相似性，没有一个算法适合每一个问题。但是经 过数据挖掘处理的问题或数据集绝不是随机的，也不是所有可能问题的均匀分布，他们代表的是一个有偏差的样本，那么为什么要应用NFL的结论?答案涉及到上 面提到的因素：问题空间初始是未知的，多重问题空间可能和每一个数据挖掘目标相关，问题空间可能被数据预处理所操纵，模型不能通过技术手段评估，业务问题本身可能会变化。由于这些原因，数据挖掘问题空间在数据挖掘过程中展开，并且在这个过程中是不断变化的，以至于在有条件的约束下，用算法模拟一个随机选择的数据集是有效的。对于数据挖掘者来说：没有免费的午餐。
这大体上描述了数据 挖掘过程。但是，在有条件限制某些情况下，比如业务目标是稳定的，数据和其预处理是稳定的，一个可接受的算法或算法组合可以解决这个问题。在这些情况下， 一般的数据挖掘过程中的步骤将会减少。 但是，如果这种情况稳定是持续的，数据挖掘者的午餐是免费的，或者至少相对便宜的。像这样的稳定性是临时的，因为 对数据的业务理解(第二律)和对问题的理解(第九律)都会变化的。
第五，模式律(大卫律)：数据中总含有模式。
这条规律最早由David Watkins提出。 我们可能预料到一些数据挖掘项目会失败，因为解决业务问题的模式并不存在于数据中，但是这与数据挖掘者的实践经验并不相关。
前文的阐述已经提到，这是因为：在一个与业务相关的数据集中总会发现一些有趣的东西，以至于即使一些期望的模式不能被发现，但其他的一些有用的东西可能会被 发现(这与数据挖掘者的实践经验是相关的);除非业务专家期望的模式存在，否则数据挖掘项目不会进行，这不应感到奇怪，因为业务专家通常是对的。
然而，Watkins提出一个更简单更直接的观点：“数据中总含有模式。”这与数据挖掘者的经验比前面的阐述更一致。这个观点后来经过Watkins修正，基于客户关系的数据挖掘项目，总是存在着这样的模式即客户未来的行为总是和先前的行为相关，显然这些模式是有利可图的(Watkins的客户关系管理定律)。但是，数据挖掘者的经验不仅仅局限于客户关系管理问题，任何数据挖掘问题都会存在模式(Watkins的通用律)。
Watkins的通用律解释如下：
数据挖掘项目的业务目标定义了兴趣范围(定义域)，数据挖掘目标反映了这一点;
与业务目标相关的数据及其相应的数据挖掘目标是在这个定义域上的数据挖掘过程产生的;
这些过程受规则限制，而这些过程产生的数据反映了这些规则;
在这些过程中，数据挖掘的目的是通过模式发现技术(数据挖掘算法)和可以解释这个算法结果的业务知识相结合的方法来揭示这个定义域上的规则;
数据挖掘需要在这个域上生成相关数据，这些数据含有的模式不可避免地受到这些规则的限制。
总结这一观点：数据中总存在模式，因为在这过程中不可避免产生数据这样的副产品。为了发掘模式，过程从(你已经知道它)—–业务知识开始。
利用业务知识发现模式也是一个反复的过程;这些模式也对业务知识有贡献，同时业务知识是解释模式的主要因素。在这种反复的过程中，数据挖掘算法简单地连接了业务知识和隐藏的模式。
如果这个解释是正确的，那么大卫律是完全通用的。除非没有相关的数据的保证，否则在每个定义域的每一个数据挖掘问题总是存在模式的。
第六，洞察律：数据挖掘增大对业务的认知。
数据挖掘是如何产生洞察力的?这个定律接近了数据挖掘的核心：为什么数据挖掘必须是一个业务过程而不是一个技术过程。业务问题是由人而非算法解决的。数据挖 掘者和业务专家从问题中找到解决方案，即从问题的定义域上达到业务目标需要的模式。数据挖掘完全或部分有助于这个认知过程。数据挖掘算法揭示的模式通常不 是人类以正常的方式所能认识到的。综合这些算法和人类正常的感知的数据挖掘过程在本质上是敏捷的。在数据挖掘过程中，问题解决者解释数据挖掘算法产生的结 果，并统一到业务理解上，因此这是一个业务过程。
这类似于“智能放大器”的概念，在早期的人工智能的领域，AI的第一个实际成果不是智能机器，而是被称为“智能放大器”的工具，它能够协助人类使用者提高获取有效信息的能力。数据挖掘提供一个类似的“智能放大器”，帮助业务专家解决他们不能单独完成的业务问题。
总之，数据挖掘算法提供一种超越人类以正常方式探索模式的能力，数据挖掘过程允许数据挖掘者和业务专家将这种能力融合在他们的各自的问题的中和业务过程中。
第七，预测律：预测提高了信息泛化能力。
“预测”已经成为数据挖掘模型可以做什么的可接受的描述，即我们常说的“预测模型”和“预测分析”。这是因为许多流行的数据挖掘模型经常使用“预测最可能的结果”(或者解释可能的结果如何有可能)。这种方法是分类和回归模型的典型应用。
但是，其他类型的数据挖掘模型，比如聚类和关联模型也有“预测”的特征。这是一个含义比较模糊的术语。一个聚类模型被描述为“预测”一个个体属于哪个群体，一个关联模型可能被描述为基于已知基本属性“预测”一个或更多属性。
同样我们也可以分析“预测”这个术语在不同的主题中的应用：一个分类模型可能被说成可以预测客户行为—-更加确切的说它可以预测以某种确定行为的目标客户，即使不是所有的目标个体的行为都符合“预测”的结果。一个诈骗检测模型可能被说成可以预测个别交易是否具有高风险性，即使不是所有的预测的交易都有欺诈行为。
“预测”这个术语广泛的使用导致了所谓的“预测分析”被作为数据挖掘的总称，并且在业务解决方案中得到了广泛的应用。但是我们应该意识到这不是日常所说的“预测”，我们不能期望预测一个特殊个体的行为或者一个特别的欺诈调查结果。
那么，在这个意义下的“预测”是什么?分类、回归、聚类和 关 联算法以及他们集成模型有什么共性呢?答案在于“评分”，这是预测模型应用到一个新样例的方式。模型产生一个预估值或评分，这是这个样例的新信息的一部 分;在概括和归纳的基础上，这个样例的可利用信息得到了提高，模式被算法发现和模型具体化。值得注意的是这个新信息不是在“给定”意义上的“数据”，它仅 有统计学意义。
第八，价值律：数据挖掘的结果的价值不取决于模型的稳定性或预测的准确性。
准确性和稳定性是预测模型常用的两个度量。准确性是指正确的预测结果所占的比例;稳定性是指当创建模型的数据改变时，用于同一口径的预测数据，其预测结果变 化有多大(或多小)。鉴于数据挖掘中预测概念的核心角色，一个预测模型的准确性和稳定性常被认为决定了其结果的价值的大小，实际上并非如此。
体现预测模型价值的有两种方式：一种是用模型的预测结果来改善或影响行为，另一种是模型能够传递导致改变策略的见解(或新知识)。
对于后者，传递出的任何新知识的价值和准确性的联系并不那么紧密;一些模型的预测能力可能有必要使我们相信发现的模式是真实的。然而，一个难以理解的复杂的 或者完全不透明的模型的预测结果具有高准确性，但传递的知识也不是那么有见地;然而，一个简单的低准确度的模型可能传递出更有用的见解。
准确性和价值之间的分离在改善行为的情况下并不明显，然而一个突出问题是“预测模型是为了正确的事，还是为了正确的原因?” 换句话说，一个模型的价值和它的预测准确度一样，都源自它的业务问题。例如，客户流失模型可能需要高的预测准确度，否则对于业务上的指导不会那么有效。相 反的是一个准确度高的客户流失模型可能提供有效的指导，保留住老客户，但也仅仅是最少利润客户群体的一部分。如果不适合业务问题，高准确度并不能提高模型 的价值。
模型稳定性同样如此，虽然稳定性是预测模型的有趣的度量，稳定性不能代替模型提供业务理解的能力或解决业务问题，其它技术手段也是如此。
总之，预测模型的价值不是由技术指标决定的。数据挖掘者应该在模型不损害业务理解和适应业务问题的情况下关注预测准确度、模型稳定性以及其它的技术度量。
第九，变化律：所有的模式因业务变化而变化。
数据挖掘发现的模式不是永远不变的。数据挖掘的许多应用是众所周知的，但是这个性质的普遍性没有得到广泛的重视。
数据挖掘在市场营销和CRM方面的应用很容易理解，客户行为模式随着时间的变化而变化。行为的变化、市场的变化、竞争的变化以及整个经济形势的变化，预测模型会因这些变化而过时，当他们不能准确预测时，应当定期更新。
数据挖掘在欺诈模型和风险模型的应用中同样如此，随着环境的变化欺诈行为也在变化，因为罪犯要改变行为以保持领先于反欺诈。欺诈检测的应用必须设计为就像处理旧的、熟悉的欺诈行为一样能够处理新的、未知类型的欺诈行为。
某些种类的数据挖掘可能被认为发现的模式不会随时间而变化，比如数据挖掘在科学上的应用，我们有没有发现不变的普遍的规律?也许令人惊奇的是，答案是即使是这些模式也期望得到改变。理由是这些模式并不是简单的存在于这个世界上的规则，而是数据的反应—-这些规则可能在某些领域确实是静态的。
然而，数据挖掘发现的模式是认知过程的一部分，是数据挖掘在数据描述的世界与观测者或业务专家的认知之间建立的一个动态过程。因为我们的认知在持续发展和增 长，所以我们也期望模式也会变化。明天的数据表面上看起来相似，但是它可能已经集合了不同的模式、(可能巧妙地)不同的目的、不同的语义;分析过程因受业 务知识驱动，所以会随着业务知识的变化而变化。基于这些原因，模式会有所不同。
总之，所有的模式都会变化，因为他们不仅反映了一个变化的世界，也反映了我们变化的认知。
这九条定律是关于数据挖掘的简单的真知。这九条定律的大部分已为数据挖掘者熟知，但仍有一些不熟悉(例如，第五、第六、第七)。大多数新观点的解释都和这九条定律有关，它试图解释众所周知的数据挖掘过程中的背后的原因。
我们为什么何必在意数据挖掘过程所采用的形式呢?除了知识和理解这些简单的诉求，有实实在在的理由去探讨这些问题。
数据挖掘过程以现在的形式存在是因为技术的发展—-机器学习算法的普及以及综合其它技术集成这些算法的平台的发展，使得商业用户易于接受。我们是否应该期望因技术的改变而改变数据挖掘过程?最终它会改变，但是如果我们理解数据挖掘过程形成的原因，然后我们可以辨别技术可以改变的和不能改变的。
一些技术的发展在预测分析领域具有革命性的作用，例如数据预处理的自动化、模型的重建以及在部署的框架里通过预测模型集成业务规则。数据挖掘的九条定律及其 解释说明：技术的发展不会改变数据挖掘过程的本质。这九条定律以及这些思想的进一步发展，除了有对数据挖掘者的教育价值之外，应该被用来判别未来任何数据 挖掘过程革命性变化的诉求。
转载请注明来自36大数据（)： &
除非特别注明，本站所有文章均不代表本站观点。报道中出现的商标属于其合法持有人。请遵守理性，宽容，换位思考的原则。}