【IT168技术文档】

3.3 理解历史数据和分析需求

  历史数据也就是业务数据库，它是数据仓库的数据来源，是构建数据仓库的“物质基础”。需求在每一个工程项目中都很重要，它是数据仓库的价值体现。因此理解历史数据和分析需求是5步中的第1步。下面先从理解“用户驱动＋数据驱动”的设计理念开始。
3.3.1 “数据驱动＋用户驱动”的设计理念

  数据驱动是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库。

  用户驱动也叫需求驱动，是根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。

  数据仓库的用户一般是企业管理者，分析需求和业务需求有很大差异，因此不能把数据库设计阶段的用户需求直接用在数据仓库设计中。在设计仓库数据库之初把用户的分析需求纳入考虑范围是十分有必要的。同时，数据仓库的构建必需基于业务数据库，业务数据源的结构也是不得不考虑的问题。因此在设计数据仓库的时候，应该坚持用户驱动与数据驱动相结合的设计理念。图3-20所示的是这两种方法结合获取数据仓库设计真正需求的过程。

3.3.2 理解业务数据

  由图3-20可知，通过对业务数据的分析，可以清楚的知道原有的数据库系统中已经有什么，对当前系统设计有什么影响等，也可以为利用已有的数据和代码提供方便。这样，在把业务数据转化为分析数据时，便于按照分析领域对数据（即数据之间的联系）重新考察，组织数据仓库的主题。
1．理解业务

  需求是项目的动力，使用则是项目的根本。构建数据仓库归根到底是应用于企业数据分析，辅助管理决策，这是设计人员应该在数据仓库的整个生命周期都牢记于心的。

  理解业务数据的首要一步就是理解业务，也就是要熟悉企业生产经营流程，同时初步获取在这些流程中的分析需求，为最终确定用户需求做好意识上的准备。

  例如在Adventure Works Cycles这个经营自行车及其相关配套产品的公司内部，原材料采购、生产和销售及相关的财务和管理等有既定的流程。下面以原材料采购和产品的销售两个业务领域为例进行分析。
1）原材料采购

  在公司内部有采购部负责原材料采购，采购部门下设一个经理和多个采购员。一种原材料有多个供应商，一个供应商可以提供多种原材料。原材料和供应商之间是多对多的关系。每个采购员负责多种原材料的采购，一种原材料只能由一个采购员来采购。采购员和商品之间是一对多的关系。采购员只需了解原材料和供应商的联系，而采购部门经理需要管理员工，并且还需要了解原材料的仓储情况，以确定需要采购的商品并将任务分配给每个采购人员。

  另外，公司为了防止产品过分依赖于原材料价格，还需要对原材料进行批量存储，因此设立仓库管理部门，专门负责原材料的存储管理，仓库管理部门管理多个仓库，下设一个经理和多个仓库管理员，每个仓库中拥有多个仓库管理员，每个管理员只能在一个仓库中进行工作。

  仓库管理员需要知道他所管理的仓库中存储的原材料的种类、数量、存储的时间、原材料的保值期及原材料进入仓库和离开仓库的时间等信息。一种原材料可以保存在多个仓库中，一个仓库可以保存多种原材料。

  仓库管理部门经理不但需要处理仓库管理员需要的数据，而且需要知道仓库管理员的基本信息（比如仓库管理员的家庭住址和电话等）。
