OLAP项目的一般过程

摘要:

按照时间顺序编写商业智能开发过程中可能遇到的各个阶段；各个阶段可能遇到的问题，如何注意这些问题。

u       需求阶段：

1.  需求阶段习惯上也就是客户提出要求的阶段，这个阶段原则上我们应该积极主动与客户联系，听取他们的需求。他们对数据仓库的了解没有那么深刻，但是提出的问题却是很现实的他们解决不了的，需要我们协助解决的问题。

2.  需求阶段是重要的一个环节，跟一般的软件需求一样，需要明确我们的OLAP系统要实现的是什么。这个阶段我们可以先不考虑我们的技术是否可以实现，只要目前世界上有这样的技术我们就可以应允，技术可以是在开发过程中学习的，在以后的项目中我们会继续遇到类似的问题，那个时候我们的技术也就相对成熟了。

3.  需求阶段是我们跟客户互动的阶段。客户在跟我们的沟通过程中也会逐渐的发现数据仓库还可以实现什么，所实现的功能用到他们的项目中是否会有大的帮助。这样，我们也在向客户输送数据仓库的相关信息，也在宣传着我们的技术或者产品。客户所在的行业，可能在之前我们都没有接触涉及过，相关的行业经验缺乏，这个过程也是我们学习了解相关行业知识积累行业经验的过程。

4.  这个过程双方达成协议，并签署合同。

u      策划阶段：

1.      在需求分析的基础上，我们对整个项目的整体规模有了一定的了解。接下来就是要把项目工程化，应用软件工程一般规则策划整个项目。

2.      从大体上确定需要多少人力投入这个项目，这些人对项目所涉及行业熟悉吗，是否需要培训相关的行业知识。如何根据项目组成员个人技术能力分配相关工作，如果项目过程中有人离开项目组或者离开公司怎么处理等。

3.      策划阶段也需要不时的与客户沟通，比如根据合同的内容安排项目的进度等。如果没有协调好就可能发生某些不符合合同要求的情况。

u      设计阶段：

设计阶段是整个OLAP项目的规划阶段，属于架构或者计划。将来的分析开发阶段都将根据设计阶段规定好的架构进行。因此设计阶段是非常重要的。不可否认设计阶段架构的框架可能在后续的开发过程中发现错误，需要重新架构。为了尽可能避免这种情况的发生，宁可多话时间在分析研究，或者实行多种方案，有备用的方案应急。

u      编码阶段：

ü        模型分析

1.        定义问题，确定分析的目标：

OLAP和数据挖掘是商业智能家族中两种重要的技术。

OLAP的优势体现在其在维度定义基础上对数据的预先聚合、对复杂查询分析放映速度快；OLAP可以解决如下典型问题：

1．            饮料在过去三个月内在某个地区的销售总额是多少。

2．            上个月所有商店汇总过来的销售最好10中产品是什么。

3．            男性顾客＆女性顾客购买量分别是多少。

4．            促销期间＆非促销期间的日均销量有什么区别。

数据挖掘的优势体现在通过分析属性间的相互关系发现隐藏的规则或者规律。数据挖掘可以回答如下典型问题：

1．            哪些类型的消费者有可能购买新潮的数码相机。

2．            哪些商品适合推荐给某特定消费者。

3．            接下来的三个月数码相机的销量预计会是多少。

4．            如何按照某种规则给消费者群体分组、分类。

在很多情况下，隐藏规则、模式的挖掘、发现需要在聚合数据的基础上才能实现；直接从事实数据表挖掘隐藏规则、模式是困难甚至是不可能实现的。多维数据集的维度可能包含数百万的成员以及上千万的聚合值；跟关系数据库中的数据一样，多维数据集中也包含了某些隐藏的规则、模式，这些隐藏知识的发现需要数据挖掘的辅助。

在具体项目中，我们可以同时向客户推荐这两种技术或者根据他们的问题描述确定使用哪种技术。

 

2.        准备数据，ETL：

建模过程需要比较清晰的逻辑思路。一般需要对基础的业务数据库结构比较了解，也就是对数据源的理解。

客户提供的数据源可能由于来自不同的部门而有多种形式，比如平面文本文件，excel，access等，或者来自非Sqlserver的关系数据库，如mySql，sybase，db2，oracle等。有了SSIS（SQL Server Integrating Service），对这些不同格式的数据源的整合变得相对容易些。数据源数据也可能包含缺陷项或缺少项之类的不一致性。例如，数据可能显示客户在其出生日期之前购买产品，或者客户在距离她家 2,000 英里的商店定期购物，再比如男性客户的老公信息或者带有中文字符的不标准的时间等等。这些在生成模型之前，甚至定义数据源视图之前就应该解决，纠正，否则将会出现错误的信息或者挖掘出错误的模型。上述过程属于ETL过程，SSIS提供大量工具，这些工具已经涵盖或者取代了SQL Server 2000的DTS（Data Transform Service）。

