BI相关知识

商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商等来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据。而商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策。为了将数据转化为知识，需要利用数据仓库、联机分析处理（OLAP）工具和数据挖掘等技术。因此，从技术层面上讲，商业智能不是什么新技术，它只是数据仓库、OLAP和数据挖掘等技术的综合运用。

商业智能(BI,BusinessIntelligence)的概念最早是由GartnerGroup提出来的。确切地讲，商业智能并不是一项新技术,它是将数据仓库(DataWarehouse：DW)、联机分析处理(OLAP)、数据挖掘(DataMining：DM)等技术与资源管理系统(ERP)结合起来应用于商业活动实际过程当中，实现了技术服务于决策的目的。

商业智能一直存在于企业的日常工作当中。比如对数据的简单整理、对报表的分析、通过这些分析做出未来若干时间内的工作规划等，这些都是商业智能的表现。随着企业信息化的发展，在应用ERP过程中，大量的数据积累，大量的信息涌现，造成了企业对ERP数据信息的困惑，从而引发了企业对于专业商业智能软件产品的需求。商业智能不再仅仅是一种概念、一种技术，它更多的成为了一种业务层面的需求，为企业应用服务。商业智能产品在制造业领域应用的核心就是通过数据提取、整理、分析，最终通过分析结果制定有关策略、规划，达到资源的合理配置，节约成本提高效益。商业智能在制造业信息化领域大有可为。

商业智能 - 步骤

实施商业智能系统是一项复杂的系统工程,整个项目涉及企业管理,运作管理,信息系统,数据仓库,数据挖掘,统计分析 

商业智能BI应用

等众多门类的知识.因此用户除了要选择合适的商业智能软件工具外还必须按照正确的实施方法才能保证项目得以成功.商业智能项目的实施步骤可分为:

(1)需求分析:需求分析是商业智能实施的第一步,在其他活动开展之前必须明确的定义企业对商业智能的期望和需求,包括需要分析的主题,各主题可能查看的角度(维度);需要发现企业那些方面的规律.用户的需求必须明确.

(2)数据仓库建模:通过对企业需求的分析,建立企业数据仓库的逻辑模型和物理模型,并规划好系统的应用架构,将企业各类数据按照分析主题进行组织和归类.

(3)数据抽取:数据仓库建立后必须将数据从业务系统中抽取到数据仓库中,在抽取的过程中还必须将数据进行转换,清洗,以适应分析的需要.

(4)建立商业智能分析报表:商业智能分析报表需要专业人员按照用户制订的格式进行开发,用户也可自行开发(开发方式简单,快捷).

(5)用户培训和数据模拟测试:对于开发—使用分离型的商业智能系统,最终用户的使用是相当简单的,只需要点---击操作就可针对特定的商业问题进行分析.

(6)系统改进和完善:任何系统的实施都必须是不断完善的.商业智能系统更是如此,在用户使用一段时间后可能会提出更多的,更具体的要求,这时需要再按照上述步骤对系统进行重构或完善

数据仓库

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。 比如武汉播思的Hugatable就是一个基于云计算的超级数据仓库系统。

数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的《建立数据仓库》一书中所提出的定义被广泛接受，数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。 数据仓库是一个过程而不是一个项目；数据仓库是一个环境，而不是一件产品。数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问，的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持。 

数据仓库 - 特点

数据仓库的核心工具

1、面向主题 

操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。 

2、集成的 

数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。 

3、相对稳定的 

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。 

4、反映历史变化 

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库 - 组成

图IBM数据仓库解决方案产品组成

1、数据仓库数据库 

数据仓库的数据库是整个数据仓库环境的核心，是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。 

2、数据抽取工具 

数据抽取工具把数据从各种各样的存储方式中拿出来，进行必要的转化、整理，再存放到数据仓库内。对各种不同数据存储方式的访问能力是数据抽取工具的关键，应能生成COBOL程序、MVS作业控制语言（JCL）、UNIX脚本、和SQL语句等，以访问不同的数据。数据转换都包括，删除对决策应用没有意义的数据段；转换到统一的数据名称和定义；计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。 

3、元数据 

元数据是描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类，技术元数据和商业元数据。 