2）产品销售

  Adventure Works Cycles的自行车及其相关产品远销北美、欧洲和亚洲市场。公司有网络销售和通过批发商销售两种销售渠道，因此，对于客户也分为两类，其一是个人，即从在线商店购买产品的消费者，其二是商店，即从Adventure Works Cycles销售代表处购买产品后进行转售的零售店或批发店。

  对于销售部门，销售员关心的是商品的信息，每种商品的价格、质量、颜色和规格等，以便向顾客推销相关的产品。因此，销售员最需要的数据就是商品的信息。销售部门经理不但需要了解商品的销售情况，以便在某种商品缺货的时候通知仓库存储部门运送存储的商品，或者通知采购部门采购相应的原材料。销售部门经理还需要了解每个销售员的工作业绩，对每个销售员进行考核。因此销售部门经理需要了解商品、顾客和部门员工的情况。
 
  从上面的分析可以看出，商务数据确实是多维的。不同部门对数据的需求不同，同一部门人员对数据需求也存在差异。如果考虑数据需求的层次问题，管理人员和不同的业务人员对数据要求的程度也各不相同。管理人员可能需要综合度较高和较为整体的数据，而业务人员需要细节数据。

  在前面分析仓库中的立方体的时候，曾经讲到过要对数据立方进行不同视角的分析（图3-8），在这里可以看到，这种分析是符合业务操作的实际情况的。

  同时，可以用业务构成图来表达业务理解的分析成果。对于上述的分析，可以用图3-21来表达。需要注意的是，这只是对Adventure Works Cycles公司业务分析的一个简单示例，在实际项目中情况要复杂得多，为了获取这个业务构成图，可能需要借鉴企业信息化中的其他阶段的成果，如可以把 ERP构建构成的业务流程重组成果用在这里。

  有了这样一个清晰表达业务结构的图，就为后面建立分析主题打下了很好的基础。

2．理解业务到数据的转化

  实际上，对业务的理解是信息系统建设过程都需要的，只不过在设计数据仓库的时候理解业务需要着重从业务蕴含的数据的多维性方面来分析。而业务到数据的转化这一步则主要是在构建OLTP系统时使用的。数据仓库都是以历史数据为基础的，这一步本质上是理解这些历史数据的来历。

  在构建OLTP系统的过程中，一般先把业务转化为E-R图，也称为OLTP的逻辑模型图，这在许多数据库系统设计的书籍里都有详细说明，这里就不再描述。图3-22是把企业业务模型和通过E-R图这种工具转化成数据后的数据表对应起来的一种关系图。它实际上表达了从业务到数据的过程。
3．理解OLTP数据

  OLTP数据是数据仓库数据库的物质基础，只有对它的内容及其构成足够熟悉，在设计数据仓库和以后对数据进行ETL过程的时候才有可能得心应手。

  首先是要明确数据的结构。比如AdventureWorks数据库为了能处理Adventure Works Cycles公司的业务数据，把这些数据分成了5个架构，分别是表示人力资源的“HumanResources”，表示人员信息的“Person”，表示产品信息的“Production”，表示采购信息的“Purchasing”和表示销售信息的“Sales”，从前面的分析可知，这些架构囊括了此公司的大部分业务。

其次是要明确数据的内容。

  数据内容包括某个业务领域的数据表构成及其主外键关系，还包括各个数据表的具体字段构成情况。下面理解AdventureWorks业务数据库中的数据内容，限于篇幅的影响，这里只对一部分在分析和数据挖掘过程中十分重要的数据内容进行分析。

l 个人客户相关的数据

  个人客户是公司客户类型的一大类，即从Adventure Works Cycles在线商店购买产品的消费者。若“Sales.Customer”表的“CustomerType”列值为‘I’则表示客户类型为个人，若为 ‘S’则为批发商。与个人客户相关的表有5个分别是“Person.Contact”表示客户的联系方式、“Sales.Customer”表示客户的类型和“Sales.Individual”表示个人客户的具体信息，其中“Demographics”列还以XML格式对收客户的收入、爱好和车辆数目等进行了统计，而对于客户的订单信息则放在“Sales.SalesOrderHeader”和“Sales.SalesOrderDetail”两个表中。

l 产品相关的数据

  Adventure Works Cycles公司提供4类产品。一是公司自己生产的自行车。一是自行车组件（替换零件），例如，车轮、踏板或刹车部件。还有就是从供应商购买来转售给客户的自行车装饰和自行车附件。

  和产品相关的表比较多，结构也较为复杂，下面以表格的形式分析这方面的数据内容。

  表3-4 产品相关的表及其数据理解