BI是什么？BI(Business Intelligence)的中文译名是商务智能，关于这个名词的定义很多，比较严谨的定义如下：
“商务智能是企业利用现代信息技术收集、管理和分析结构化和非结构化的商务数据和信息，创造和累计商务知识和见解，改善商务决策水平，采取有效的商务行动，完善各种商务流程，提升各方面商务绩效，增强综合竞争力的智慧和能力。”（作者：王茁）
也有比较简洁的定义：商务智能好比“数据炼油厂”，即把商业活动中累积的数据加工成可用于支持商业决策的信息。
资料来源：美国数据仓库研究院（www.dw-institute.com）
BI是如何产生的？这需要从传统的商务交易系统讲起。
最初在商务交易中引入计算机辅助管理时，开发人员是根据企业已规定好的业务规则来编写交易系统。此时的商务系统，其主要目的是让“商务流程自动化”，从而缩短业务周期，提高效率，增强企业的竞争力，最终为企业创造更大的利润。现今，绝大部分大、中型商业公司都已在内部或多或少的引入的计算机辅助商务管理系统。
随着计算机在商业管理中的普及，公司的高层管理人员有了更近一步的需求，即其企业的部门框架和业务规则随着社会分工的日益细化，而不断的发生变动。而且，其中蕴含了不少的新的商机，精明的经理们当然不希望错过这些能让企业更上层楼的机会了，而原有的商务管理系统面对日益变化的业务规则逐渐变得力不从心。
因此，软件厂商针对新出现的商业部门和业务规则，推出了一系列的自成体系的，专门针对某块商业数据管理的管理软件，如财务管理软件，客户关系管理软件，产品数据管理软件，人力资源管理软件等。但是，这些自成体系的的管理软件之间，数据很难共享，从而在企业各个部门之间形成了“信息孤立”的局面。
于是，软件厂商又推出了更大块集成的企业资源规划(ERP)系统，把之前推出的各块独立的管理系统整合起来。但是，单单把各个商务部门的管理软件集成起来，是否真的就是企业真正需要的“能适应商务变化”的整体解决方案呢？
我认为：如果仅仅针对目前的商务活动和业务规则打包，答案一定是NO! 这个答案也早就被相关方面的专家所确定。那么，如何才能真正把各个商业部门之间的商务数据集成起来，从中预测商务变化，找到潜在商机，为商业决策提供数据支持呢？答案就是BI。
不过，BI的范围太广太大，在实际商务中我们往往只需运用其中的某个部分就可以暂时满足企业的需求，如数据仓库，联机事务分析(OLAP)，数据挖掘，决策支持系统(DDS)等。其实，整个BI的框架结构可以用下面的图中间的三部分(数据预处理、数据仓库、数据分析)来表示：
现在决大多数企业已在其一个或多个部门内采用了计算机商务管理系统，也累积了相当的商业数据。然而，正如业内的那句老话“rich data, poor information”，以前累积的数据，并没有很好的得到利用。Why?并不是企业高层管理人员没有想到，而是这些数据来源太广，格式不统一，并且其中极少量的数据记录格式不正确；同时，累计的数据量相当庞大，上百万条记录才刚起步，某些大型公司每天所产生的商业记录已过千万；而且，某些细节对高层管理人员来说并不重要。他们需要的是一份站在战略层角度统观全局，及时的，在短时间内可以读完，为企业决策服务的统计报表。
为了实现这一艰巨的目标，BI专家把任务分解成了三个子任务：
1)为了整合各种格式的数据，清除原有数据中的错误记录，专家们提出了数据预处理的要求——STL(数据抽取、转换、装载)；
2)对预处理过数据，应该统一集中起来，由此产生了元数据(Meta data)、数据仓库(Data Warehouse)；
3)最后，对于集中起来的庞大的数据集，还应进行相应的专业统计，从中发掘出对企业决策有价值的新的机会，这就是OLAP(联机事务分析)和数据挖掘(Data Mining)。
下面具体介绍一下每个子任务所需要用到的专业技术和辅助工具。
1)数据预处理(STL：Extraction，Transformation，Load)
当早期大型的在线事务处理系统(OLTP)问世后不久，就出现了一种用于“抽取”处理的简单程序，其作用是搜索整个文件和数据库，使用某些标准选择合乎要求的数据，将其复制拷贝出来，用于总体分析。因为这样做不会影响正在使用的在线事务处理系统，降低其性能，同时，用户可以自行控制抽取出来的数据。但是，现在情况发生了巨大的变化，企业同时采用了多个在线事务处理系统，而这些系统之间的数据定义格式不尽相同，即使采用同一软件厂商提供的不同软件产品，或者仅仅是产品版本不同，之间的数据定义格式也有少许差距。由此，我们必须先定义一个统一的数据格式，然后把各个来源的数据按新的统一的格式进行转换，然后集中装载入数据仓库中。
其中，尤其要注意的一点时，并不是各个来源的不同格式的所有数据都能被新的统一格式包容，我们也不应强求非要把所有数据源的数据全部集中起来。Why?原因很多。有可能原来录入的数据中，少量的记录使用了错误的数据，这类数据如果无法校正，应该被舍去。某些数据记录是非结构化的，很难将其转化成新定义的统一格式，而且从中抽取信息必须读取整个文件，效率极低，如大容量的二进制数据文件，多媒体文件等，这类数据如果对企业决策不大，可以舍去。
目前已有一部分软件厂商开发出专门的ETL工具，其中包括：
·Ardent DataStage
·Evolutionary Technologies,Inc. (ETI) Extract
·Information Powermart
·Sagent Solution
·SAS Institute
·Oracle Warehouse Builder
·MSSQL Server2000 DTS
2)数据仓库
上面提到，在进行STL之前，需要先定义一个统一的数据格式。那么，定义出来的统一的数据格式是否需要保存起来，以便在数据仓库日后的演化中使用呢？Yes!随着企业不断变化的商业模式和业务规则，肯定需要对系统进行修改和功能升级。如果弄不清楚之前定义的数据格式的具体含义，我们将无从下手。所以，我们需要一种用来描述数据的数据。早期我们使用的是数据字典(Data Dictionary)，数据字典一般包括数据的定义、关系、来源、作用域、格式和用法。但是，随着时间的推移，专家们发现，越来越多的已搭建好的数据仓库希望方便的包容最新的各种格式的结构化和非结构化数据，而传统的基于关系型数据库的数据字典并不能达成这一目标。
xml出世之后，这种自描述，可无限嵌套扩展，平台独立性的文本数据格式为数据字典的进化提供了相当重要的技术支持，由此产生了基于xml的元数据的概念。并且，目前已有不少的软件系统和数据仓库都采用了xml格的元数据。如微软的.Net，P2P的EMule等。由此可见，元数据并不单单局限运用在数据仓库中。
由于基于xml的元数据相当灵活，我们可以用元数据来描述复杂的商业业务定义。所以，现在数据仓库中的元数据分为两种：技术元数据和业务元数据。技术元数据(technical meta data)是为企业技术用户和IT部门的员工提供支持的元数据，对于维护和改进系统来所至关重要。而业务元数据(business meta data)是为企业业务用户提供支持的元数据，使业务用户更容易理解统计报表中的信息。
元数据工具分为两类：一类是将各种元数据集成到集中式仓储的集成工具，另一类是在仓储上执行查询访问的访问工具。一般来说，大多数软件厂商所提供的数据仓库、BI系统中都捆绑了相应的工具。其中包括：
·Ardent MetaStage (Infomix)
·IBM information Catalog
·Brio Enterprise
·Business Objects
·Cognos Impromptu及Powerplau
·Information Advantage Business Intelligence
·Microsoft OLAP Services ("Plato")
·Microstrategy DSS Web and Server
数据仓库是BI的基础，就好比厨师的食材。各个数据源的数据经ETL的预处理后，就被送进了数据仓库中。数据仓库有如下４个重要特性：
①面向主题的：不同类型的公司，其主题集合是不相同的。
②集成的：数据仓库的数据来源很广，数据仓库最重要的目的就是为了集成这些不同数据源的数据。
③非易失的：和传统的操作型数据库系统相比，数据仓库通常是以批量方式载入和访问。而且，对于数据仓库中的记录，并不进行一般意义上的数据更新，删除。所有的历史数据都会被保留，通常我们只是不停的批量导入新的数据。
④随时间变化的：操作型数据库系统出于性能上的考虑，并不保存系统投入运行后所产生的所有数据，一般只保留最新的60~90天内所产生的数据记录。而且，通常情况下，操作型数据库中一项业务活动只占用一条记录。当业务状况发生变化后，我们只需更新相应的记录。而为了按时间变化发掘业务活动的时序规律，数据仓库中，该业务活动可能同时存在多条记录，除了相应字段的内容不同外，其业务活动的时间记录也不相同。数据仓库中的数据是一系列在某时某刻生成的复杂的快照，由此可见，数据仓库的数据是高度冗余且必须的。
而且，由于数据仓库的使用对象不尽相同，数据仓库的设计需要考虑其数据单元的细节程度，即粒度。细节程度越高，粒度级就越低，反之亦然。例如：一个简单的交易处于低粒度级，而每个月所有交易的汇总则处于一个高粒度级。通常，数据分析人员使用的数据粒度较低，而高层管理人员所使用的数据粒度较高。粒度同时决定了数据仓库所占用的物理空间的大小，尽管一条交易记录可能只占用200个字节，但是一个月所累积的10万条交易记录就占用了20M个字节。如果按月对每月的所有交易记录进行综合，所得到的记录可能只占用500个字节。
数据仓库通常的活动是批量载入和查询访问，并不进行一般意义的数据更新，而且其数据冗余程度较高。为了提高查询效率，我们可以采用一些非常规的方法来进行数据分区存储。而且，我们需要对数据仓库中的数据进行方便且有效的监控。
提供数据仓库技术服务的软件厂商大多是从操作型数据库系统发展起来，其推出的数据仓库都是基于其自身研发的大型数据库产品上，且捆绑了相应的ETL，元数据，OLAP，报表等工具，如IBM的DM2，SAS，Sybase，Oracle，Informix，MSSQL Server等。
在本节末要说明一下数据集市(Data Mark)。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。然而，由于各个数据集市之间彼此独立，从而形成新的“信息孤岛”，也造成了重复投资。所以，目前越来越多的数据仓库厂商开始提供帮助企业用户整合原有数据集市，构建集中数据仓库的技术服务。在实际项目中，到底是选择数据仓库，还是选择数据集市，应取决于该项目的主要商业驱动。如果企业正忍受糟糕的数据管理和不一致的数据，希望为今后打下良好的基础，则数据仓库的方案比较好。如果该企业迫切需要给用户提供信息，那么可以先构建一个数据集市。而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。
3)数据分析：OLAP和数据挖掘
OLAP与数据挖掘是一个有机的整体，在OLAP中必定要针对不同的主题数据仓库采用相应的数据挖掘算法来进行数据分析。如果把数据仓库对BI系统的作用比作厨师的食材，那么，OLAP和数据挖掘则是厨具。
联机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd于1993年提出的，其目的是为了让管理者灵活地对海量数据进行浏览分析。当时,Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的需要,SQL对大数据库进行的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此Codd提出了多维数据库和多维分析的概念,即OLAP。Codd提出OLAP的12条准则来描述OLAP系统：
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次
和传统的联机事务处理(OLTP)相比，两者的区别很大，具体情况如下表：
OLTP OLAP
用户
操作人员,低层管理人员
决策人员,高级管理人员
功能
日常操作处理
分析决策
DB设计
面向应用
面向主题
数据
当前的, 最新的细节的，二维的分立的
历史的, 聚集的, 多维的集成的, 统一的
存取
读/写数十条记录
读上百万条记录
工作单位
简单的事务
复杂的查询
用户数
上千个
上百个
DB大小
100MB ~ GB
100GB ~ TB
利用多维的概念，OLAP提供了切片、切块、下钻、上卷和旋转等多维度分析与跨维度分析功能。相对于普通的静态报表，OLAP更能满足决策者和分析人员对数据仓库数据的分析。OLAP系统架构主要分为基于关系数据库的ROLAP（Relational OLAP）、基于多维数据库的MOLAP（Multidimensional OLAP）、基于混合数据组织的HOLAP（Hybrid OLAP）三种。前两种方式比较常见。ROLAP表示基于关系数据库的OLAP实现。它以关系数据库为核心，以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。MOLAP表示基于多维数据组织的OLAP实现。它以多维数据组织方式为核心，使用多维数组存储数据。MOLAP查询方式采用索引搜索与直接寻址相结合的方式，比ROLAP的表索引搜索和表连接方式速度要快得多。
数据挖掘（Data Mining，DM）是指从大量不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、有用的信息和知识的过程。其表现形式为概念（Concepts）、规则(Rules)、模式(Patterns)等形式。
从商业层来看，我个人认为，在商业智能系统中进行数据挖掘的目标大致可分为两类：
①从累积的业务数据中发掘出管理层事先不知道的、但又是潜在有用的信息，为其创造新的商业机会。商业销售已有大量这方面的运用实例，BI业内流传已久的“啤酒和尿布”，以及我在本文开头所举的例子就属此类。
②从累积的业务数据中寻求最优的资源规划方案，降低成本，从而提高利润。让我们先从大家可能都想过一个例子谈起——邮递员送信，假设我是某个城市的邮递员，一次要送出多封信件，收信人的住址分布在城市的各个街道上。那么该如何设计线路，来尽可能的减少行程呢？商业活动中出现大量类似的例子，当可供分析的数据不多时，我们可以用纸笔来手工计算，找到最优解。但是，如果原始数据量极为庞大的话，我们将不得不求助于计算机了。
目前业内已有很多成熟的数据挖掘方法论，为实际应用提供了理想的指导模型。CRISP-DM（Cross-Industry Standard Process for Data Mining）就是公认的、较有影响的方法论之一。CRISP-DM强调，DM不单是数据的组织或者呈现，也不仅是数据分析和统计建模，而是一个从理解业务需求、寻求解决方案到接受实践检验的完整过程。CRISP-DM将整个挖掘过程分为以下六个阶段：商业理解（Business Understanding），数据理解(Data Understanding)，数据准备(Data Preparation)，建模(Modeling)，评估(Evaluation)和发布(Deployment)。其框架图如下：
商业理解就是对企业运作、业务流程和行业背景的了解；数据理解是对现有企业应用系统的了解；数据准备就是从企业大量数据中取出一个与要探索问题相关的样板数据子集。建模是根据对业务问题的理解，在数据准备的基础上，选择一种更为实用的挖掘模型，形成挖掘的结论。评估就是在实际中检验挖掘的结论，如果达到了预期的效果，就可将结论发布。
在实际项目中，一般的事务处理系统甚至一些只提供报表分析功能的简单商业智能系统，建成以后只需要少量的工程维护工作，而采用数据挖掘技术的商业智能系统往往有很大不同。因为数据挖掘是一个商业理解、数据理解、建模、评估等一系列多次反复、多次调整、不断修订完善的过程，并且模型的应用也不是一成不变的，在适当的时候需要更新和重建。所以一般的商业智能项目并不追求一次性工程建设，更倡导的是一种与企业业务紧密联系能够提升企业竞争力的咨询服务，而且熟悉业务和分析方法的分析人员在商业智能系统的应用中起着至关重要的作用。
从技术层来看，数据挖掘技术可分为描述型数据挖掘和预测型数据挖掘两种。描述型数据挖掘包括数据总结、聚类及关联分析等。预测型数据挖掘包括分类、回归及时间序列分析等。
1、数据总结：继承于数据分析中的统计分析。数据总结目的是对数据进行浓缩,给出它的紧凑描述。传统统计方法如求和值、平均值、方差值等都是有效方法。另外还可以用直方图、饼状图等图形方式表示这些值。广义上讲，多维分析也可以归入这一类。
2、聚类：是把整个数据库分成不同的群组。它的目的是使群与群之间差别很明显，而同一个群之间的数据尽量相似。这种方法通常用于客户细分。在开始细分之前不知道要把用户分成几类，因此通过聚类分析可以找出客户特性相似的群体，如客户消费特性相似或年龄特性相似等。在此基础上可以制定一些针对不同客户群体的营销方案。
3、关联分析：是寻找数据库中值的相关性。两种常用的技术是关联规则和序列模式。关联规则是寻找在同一个事件中出现的不同项的相关性；序列模式与此类似，寻找的是事件之间时间上的相关性，如对股票涨跌的分析等。
4、分类：目的是构造一个分类函数或分类模型(也常常称作分类器)，该模型能把数据库中的数据项映射到给定类别中的某一个。要构造分类器，需要有一个训练样本数据集作为输入。训练集由一组数据库记录或元组构成,每个元组是一个由有关字段(又称属性或特征)值组成的特征向量,此外,训练样本还有一个类别标记。一个具体样本的形式可表示为:( v1, v2, ...，vn；c )，其中vi表示字段值，c表示类别。
5、回归：是通过具有已知值的变量来预测其它变量的值。一般情况下，回归采用的是线性回归、非线性回归这样的标准统计技术。一般同一个模型既可用于回归也可用于分类。常见的算法有逻辑回归、决策树、神经网络等。
6、时间序列：时间序列是用变量过去的值来预测未来的值。
早期由于数据挖掘的理论和相关技术尚不成熟，软件厂商并未为其数据库产品开发相应的数据挖掘工具，但当时已有少部分大型企业有这方面的技术需求。所以，市场上出现了一些独立的数据挖掘工具，如SAS公司的Enterprise Miner、IBM公司的Intelligent Miner和SPSS公司的Clementine。现在，随着相关技术的日益成熟，越来越多的企业提出这样的技术需求，软件厂商也意识到其中的潜力，估计在未来的3~5年内，将会出现集成在数据仓库中完备的数据挖掘工具。
最后要提醒大家的是，尽管商业智能应用的前景光明，但是BI业内还没有形成一个统一的标准。而且，由于BI系统的实施是一个长期的、迭代的过程，企业在这个过程中肯定会出现短期利润倒退的情况，这也在很大程度上打击了企业的信心和实践热情。所以，目前绝大多数企业都对此持观望态度，或只在有限的部门内局部实施BI。我个人认为，企业这样做也是相当明智的。但尽管是局部实施，机会还是有的。作为技术人员，可以争取在相关技术的研发上取得突破；作为软件厂商的话，则应从现有老客户和现有产品的技术升级中寻求机会。