技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库是用的数据。包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等。 

商业元数据从商业业务的角度描述了数据仓库中的数据。包括：业务主题的描述，包含的数据、查询、报表； 

元数据为访问数据仓库提供了一个信息目录，这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据。是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据。 

4、访问工具 

为用户访问数据仓库提供手段。有数据查询和报表工具；应用开发工具；经理信息系统（EIS）工具；联机分析处理（OLAP）工具；数据挖掘工具。 

5、数据集市（Data Marts） 

为了特定的应用目的或应用范围，而从数据仓库中出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是再实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。 

数据仓库管理：安全和管理；跟踪数据的更新；数据质量检查；管理和更新元数据；审计和报告数据仓库的使用和状态；删除数据；复制、分割和分发数据；备份和恢复；存储管理。 

信息发布系统：把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法。 

数据仓库 - 步骤

济南地税数据仓库系统

1、数据仓库的设计步骤 

1）选择合适的主题（所要解决问题的领域）。 

2)明确定义fact表。 

3)确定和确认维。 

4)计算并存储fact表中的衍生数据段。 

5)确定查询优先级和查询模式。 

2、数据仓库的建立步骤 

1）收集和分析业务需求。 

2）建立数据模型和数据仓库的物理设计。 

3）定义数据源。 

4）选择数据仓库技术和平台。 

5）从操作型数据库中抽取、净化、和转换数据到数据仓库。 

6）选择访问和报表工具。 

7）选择数据库连接软件。 

8）选择数据分析和数据展示软件。 

9)更新数据仓库 。 

数据仓库 - 测试方法

数据仓库价值曲线 

在数据仓库环境下进行测试时如何处理需求与质量的关系。虽然数据仓库的测试是一个惊奇而神秘的过程，但实际上它与其它测试项目并无多大区别。基本的系统分析和测试过程在这里仍然有效。我们来看一下其中的几个步骤，并研究如何在数据仓库环境中应用。 

分析源文件

与其它项目一样，测试数据仓库部署时，通常都会有一份相关的说明文件。虽然这些文件对于创建基本的测试策略非常有用，但经常会缺少一些关于测试开发与执行的详细资料。有时会有一些其它文件解释技术上的细节问题，即从源到目标的转化(source-to-target mappings)说明文件。这些文件详细说明了数据的来源、如何对数据进行操作，以及存储到哪里。如果能拿到这些文件，关于系统设计的文件在设计测试策略时也会变得更加有用。

开发策略和测试计划

分析了各种各样的源文件后，就要开始创建测试策略。我发现从生命周期和质量的角度来看，增量测试是测试数据仓库的最好办法。这从本质上意味着开发团队会从开发过程的早期开始，将各种小组件交付给测试团队。这个办法的主要优点是避免交付让人吃惊的“大块”组件，可以从早期开始检验缺陷，并使调试变得简单。此外，这个方法还有助于在开发与测试周期中建立详细的过程。具体到数据仓库测试，即是对数据获取分段表，然后是增量表、基本的历史表格、BI视图等的测试。

另一个制定数据仓库测试策略的主要问题是基于分析(analysis-based)的测试方式和基于查询(analysis-based)的测试方式的选择。纯基于分析的方法是让测试分析师通过分析目标数据和相关标准计算出预期结果。基于查询的方法有相同的基本分析步骤，但更进一步，用SQL查询语言编写预期结果。这为将来建立回归测试过程节省了很大精力。如果测试是一次性的，那么用基于分析的方式就足够了，因为通常这种方式较快一些。反之，如果企业对回归测试有持续的需求，那么基于查询的方式会更为合适。

测试的开发与执行

不管在测试执行过程之前还是之后进行测试的开发，要根据上行需求的稳定性和分析过程决定。如果情况变动比较频繁，那么早期进行的测试开发可能大部分都会被废弃。这种场合，实时进行的整合的测试开发和执行过程通常会更有效果。不管怎样，在设计测试开发和执行过程的框架时，参考一下测试分类总是有用的。比如，一些数据仓库的测试分类可能有：

记录计数(预期与实际对比) 

副本记录 

参考数据有效性 

参照完整性 

错误与异常逻辑 

增量过程与历史过程 

