[转]Amtura 商务智能项目实现手记

http://blog.bridata.ca/?p=458

Amtura 公司总部位于美国宾州，是一家从事 ERP 软件和通信软件的公司。总部大约有700多管理人员，3个公司的分部分别在加州和得克萨斯州。ERP 软件的客户主要是包装产品生产企业，在美国由于生产企业的分工很细，很多生产企业并不亲自包装自己的产品，而是由专门的包装公司负责包装，也有的包装企业负责给客户提供特定的包装产品，但是这些包装企业往往很专业也很大。Amtura 的软件产品就是面向这些包装企业的。

项目简介：

Amtura 的 ERP 系统虽然有专用的领域，但是也有生产企业  ERP 系统的一般特点，也分几个主要的模块：预订、生产、销售、库存、人力资源和财务管理。客户需要在基于已有的 ERP 系统基础之上，建立一个可提供历史数据分析和决策支持的商务智能系统，BriData 公司就承接了这个BI 项目，以帮助Amtura 实现一个完整的包括计划、实施和维护各个环节的商务智能项目。为了协调我们公司的工作，Amtura 安排了一个项目经理、一个高级程序员来配合我们的工作。

技术背景：

Amtura 的现有的 ERP 系统使用的是以 SQL Server 和 Informix  为数据平台，以 .NET 为主要开发工具的软件产品。当前使用的开发版本是: SQL Server 2005, Visual Studio 2005, Informix，从数据库平台的角度说，他们的客户即有运行在SQL Server 上的 ERP 系统，也有运行在 Informix 上的 ERP 系统，甚至同一的用户不同的分支也使用不同的数据库平台。通过对这套 ERP 系统进行分析，我们对其基本的数据有了一个大概的了解：

  1. 单一 Database，单一 Schema；
  2. 不同的用户数据库的容量不同，大约的范围在 20 G – 1T 之间；
  3. 大约 200 个数据表 (Tables)，与建设 BI 系统有关的表大约有100 个左右； 
  4. 有的表的字段数甚至超过了100个；
  5. 没有统一的命名标准 (Naming Convension);
  6. 表的设计没有严格的遵守 Normalization；
  7. 没有严格的字段或外键约束定义；
  8. 没有数据 Changing Capture (变化捕获)；

通过以上的特点不难发现，最后一项： 没有Changing Capture 的功能将会极大地影响建设数据仓库的进度和性能，其他的数据缺憾相比而言却容易修正。我会在以后再详细地介绍我们使用的策略。

项目目标：

  1. 合并、清理数据以实现 Master Data Management;
  2. 建立 Metadata Management 机制；
  3. 建立数据仓库以提高对历史数据的统计速度；
  4. 建立Data Mining 模型；
  5. 建立可维护的、多角度的数据仓库访问途径；
  6. 建立企业 Portal;

开发工具选择：

  1. 数据库平台选择SQL Server 2008 企业版
  2. OLAP 平台选择SQL Server 2008 Analysis Services
  3. ETL 工具初步选择 SQL Server 2008 Integration Services 和 SQL 结合的方式
  4. 数据建模工具和架构设计工具选择 Visaul Visio 和 CA ERwin
  5. OLAP 访问工具选择 SQL Server 2008 Reporting Service 和 Excel 2007
  6. 企业 Web Portal 选择 SharePoint Server 2007
  7. 根据 MS Office 2010 的发布时间，考虑向 MS Office 2010 的移植。

--[二]

我们实施这个项目的第一阶段包括2个星期的系统设置和2个星期的原数据库结构分析。

系统设置

系统设置我们进行了基本开发环境的安装和调试，建立了开发服务器、开发测试服务器和产品测试服务器。在这些服务器上我们安装了：Visual Studio 2008, MS SQL Server 2008, SharePoint Server 2007, PerformancePoint Server 2007 等一些必要的开发工具以及客户数据的副本等。在项目的初期我们采用 Visual Sourcesafe 作为源代码控制的平台，但是同时也安装了 TFS 作为下一个项目管理和原代码控制的主要工具。

原数据分析

原数据库分析的过程主要是对原有 ERP 系统的业务流程进行分析，同时结合客户的初步需求建立一套业务逻辑和数据逻辑的文档，这些文档的建立将会为以后数据仓库的建设和维护带来极大的便利。在原数据分析阶段，我们设计了一下几个内容：

  • 原数据文档，主要用于在描述数据间的逻辑关系
  • 原数据数据模型 (Data Module)，由于原有的 ERP 系统没有及时跟新已有的 ER Diagram, 所以我们需要在他们的写作之下完成这个任务。
  • 数据轮廓 (Data Profiling) 及数据轮廓报告，这也是原数据分析的重要的环节。数据轮廓报告为下一步的 ETL 处理和数据仓库建模提供了基础。

总的来说，2个星期的原数据分析显然是很紧张的，在实际的项目实施中，原数据分析其实会贯穿于整个项目的始终，这个阶段的原数据分析的主要目的是让我们的项目实施方对原有的系统有个大概的了解。

 

Amtura 商务智能项目开发环境设置：

服务器：Windows Server 2003 企业版。虽然公司已经购买了 Windows Server 2008，但是我们的用户仍然使用 Windows Server 2003, 所以我们不得不在 Windows Server 2003 的基础之上进行设置和测试。服务器端需要进行一下的设置：

  • 安装最新的 Service Patch
  • 安装 MS SQL Server 2008 企业版及其 Service Patch
    • MS Reporting Services
    • MS Integration Services
    • MS Analysis Services
  • MS Office SharePoint 2007 和 Servie Patch
  • MS Reporting Service for SharePoing Add-on，
  • Setup Excel Services in SharePoint Server, 这是一个非常麻烦的设置工程，我会在另外的文章里专门介绍。
  • PerformancePoint 2007。这个安装最为繁琐，因为PerformancePoint 是在 SQL Server 2008 之前发布的，所以它并不直接地支持SQL Server 2008，还需要很多设置才能使用。
    • ASP.NET AJAX Extension 2.0， 只是安装 PerformancePoint 2007 所需要的。
  • FrontPage Server Extensions， 这个需要在服务器端设定。

 开发客户端：Windows XP, Visual Studio 2008, SQL Server 2008 客户端.

设置Cube 处理日志不但是产品设计阶段还是发布阶段的重要过程，Cube 处理日志的一个重要内容就是记载失去关联的Fact表和Dimension 表的外键链接。在 ETL 处理中根据业务的需要，可以将错误的外键关联、错误的外键值等删除、忽略或者重新导入，但是在Cube 的处理过程中，仍然可以记载这些错误或者例外，比如 可以将不满足的外键自动链接到 ‘Unkown’ 值。

可以在 Measure Group 或 Measure 属性中设置 自定义的错误捕获，以记载诸如：重复的键值、未发现的键值、空键值等，在处理Cube的过程中可以忽略这些错误记录使得处理不被打断，但是最好的设计应该仍然使系统记载这些错误，以便在ETL中加以处理。

Log 文件的路径可以自己定义，但是在发布 Cube 到实际产品的过程中应该考虑：

  • 保存在一个Cube 处理用户拥有权限的路径中；
  • 使用不同的文件名保存不同的 Cube ， 使分析错误更为具体
  • 使用标准的 Log 后缀作为扩展名； 
posted @ 2012-03-20 17:01  野三坡  阅读(249)  评论(0)  编辑  收藏  举报