SSIS可以解决大部分上述的问题。通过设置数据流源和数据流目标的格式，数据流转换工具控件就可以实现对不同格式数据的整合。控制流工具中容器的应用可以实现循环或者根据函数脚本来判断控制流的分支，最终实现数据向预定的类型转换。比如，从一个文件中根据文本规则（如空格标识，或者‘|’标识），吸取出某些数据作为数据库的某个字段的记录；把名和姓两个分开的字段合并成一个字段等等。数据流控件中还提供了专门处理AS的工具控件，如UDM，SCD处理控件，数据挖掘查询控件等。ETL流程也可以通过构建Package来完成了，众多的DTS函数和图形化界面的操作省去很多繁琐的操作，元数据、函数都可以通过拖拽来实现。难点在于函数与函数、函数与脚本的组合使用。在IS中，也可以使用用户自定义组件，结合VS的组件开发，我们可以开发符合我们特定需要的IS组件，功能很强大。我们甚至可以对客户说，没有我们不能处理的数据源。

3.        浏览数据源，分析关联：

这里指的数据源已经是经过ETL处理后的数据源了，否则所作分析、关联将是无效或者错误的。个人感觉构建多维立方体的最关键一个环节就是分析设置众多的表与表之间的关联。表与表之间，字段与字段之间的关联分析设置

4.        构建模型：

A.       根据提供的数据源和客户需求确定分析的主题

分析的主题最终也就是提供给用户的立方体，通过透视（Perspective）还可以细分虚拟立方体，指定某些角色可以分析的角度。

B.       根据分析主题确定分析粒度

事实粒度需要根据提供的基础表的详细情况而定，一般而言，字段多分类详细的基础数据可以建立比较细致的粒度。粒度的确定也是根据用户的需求而定的，对于领导层次的分析，虽然可以建立明细的粒度，但是他们往往只是需要知道总体的情况、趋势。粒度越小，提供的信息越详细。

C.       根据分析主题以及数据源确定事实度量

量度组直接来源于事实表，事实表中数字型（如int，smallint等）的字段都可用作度量来使用，很多时候只是抽取需要的数字型字段。但是有些时候需要统计的量在事实表中没有相应的数字型字段，这个时候就需要增加字段或者设置相应的关联。有些时候需要统计的量恰恰是字段中某个非数字型的字段，这个时候需要做相应的变换，或者增加含有对应数字型的代码表，或者直接在构建数据源视图的时候做转换处理（需要比较复杂的Sql语句）.不包含任何数字型字段的事实表也可以有度量，那就是对主键的count计数。

D.      确定分析问题的角度（维度创建）

分析问题的角度也就是立方体的维度。比如销售立方体，可能需要从时间，地点，分销商，消费者，促销信息等角度进行分析。维度层次结构分为属性层次结构和用户层次结构，属性层次结构可由系统（Visual Studio 商业智能 Solution）自动完成构建，需要修改部分属性细节；重点在用户层次结构，需要注意的事项比较多，而且需要根据用户的分析需求修改属性，比如排序、聚合方式、层次属性是否可见等。

E.       形成多维数据集，验证多维数据集，修改更新多维数据集

5.        浏览、测试、验证模型：

6.        部署、更新模型：

 

ü        前端展现

特定项目一般需要特定的展现程序，我们可以通过修改淘金者来展示立方体，或者用Reporting Service,或者开发新的C\S 或者B\S结构的程序来实现特定的展现。ReportingService虽然只能在界面上提供静态的报表，但是报表的展示内容却可以由用户来自行决定，因为RS报表生成器也是拖拽式的工具，操作简单。用户只要知道业务分析常用的报表即可。OWC的表格＆图形展现也是比较成熟的，有微软的技术支持，我们只要知道则怎么用，怎么赋值就可以。

在多维数据集的前端展现方面，我们已经有比较成熟的技术。对Analysis Service AdomdClient有比较熟悉驾驭能力，  对AMO的理解还比较浅，但是以及知道了其能够实现什么，我完全可以熟悉并掌握它。

对数据挖掘模型的展现也不是问题，Analysis Service AdomdClient下已经提供了展示微软提供的11种挖掘模型的控件，在.NET下可以方便的开发。

u      测试阶段：

u      试运行阶段：

u      验收阶段：