数据驱动及用户驱动数据仓库设计理念.docx

数据驱动及用户驱动数据仓库设计理念理解历史数据和分析需求历史数据也就是业务数据库，它是数据仓库的数据来源，是构建数据仓库的“物质基础”。需求在每一个工程项目中都很重要，它是数据仓库的价值体现。因此理解历史数据和分析需求是5步中的第1步。下面先从理解“用户驱动数据驱动”的设计理念开始。3.3.1 “数据驱动用户驱动”的设计理念数据驱动是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库。用户驱动也叫需求驱动，是根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。数据仓库的用户一般是企业管理者，分析需求和业务需求有很大差异，因此不能把数据库设计阶段的用户需求直接用在数据仓库设计中。在设计仓库数据库之初把用户的分析需求纳入考虑范围是十分有必要的。同时，数据仓库的构建必需基于业务数据库，业务数据源的结构也是不得不考虑的问题。因此在设计数据仓库的时候，应该坚持用户驱动与数据驱动相结合的设计理念。图3-20所示的是这两种方法结合获取数据仓库设计真正需求的过程。图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构建构成的业务流程重组成果用在这里。有了这样一个清晰表达业务结构的图，就为后面建立分析主题打下了很好的基础。 图3-21 业务构成图2理解业务到数据的转化实际上，对业务的理解是信息系统建设过程都需要的，只不过在设计数据仓库的时候理解业务需要着重从业务蕴含的数据的多维性方面来分析。而业务到数据的转化这一步则主要是在构建OLTP系统时使用的。数据仓库都是以历史数据为基础的，这一步本质上是理解这些历史数据的来历。在构建OLTP系统的过程中，一般先把业务转化为E-R图，也称为OLTP的逻辑模型图，这在许多数据库系统设计的书籍里都有详细说明，这里就不再描述。图3-22是把企业业务模型和通过E-R图这种工具转化成数据后的数据表对应起来的一种关系图。它实际上表达了从业务到数据的过程。3理解OLTP数据OLTP数据是数据仓库数据库的物质基础，只有对它的内容及其构成足够熟悉，在设计数据仓库和以后对数据进行ETL过程的时候才有可能得心应手。首先是要明确数据的结构。比如AdventureWorks数据库为了能处理Adventure Works Cycles公司的业务数据，把这些数据分成了5个架构，分别是表示人力资源的“HumanResources”，表示人员信息的“Person”，表示产品信息的“Production”，表示采购信息的“Purchasing”和表示销售信息的“Sales”，从前面的分析可知，这些架构囊括了此公司的大部分业务。图3-22 企业业务及其对应的数据表的关系其次是要明确数据的内容。数据内容包括某个业务领域的数据表构成及其主外键关系，还包括各个数据表的具体字段构成情况。下面理解AdventureWorks业务数据库中的数据内容，限于篇幅的影响，这里只对一部分在分析和数据挖掘过程中十分重要的数据内容进行分析。个人客户相关的数据个人客户是公司客户类型的一大类，即从Adventure Works Cycles在线商店购买产品的消费者。若“Sales.Customer”表的“CustomerType”列值为I则表示客户类型为个人，若为S则为批发商。与个人客户相关的表有5个分别是“Person.Contact”表示客户的联系方式、“Sales.Customer”表示客户的类型和“Sales.Individual”表示个人客户的具体信息，其中“Demographics”列还以XML格式对收客户的收入、爱好和车辆数目等进行了统计，而对于客户的订单信息则放在“Sales.SalesOrderHeader”和“Sales.SalesOrderDetail”两个表中。产品相关的数据Adventure Works Cycles公司提供4类产品。一是公司自己生产的自行车。一是自行车组件（替换零件），例如，车轮、踏板或刹车部件。还有就是从供应商购买来转售给客户的自行车装饰和自行车附件。和产品相关的表比较多，结构也较为复杂，下面以表格的形式分析这方面的数据内容。表3-4 产品相关的表及其数据理解数 据 表数据表内容的理解Production.BillOfMaterials用于制造自行车和自行车子部件的所有组件的列表。ProductAssemblyID 列表示父级产品（即主产品），ComponentID 表示用来组成父级部件的子级零件（即独立零件）Production.Culture列出使用了哪些语言来本地化产品说明 Production.Location列出产品和零件的库存位置（续表） 数 据 表数据表内容的理解Production.Product由公司销售或用来制造自行车和自行车组件的各种产品的信息Production.ProductCategory产品最常规的分类。例如，自行车或附件Production.ProductCostHistory列出不同时间点的产品成本Production.ProductDescription列出各种语言的详细产品说明Production.ProductInventory按地点统计的产品库存量Production.ProductListPriceHistory列出不同时间点的产品价格Production.ProductModel与产品关联的产品型号ProductModelProductDescriptionCulture给出产品型号、产品说明及其本地化后的语言之间的交叉引用Production.ProductPhoto列出所售产品的图像Production.ProductReview给出客户对产品的评价Production.ProductSubcategory产品类别的子类别 原材料采购相关数据此公司通过采购部门购买自行车生产中使用的原材料和零件，同时也购买一些产品以进行转售，例如，自行车装饰件和自行车附件，像水瓶和打气筒。和原材料采购相关的表也比较多，同样以表格的形式列出其数据内容如表3-5所示。表3-5 原材料采购相关的表及其数据理解数 据 表数据表内容的理解Person.Address所有客户的通信地址信息Person.Contact供应商雇员的姓名，与“VendorContact”表相关联，将联系人映射到供应商。XML数据类型的列“AdditionalContactInfo”包含了联系人的其他联系方式（手机和传真等）Production.ProductVendor将供应商映射到其提供的产品Purchasing.PurchaseOrderDetail采购订单的详细信息，例如，订购的产品、数量和单价Purchasing.PurchaseOrderHeader采购订单的摘要信息，例如，应付款总计、订购日期和订单状态。“PurchaseOrderHeader”表与“PurchaseOrderDetail”表共同构成主-从关系Purchasing.ShipMethod用于维护产品标准发货方法的查找表。“ShipMethodID”列包含在 “Purchase OrderHeader”表中Purchasing.Vendor供应商的详细信息，例如，供应商的名称和账号Purchasing.VendorAddress将客户链接到“Address”表中的地址信息。按类型对地址进行分类，例如，开票地址、家庭住址和发货地址等。“AddressTypeID” 列映射到“AddressType”表中Purchasing.VendorContact这是一个关联表。连接“Contact”和“Vendor”两个表以上只是对商务分析时特别重要的业务数据进行了分析，目的是提供一个可供项目参考的示例，若要完全理解业务数据，还要对数据库中的表及其关系进行更加深入的理解。这里以原材料采购数据中的表“Purchasing.PurchaseOrderHeader”为例子分析表的具体构成。如表3-6所示。在后面的ETL过程及商务分析和商务规则的挖掘等操作中会发现，这些分析是有相当大的好处的。因此在实际项目中，应该对每一个业务数据表进行类似的分析。表3-6 Purchasing.PurchaseOrderHeader表的具体分析列数 据 类 型说 明PurchaseOrderIDint主键RevisionNumbertinyint用于跟踪一段时间内采购订单变化的递增编号Statustinyint订单的当前状态。1 = 等待批准，2 = 已批准，3 = 已拒绝，4 = 完成EmployeeIDint创建采购订单的雇员。指向“Employee.EmployeeID”的外键。VendorIDint采购订单所采购的产品的供应商。指向“Vendor.VendorID”的外键ShipMethodIDint发货方法。指向“ShipMethod.ShipMethodID”的外键OrderDatedatetime采购订单的创建日期ShipDatedatetime预计供应商的发货日期SubTotalmoney采购订单小计 TaxAmtmoney税额Freightmoney运费TotalDuemoney付给供应商的应付款总计。计算方式为 SubTotal + TaxAmt + FreightModifiedDatedatetime行的上次更新日期和时间3.3.3 确定用户对分析型数据的需求在业务数据理解的任务中，明确了企业的具体业务映射到数据库系统的细节，数据仓库的设计者对现有数据库系统完成了企业数据需求中的哪些部分，还缺少哪些部分已经心中有数。这一节的任务是从企业的各个视点对企业数据分析需求加以挖掘，发现企业需要的（或可以构造的）主题，为需求到数据仓库的映射打下基础。1对用户需求分类分类是认识事物的一种好方法。要真正清楚地理解用户的需求，根据一定的标准对需求划分类别是很有必要的。实际上企业每个部门都有对企业业务观察的不同视角，这是需求多样性的一个方面。例如对于类似Adventure Works Cycles的一个商务企业来说销售部门、采购部门和仓库管理部门等都有相应的视角，尽管这些业务是相关的，而且是作为一个整体形成企业业务流程的。因此，对数据的需求，特别是对分析数据的需求必然有所不同，图3-23是对这种现象的示意。 图3-23 对企业流程中的不同视角创建企业级数据仓库是一个应全面考虑的工程，但它的需求是相当模糊的，对需求按照其业务视角进行分类以后，可以对用户报表的需求、历史数据的保留、要包括的数据本质、要排除的数据本质、获取数据的地方、数据的迁移和数据的复制等方面的需求进行明确。为完成分类的任务，一般在分类前要问2个问题：在公司中，用户所在部门承担的任务是什么？用户在部门中承担的任务是什么？在具体分类时，由于涉及到部门信息的使用方式，需要回答3个问题：为完成该任务，将使用什么样的报表？目前从何处获取这些信息？得到信息后，如何处理它？分类结束后，为了能为下一步的工作做准备，需要关注3个问题：这些信息通常是应用户的需要产生的，还是在某些定期报表中找到的？用户曾把这些信息输入工作表中，以便进一步分析吗？怎样处理这些信息才算及时？2准备需求采集数据仓库主要由用户操作，用户就是顾客。用户的需求不能想当然，所以为了确保操作成功，要保证与用户的充分交流，而作为正式交流，准备工作是很重要的。其一是人员准备。技术方面，一般来讲仓库设计组的主要成员都应该参加，还可以包括一个在决策支持或数据仓库领域有专长的顾问。顾问应为设计组提供有价值的意见，从而帮助设计组更快地收集到设计要求。用户方面，从组织机构的上层开始交流是非常有益的。上层行政官员可以提供许多令人惊奇的有关业务操作及其希望从该组织得到的内容。除此之外，还应该包括负责数据仓库项目或有关的商业领域的行政人员、来自相关商业领域的负责向高级行政官员汇报的主管经理和为高级行政人员和主管经理准备报告的业务分析员。其二是内容准备。对于参与收集需求的技术人员，需要给他们足够且有用的提示和建议，以确保每个人都能积极参与。在提示他们时，要强调他们参与的重要性，以及与用户会谈的目的。会谈的目的有：希望从用户得到的内容和希望用户带来的所有材料，比如，用户发现的有价值的报告样本等。制定与所有参与需求分析的用户的日程也应该是需要准备的一项重要内容。3确定需求提问根据不同的交谈对象，所提问题也应不同。很明显，针对高级行政人员和底层的雇员应该有不同的问题。但是这里面包含一些具有共性的问题域，比如：交谈对象在公司中的地位是什么？他们的工作成绩是怎样得来的，即什么因素决定工作的成功与失败？什么信息对完成指标有影响，什么信息数据对会谈者理解关键指标有帮助？得到信息后，下一步利用这些信息干什么？怎样处理这些信息？这些信息是最终的，还是需要进一步输入和处理？这些信息是否与其他报告或其他信息进行了融合？从这些数据衍生的信息或分析结果将提供给谁？怎样分析过程需耗费多长时间？从这些分析中可做出什么决策？信息分发的方式是什么？报告、论文或电子邮件？怎样弥补信息的空缺？分析这些数据需要哪一级的详细程度？信息报表的来源是什么？谁对报告的制定、维护和分发负责？如果他们在一个标准上可以得到多个商务问题的答案，他们将怎样优先处理这些信息？如果觉得这些问题还不够深入，对于需求分析的问题，可以按照商务目标、当前信息源、涉及的主题范围、关键性能指标和信息频率等5个方面进一步细化需求提问。1）商务目标企业部门的目标是什么？怎样将这些目标融进整个公司的目标之中？要达到这些目标有哪些需要？成功的关键因素是什么？集团公司实现这些目标的障碍有哪些？商业策略是什么？商务活动的领域有哪些？这些领域是怎样联系在一起从而达到商务活动目的的购买外部数据吗？从哪里购买？还有谁有公司没有购买的数据？数据提供商是怎样发布信息的？所有的用户都需要相同的信息吗？特殊情况是什么？明确定义用户的类别。2）当前信息源在现有报表过程中，当前传递了哪些信息？这些信息的详细程度怎样？是太详细了，还是太粗略了？哪些操作地区产生了关于重要主题领域的数据和信息？提供数据和信息的地区有计算机系统支持吗？这些计算机系统中数据的质量、可靠性、一致性和完整性等商务评价指标指的是什么？3）主题领域有关这方面的问题可以帮助确定对商务活动来说什么主题是很重要的。随着用户地位的不同，在他们的数据领域中，各种不同的领域或维度被明确地提出，这就使得对信息打包变得容易多了。这些问题集中在数据仓库中的数据应怎样检索及用户