控制栏值与默认值

除这些分类外，还可以参考缺陷分类学，比如Larry Greenfield的分类。

测试执行时，准确的状态报告过程是经常被忽略的一个方面。在确定团队里的其他人明白你的方法的前提下，测试分类和测试进度可以保证他们对测试状态也有一个清楚的概念。有了详细的规划并坚持到底，以及良好的沟通，就能建立一个数据仓库测试过程，帮助项目团队取得满意的成果。

数据仓库 - 和数据集市

数据仓库基本体系结构

有关决策支持型数据库的数据集市是面向企业中的某个部门或是项目小组的。一些专家顾问将数据集市的建造描述为建立数据仓库全过程中的一步。首先，一个储存企业全部信息的数据仓库被创建，其中，数据均具备有组织的、一致的、不变的格式。数据集市随后被创立，其目的是为不同部门提供他们所需要的那部分信息。数据仓库聚集了所有详细的信息，而数据集市中的数据则是针对用户们的特定需求总结而出的。 

而另外一些专家则认为数据集市的建立并不需要首先建立一个数据仓库。在这个模型中，数据直接由事务型数据库转入数据集市中。一个公司可能建立有多个数据集市，而彼此之间毫无联系。 

这种不在建立数据仓库的基础上创建数据集市的方式会更便宜、更快速，因为它的规模更加易于管理。 

第二种观点的缺陷在于无法实现最初创建数据仓库的最主要的目的——将企业所有的数据统一为一致的格式。现有的事务处理系统的数据往往是不一致、冗余的。如果首先建立起一个全公司范围的数据仓库，组织就能够获得一个统一关于企业的活动和客户的知识库。如果先建立起一个个的数据集市，那么数据仓库的诸多优势都能够得以实现，但是企业远远无法做到对数据的一致的储存。

Pentaho BI

　　一、Pentaho BI 平台介绍 

　　Pentaho BI 平台不同于传统的BI 产品，它是一个以流程为中心的，面向解决方案（Solution）的框架。其目的在于将一系列企业级BI产品、开源软件、API等等组件集成起来，方便商务智能应用的开发。它的出现，使得一系列的面向商务智能的产品如Jfree、Quartz等等，能够集成在一起，构成一项项复杂的、完整的商务智能解决方案。 

　　Pentaho BI 平台，Pentaho Open BI 套件的核心架构和基础，是以流程为中心的，因为其中枢控制器是一个工作流引擎。工作流引擎使用流程定义来定义在BI 平台上执行的商业智能流程。流程可以很容易的被定制，也可以添加新的流程。BI 平台包含组件和报表，用以分析这些流程的性能。目前，Pentaho的主要组成元素包括报表生成、分析、数据挖掘和工作流管理等等。这些组件通过J2EE、WebService、SOAP、HTTP、Java、JavaScript、Portals等技术集成到Pentaho平台中来。Pentaho的发行，主要以Pentaho SDK的形式进行。 

　　Pentaho SDK共包含五个部分：Pentaho平台、Pentaho示例数据库、可运行的Pentaho平台、Pentaho解决方案示例和一个预先配制好的Pentaho网络服务器。其中Pentaho平台是Pentaho平台最主要的部分，囊括了Pentaho平台源代码的主体；Pentaho数据库为Pentaho平台的正常运行提供的数据服务，包括配置信息、Solution相关的信息等等，对于Pentaho平台来说它不是必须的，通过配置是可以用其它数据库服务取代的；可运行的Pentaho平台是Pentaho平台的运行模式的示例，它演示了如何使Pentaho平台在没有应用服务器支持的情况下运行；Pentaho解决方案示例是一个Eclipse工程，用来演示如何为Pentaho平台开发相关的商业智能解决方案。 

　　Pentaho BI 平台构建于服务器，引擎和组件的基础之上。这些提供了系统的J2EE 服务器，安全，portal，工作流，规则引擎，图表，协作，内容管理，数据集成，分析和建模功能。这些组件的大部分是基于标准的，可使用其他产品替换之。Pentaho服务器组件是整套系统的基础， 

　　下面做个简要介绍。 

　　二、Pentaho服务器组件 

　　Pentaho服务器由一个BI 平台和传送最终用户BI 能力的库组成。服务器运行于一个 

　　J2EE 兼容的web 服务器（如Apache，JBOSS AS，WebSphere，WebLogic 和Oracle AS） 

　　上。Pentaho 服务器使得BI 平台的很多功能以一种一致的，熟悉的外观和行为展示给用户。例如，一个组件产生了用户可以访问的报表列表，另一个以日历的方式列出了任务相关的最终期限，第三个显示了用户需要完成的当前任务。每个组件产生的内容 

　　和每个用户的角色相关。Pentaho 服务器包含用于报表，分析，商业规则，email 和桌面通知以及工作流的引擎和组件。这些组件被集成在一起，用于解决商业智能问题。 

　　在一个解决方案（Solution）中，每个子系统的行为，相互作用和用户交互被解决方案（Solution）定义文档的一个集合所定义。解决方案（Solution）定义文档是XML 文档，它包含： 

　　业务流程的定义(XPDL标准) 

　　活动的定义，这些活动按需作为部分流程执行，或被web 服务调用，其包含以下定义： 

　　数据源，查询，报表模板，传送和通知规则，商业规则，仪表盘和分析视图。 

　　以上所有的项之间的关系 

　　服务器中的组件依赖于一个解决方案（Solution）引擎，可获得可用解决方案（Solution） 

　　文档，安全支持，报表，工作流项，数据，和审计信息。在服务器上可以执行多于一个的解决方案（Solution）。解决方案（Solution）定义文档可从一个服务器复制到另一个，并可被自由分发。服务器包含如下部分： 

　　高级系统管理的基础设施。这包括系统监控(SMNP)服务，使用报表，Web 服务支持，配置确认工具，和诊断工具。 

　　高级流程性能报表和分析的系统和组件。这包括工作流任务上涉及到的工作流项目，单独任务，employees 和services 上属性的切片和切块（slice-and-dice），what-if 和数据挖掘能力。 

　　支持Enterprise Application Integration (EAI)，用于和operational 应用live集成，以及Extract, Transform, and Load (ETL) 能力，用于创建数据仓库和数据集市。 

　　三、Pentaho软件层次结构 

　　Pentaho平台是Pentaho运行系统中的核心部分，它本身是一个Web应用，部署于一个J2EE兼容的应用服务器上。它又作为Solution的服务器存在着，是Solution中各个Action序列的解释执行者。Pentaho平台大致可分为三个层次：界面层、核心层和插 

　　件层。界面层是外部用户访问Pentaho服务的接口，主要包含三个部分：UDDI、Web页面、Navigation Component。UDDI为外部应用程序或Web Service访问Pentaho服务提供接口；Web页面则为用户通过浏览器访问Pentaho服务提供接口；Navigation Component实质上是一组Servelet，它主要用于显示当前部署在Pentaho平台上的Solution中所包含的 

　　各个Action序列，用户可在其中选择需要执行的Action序列。 

　　核心层主要由Solution Engine和它的Runtime环境组成。Solution Engine实质上是一个解释执行Action序列描述文件的解释器，它接收来自用户界面的请求，这个请求通常是要求执行Solution中的某个Action序列。Solution Engine连同其Runtime环境就负责解释执行这些Action序列。解释执行过程中，出于调试和性能分析的需要，引入了一个Audit机制，该机制类似一个日志记录系统，记录Pentaho平台运行过程中的一些动态过程。Solution Engine和Audit机制的运行都需要访问许多相关的数据资源，这些数据资源被称为"资源库"，也就是图中的各个Repository。 

　　插件层主要包括了集成到Pentaho平台中的各种BI产品，如Quartz、Jfree等等。从图3中可以看出，插件层又可分为两类模块，一类叫作Component模块，这种模块是插件层与核心层的接口模块，它们将各种不同的插件的功能以一个统一的接口提供给上层使用，起到一个功能抽象的作用。另一类则是形形色色的BI插件的具体实现，这通常由第三方开发者提供。各种插件运行过程中可能会用到自身的私有数据，这些数据在Pentaho平台中也被抽象成为资源库（Responsory），这使得不同的插件可以以一种统一的方式访问自己的数据。