DW Concept 数据建模分册

整体技术部DWConceptPAGE内部资料注意保密第12页DWConcept数据建模分册作者任少斌时间审核时间批准时间北京用友华表软件技术有限公司修订记录版本号发布日期编制人审核人/批准人修改章节号V1.0前言目的一个优秀的数据仓库架构，离不开一个良好数据体系的支撑，数据体系建设是一个长期的、迭代优化的过程，所有数据模型设计人员在此过程中必须统一设计思想，采用统一的规范，这样才能保证数据体系的可维护性、可扩展性、可延续性，同时统一的规范也是保证数据体系可读性的前提。范围本文档适用于一般数据仓库过程的数据体系说明以及DLL、DTL、DAL层数据模型设计。缩略语解释CDM：概念数据模型LDM：逻辑数据模型PDM：物理数据模型仓库过程概述数据仓库是一个过程，而不是一个项目，在这个过程中我们需要逐步积累和规范一些不能一蹴而就或者靠纯技术手段就能解决的东西，包括源系统业务知识库、统一仓库元数据建设、数据仓库建模方法论和规范以及专业数据仓库建模人员的培养等。下图着重从数据侧描述数据仓库的一般过程。逻辑模型设计思想概述逻辑数据模型LDM是一种图形化的展现方式，使用统一的逻辑语言描述业务，有效组织来源多样的各种业务数据，是数据管理和交流的有效手段；为各种分析应用提供单一的、整合的数据基础，是实现商业智能（BusinessIntelligence）的重要基础。模型层次模型层次英文全称中文名层次定义DVLDataValuableLayer数据价值层该层级的主要功能是通过高级复杂的数据分析方法、为一些具体的商业需求提供特定领域的数据服务、对商业产生直接价值；在该层级实现报表（固定指标、固定格式的数据报告、报表）、HOLAP、DM以及其它数据产品等需求。主要在OracleRAC上实现。DALDataAccessLayer数据访问层面向分析主题的、面向应用的、统一的数据访问层，所有的基础数据、业务规则和业务实体的基础指标库以及多维模型都在这里统一计算口径、统一建模，大量统一视图以及多维模型在该层实现。该层级以业务为驱动、以需求为驱动进行模型设计，实现跨主题域数据的关联计算或者轻度汇总计算，因此会有大数据量的多表关联汇总计算；主要在Greenplum上实现，大部分数据需要同步至OracleRAC。PUBPublicDataLayer公共数据层该层主要存储简单、静态、代码类的维表，包括从OLTP层抽取转换维表、在仓库中依据业务构建维表以及仓库技术常用维表如日期维表等。DTLDataTransformationLayer数据转换层该层的主要功能是基于主题域的划分，面向关键主题、以数据为驱动设计模型，并且基于范式3NF建模，完成数据整合，提供统一的基础数据来源。在该层级完成数据的清洗、重定义、整合分类功能。主要在Greenplum上实现。DLLDataLoadingLayer数据装载层该层级主要功能是存储从源系统直接获得的数据（数据从数据结构、数据之间的逻辑关系上都与源系统基本保持一致）。实现某些业务系统字段的数据仓库技术处理、少量的基础的数据清洗（比如脏数据过滤、维值处理）、生成增量数据表。主要在Greenplum上实现。DSLDataStagingLayer数据准备层该层级主要完成BICDA2源系统数据的增量或全量获取（主要是以落地文件为媒介）、分发和轻度的清洗。在该层实现数据库日志分析产品（获取增量）、非结构化数据处理、数据高速通道（异构环境数据装载卸载、字符集转换、源数据文件主动推送）、同一数据的多次或多系统分发等。主要在Hadoop上实现。OLTPOn-LineTransactionProcessing

源系统

复杂、异构的源系统DataAccessLayer数据访问层是数据仓库模型对外开放、提供统一数据服务的数据层，主要包括三个类别的多维模型和统一视图。多维模型：指以事实表为中心关联维表形成的雪花或者星型模型，该事实表应该是关联了其它相关事实表形成的冗余结构的稀疏表，有级联关系的维表应该通过设计消除多级关系，尽量避免雪花模型的出现。统一视图：指以某个业务主键为中心，统一全面集成了该业务对象的一系列基础指标。每个业务的统一视图会有多个，每一个统一视图集中展现该业务的某类业务范畴的一系列相关基础指标。统一视图中的指标包含该对象自身行为统计数、该对象自身状态统计数、该对象相关业务行为统计数、该对象相关业务状态统计数，以及类似是否×××、最后一次×××和最早一次×××等指标。业务对象业务对象是指在业务域中的静态实体、业务活动的参与者，可以是当事人、机构等现实存在的，也可以是业务过程中抽象出来的，如账户、协议等。针对某一业务对象，DAL层应该提供多维模型和统一视图两类数据接口表。业务活动业务活动是指业务对象之间在一定业务规则下发生的业务行为。针对某一业务活动，DAL层应该提供多维模型数据接口表。对象关系对象关系是指在发生某一业务活动过程中多个业务对象之间形成的关系。针对对象关系，DAL层应该提供多维模型和统一视图相混合数据接口表。逻辑模型命名规范概述命名规范包括模型层次、主题域、主题核心实体、实体/表、属性/字段、数据类型等几个部分。关键主题域主题中文名英文全称英文简称物理表前缀当事人PARTYPTYPTY产品PRODUCTPRDPRD协议AGREEMENTAGRAGR内部机构INTERNALORGANIZATIONORGORG资产ASSETASTAST营销活动CAMPAIGNCMPCMP事件EVENTENTENT浏览EXPLOREEXPEXP知识KNOWLEDGEKNGKNG社区COMMUNITYCMUCMU主题域核心实体主题中文名核心实体中文名英文名DLL层实体/表名DLL层存储与源系统结构相同的数据，某些少量数据可能发生物理存储结构上变化。DLL层采用dll.<源系统标识>_<源系统表名称>方式命名。英文名全部字母小写，单词之间用下划线分开。源系统标识参见附录。如果表名长度过长（如超过30个字符），应适当作缩写处理，所有从源系统进行过特殊处理（表名、字段名变化等）的不符合规范的表，需要在列表中特殊说明并及时更新。源系统名称源系统表名DLL层表名称DTL层实体/表名实体的命名时应遵循下述规则，并且英文名全部字母小写，单词之间用下划线分开：dtl.<主题名称>_<业务线缩写>_<实体英文名称>；总名称长度不能超过25个英文字符。<主题名称>：参考主题域划分部分。<业务线缩写>：参考附录中的业务线缩写。<实体英文名称>：实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实体所代表的业务含义。历史实体中文名用“<实体中文名>历史”命名，如“会员历史”；英文名采用在实体名称后加“_h”的方式。PUB层实体/表名PUB层主要包括三类简单、静态、代码类维表数据：从OLTP抽取转化的维表根据业务或分析需求构建的维表仓库技术常用维表日期维表示例（数据可以通过存储过程注入）CREATETABLEcalendar(--dayssinceJanuary1,4712BCid_dayINTEGERNOTNULLPRIMARYKEY,--序列主键sql_dateDATENOTNULLUNIQUE,--真正日期dayINTEGERNOTNULL,--日monthINTEGERNOTNULL,--月yearINTEGERNOTNULL,--年day_of_weekINTEGERNOTNULL,--本周第几天day_of_monthINTEGERNOTNULL,--本月第几天day_of_yearINTEGERNOTNULL,--本年第几天week_of_yearINTEGERNOTNULL,--本年第几周quarter_of_yearINTEGERNOTNULL,--本年第几季度work_dayINTEGERNOTNULLDEFAULT'1'--是否工作日...);DAL层实体/表名DAL层主要包括五类数据：敏捷数据区（AgileDataArea）：从DLL层直接视图映射到DAL层的数据，可以控制某些敏感字段。DTL层视图映射到DAL层的数据（DTLViewData），在DAL层数据不能覆盖所有数据时，DTL层的表可以视图映射到DAL层。多维模型数据（MultidimensionalData）：采用维度建模方式建立的数据模型数据。统一视图数据(UniformViewData)：基于某个分析实体或对象的一系列指标集合。常用通用的JOIN数据（CommonJoinData）：从DTL层上来的一些实体对象，可能需要经常JOIN在一起使用，在此可以预先处理一些常用通用的JOIN逻辑。DAL层的表命名使用英文小写字母，单词之间用下划线分开，并且可能需要同步到ORACLE上，所以长度不要超过30个字符。并且应遵循下述规则：敏捷数据区，视图映射数据采用dal.<源DLL表名>。DTL层视图映射到DAL层的数据，采用dal.<DTL数据表名>多维模型事实表是以某一种行为事件为分析中心，比如浏览、下单、登陆等等，因此采用：dal.<业务线缩写>_<行为缩写>_<行为修饰>_ABCD的命名形式：<业务线缩写>：参考附录中的业务线缩写。<行为缩写>：参考附录中的用户网站行为缩写。<行为修饰>：比如说明行为作用的对象等。其中ABCD第一位“A”：A代表数据的属性使用，如果它是最明细、最细粒度的数据，使用‘f’(fine)表示；如果是按某个维度进行了汇总的数据，使用‘s’(sum)表示。其中ABCD第二位“B”时间粒度：使用“d”代表天数据，“w”代表周数据，“m”代表月数据，“q”代表季度数据，“h”代表半年数据，“y”代表年数据，“t”代表从某天到当天的累计汇总。其中ABCD的第三位”C”表示对象属性，用”t”表示表，用”v”表示视图。其中ABCD第四位“D”是一个序号：从0开始，依次递增。主要用于在程序或者数据做不同版本的备份处理时使用，也可以用在业务含义非常相近的一批表的命名。多维数据模型的维表：使用公共（pub）schema下表。统一视图是以一个分析主体为中心，基于分析主体的一系列指标组成。因此统一视图数据采用：dal.<业务线缩写>_<分析主体缩写>_<指标主要来源修饰>_ABCD的命名形式：<业务线缩写>：参考附录中的业务线缩写。<分析主体缩写>：如会员mem、商品offer等。<指标主要来源修饰>：如搜索指标se等。其中ABCD第一位“A”：A代表数据的属性使用，使用”u”(universal)表示。其中ABCD第二位“B”时间粒度：使用“d”代表天数据，“w”代表周数据，“m”代表月数据，“q”代表季度数据，“h”代表半年数据，“y”代表年数据，“t”代表从某天到当天的累计汇总。其中ABCD的第三位表示对象属性，用”t”表示表，用”v”表示视图。其中ABCD第四位“D”是一个序号：从0开始，依次递增。主要用于在程序或者数据做不同版本的备份处理时使用，也可以用在业务含义非常相近的一批表的命名。常用公用的JOIN数据采用，dal.<业务线缩写>_<主实体名称>_<主实体JOIN修饰>_j，以“j”(join)字母结尾。DVL层实体/表名实体的命名时应遵循下述规则，并且英文名全部字母小写，单词之间用下划线分开：dvl.<业务线缩写>_<数据集市名>_<数据内容描述>_ABCD的命名形式；总名称长度不能超过30个英文字符。其中ABCD第一位“A”：A代表数据的属性使用，如果它是最明细、最细粒度的数据，使用‘f’(fine)表示；如果是按某个维度进行了汇总的数据，使用‘s’(sum)表示。其中ABCD第二位“B”时间粒度：使用“d”代表天数据，“w”代表周数据，“m”代表月数据，“q”代表季度数据，“h”代表半年数据，“y”代表年数据，“t”代表从某天到当天的累计汇总。其中ABCD的第三位”C”表示对象属性，用”t”表示表，用”v”表示视图。其中ABCD第四位“D”是一个序号：从0开始，依次递增。主要用于在程序或者数据做不同版本的备份处理时使用，也可以用在业务含义非常相近的一批表的命名。属性/字段名原则上，除了一些约定的缩写以外，每个属性/列的名字均可自行确定，英文名应尽量是字段的全称，单词全部小写，单词间用下划线。一些特殊的约定如下：对于编号做为标识符的属性/列，一般统一命名为“××编号”的属性/列，后缀应是id，如“会员编号mem_id”等。没有单独的代码表，取值只有”是/非”的属性/列，中文名必须以”标志”结尾，英文名后缀应是ind，并且标志位的取值必须满足“是（1）/非（0）”；如登录是否成功标志“sign_ind”，取值为“1”表示“成功”，取值为“0”表示“没有成功”。日期类型的属性/列，后缀应是date，如“插入日期dw_ins_date”等。时间拉链用“开始日期dw_begin_date”和“结束日期dw_end_date”。数据类型字段类型英文简称数据类型特殊情况xx编号xx_idnumberXx描述xx_descvarchar()Xx日期xx_datedateXx标志xx_indvarchar(1)Xx类型xx_typevarchar()逻辑模型设计规范概述管理、维护一个数据仓库的逻辑数据模型，需要建立和维护一套有效的工作流程和规范，对模型进行权限管理、版本控制、命名规范等，保证不同的逻辑数据模型设计人员能够按照统一口径进行操作。此文档主要从“建立技术规范”的角度出发，解释了在整个模型设计过程中可能应用的各种规范，以保障：模型版本的可控性模型维护的便利性模型扩展的持续性业务规则逻辑数据模型的设计思想就是通过图形方式体现业务规则和逻辑，因此在整个设计过程中都需要保证业务规则的正确性和完整性。关联关系两个实体/表之间存在关联关系时，在逻辑数据模型就体现为“主外键”的方式。定义上述关系时，需要注意所引用的属性字段一定要保留“FK”，而且需要定义cardinality（即关系的“势”）。历史表对于某些有变动发生，并且数据仓库需要保留历史的信息，在逻辑数据模型中的体现就是“历史表”。该表的主键一般情况下是“变动字段”＋“开始日期”。如“产品历史”，通过“开始日期”和“结束日期”的方式记录产品变动历史，但是在设计时需要明确进行初始加载和日常加载时两个时间字段的填写规则以及缺省的“最大日期”填写规则。另一类“历史表”表现为某时点的信息，使用”数据日期”以保留历史不同时点的信息。外观美学符号体系采取PowerDesigner中提供的工程方法。实体布局尽管模型中会根据不同的目的将实体进行分类创建子主题，但是每个子主题中实体的摆放和布局是否合理和美观，直接影响到读者对模型的认识和理解，因此也需要引起足够的重视，具体原则有：每个子主题中核心的实体放在最中心的位置。实体之间的关联线不能够交叉。如果是父子结构，最好采用“上－下”方式摆放。如果是两者之间的关系，最好采用“左－中－右”方式摆放。如果有历史表，最好将其放在本表的右方。在非代码的子主题中，非重要、非特殊的代码表尽量不保留。属性排列每个实体中的属性/字段排列也应该遵从相应的规则进行摆放：同类属性尽量靠拢摆放。重要的和常用的属性靠前。数据映射实体映射需要将实体的中文名称复制一份存放在表一级的“comment”中，请把和源业务系统表的映射关系填写在notes中。如果对应多个系统的多张表，请分段描述，中间用“”分隔。属性映射请把和源业务系统字段的映射关系填写在notes中。如果对应多个系统的多张表，请分段描述，中间用“”分隔。如果属性是代码字段，则需要在notes里枚举主要代码值，和对应中文含义。标志字段，需注明标志对应业务含义。模型说明如果说“数据映射”部分更多的是从”模型设计”角度考虑，强调的是模型的出处，那从“模型使用”角度来看，需要设计人员就实体、属性进行解释，帮助模型用户理解，从而便于今后使用。实体/表说明在Entities实体一级属性中的name和comment填入对实体/表的中文名，note填写说明和解释，帮助读者理解。设计模型时还需要注意以下几点：所有实体comment里面除了表中文名外还必须加上clusteredkey(@clusteredby)、分区字段(@partitionby)、分区范围(@partitionrange)、实体生命周期(@data_lifecycle)描述.具体格式@clusteredby：指定clustered字段@partitionby：分区字段@partitionrange：根据分区字段确定范围。如：分区字段为时间类型，范围可指定为d(日)、w(周)、m(月)、q(季)、y(年)等@data_lifecycle：实体数据保留周)实例如下：@distributedby：commodity_id@partitionby：fadd_time@partitionrange：d@data_lifecycle：36m逻辑模型每一个实体都要加上dw_ins_date属性，对于历史拉链表要加上dw_status属性.属性/字段说明在DataItem属性一级中的“note”填入对属性/字段的说明和解释，帮助读者理解。模型健康性模型设计过程中需要对健康性不断地进行回顾，主要包括：命名规范：是否遵守命名规范？有没有保持高度的一致性？实体和属性的命名是否有超长的情况出现？是否使用了数据库的关键字？重复实体：是否存在重复实体（内容一样，但是名称稍有差异）？含义不明：是否有的实体/属性的命名晦涩难懂，容易造成歧义？特殊标注：设计过程中标注中间特殊颜色、字体等是否去掉？完整性：模型完整性?引用命名：通过主外键方式进行引用的时候，有没有注意到重命名的问题，有没有保证中英文的同步。模型管理依靠SVN服务器+PowerDesigner的Repository进行版本的控制，需要有专人对模型进行不定期地的检查和回顾。PowerDesigner使用模型分类Powerdesigner可以建立的模型比较丰富，包括业务类、需求管理类、信息类、应用类等各种模型工具包，数据仓库建模属于信息类模型，常用的有CDM概念模型、LDM逻辑模型以及PDM物理模型，如下图所示：对象概念模型逻辑模型物理模型实体实体实体表属性属性属性字段关系关系(一对一，一对多，多对一)关系(无属性关系)外键关系关系(一对多，多对一)实体(有属性的关系)表(关系表)例如订单和产品的关系是一对多，这种关系确定为订单产品明细表。关系关系(多对多)实体（有属性的关系）表(关系表)模型转化Powerdesigner提供了模型间的转换：LDM转换为PDM：对于LDM在选定RDBMS的类型后，可以转换成可落地的PDM物理模型，对于PDM可以使用产生数据库功能，从PD中直接导出建库脚本。反向工程：可以将现有的物理DB库导入至PD，生成相应的PDM物理模型LDM设计数据项(DataItem)一个数据项目是一个实体基本的信息，不可拆分，一次定义，不同实体的属性可以引用它，这样可以做到数据仓库的实体属性命名统一，业务描述统一。域(Domain)Domain可以视为属性的数据类型，构建一个Domain组织可以方便DataItem的设计和重用，增加模型设计和维护的效率和方便性。在模型设计过程中，我们的方法是把所有模型涉及到的属性先按照类型分类进行Domain设计，然后再按照业务含义进行分类组织，为每一类数据类型建立一个Domain，让属性应用到域中，这样在修改列数据类型的时候，仅仅修改Domain中的内容即可。就不会导致相同的用途，但是属性数据类型和长度不一致。创建域选择Model->Domains以打开域列表（ListofDomains）窗口。单击工具栏中AddaRow工具，新建域。输入相应的Name和Code，这里我们输入日期和date。单击Apply提交Domain的创建，单击工具栏中Properties工具以打开DomainProperties窗口，如下图：选择数据类型（Datatype），设置Length等属性，同时可以选择StandardChecks属性页以编辑详细约束。对于日期，设置默认值为“sysdate”单击OK，确认修改。这样就已经完成域日期的创建过程。修改域属性选择Model->Domains以打开域列表（ListofDomains）。单击你想要修改的域对象，使目标域对象处于选择状态。双击该域对象或单击工具栏中Properties工具以打开域属性（DomainProperties）窗口，便可以对域属性进行更改了。查看域查看域上所应用的数据项目。选择域属性后查看Dependencies如下图所示：业务规则(BusinessRule)业务规则是一些业务上需要遵从的一些规则。它可以是公式，可以是定义也可以是详细说明。对于一些通用的业务逻辑可以封装成BusinessRule，这样便于业务逻辑的理解和使用，也便于业务逻辑的维护。同时也可以考虑将BusinessRule和Domains结合起来使用。将业务BusinessRule应用到Domains上，然后再把Domains应用到数据表的字段上。包、实体、关系、关联、继承、快捷方式执行VB脚本Powerdesigner提供了VB脚本的解释器和相应的对象模型，可以在VB环境中将CDM、LDM等文件当作对象来操作，访问其所有方法和属性值。一般来说使用VB脚本有两种情况：一种是对模型文件的批量操作，一种是生成特殊化的DDL脚本。Report制作Powerdesigner提供了模型报告工具，可以产生HTML格式的模型报告，清晰的展现模型视图以及数据字典等。RepositroyRepository是PowerDesigner的版本控制工具。它提供了一个整合的设计建模和版本控制环境，Repository还提供对象查找功能，使用户可以跟踪模型变化，了解变更原因。也可以在此基础上生成相应的项目报告（Report），包括模型信息，历史变更信息及模型关联信息等。主要有以下功能。模型管理：在同一位置存储和版本化PowerDesigner模型及其他类型文档。用户可以在客户端可以访问服务器端数据库，合并/提交（Consolidation）和提取（Extract）文件，以保持数据的完整性和一致性。安全：基于角色的安全机制，全面的权限管理。模型管理人员可以控制用户对模型的访问和可视化区域。同时提供记录访问日志的功能。跨模型的冲突分析：Repository能为跨模型的冲突分析提供并维护完整的存储和完整的模型间的依赖关系。模型建立步骤数据仓库逻辑模型根据模型层次。拆分出DTL层模型、DLL层模型、DAL层模型三个Package。三个Package处于同一个LDM，便于属性、域、业务规则的统一使用。以DTL层模型为例在模型中建立实体遵循这样的步骤：根据实体的业务含义确定实体所在主题域，对应到Diagram在该主题域中设计实体并根据命名规则和实体的业务含义定义实体。Name对应实体中文名，Code对应实体英文名。设计实体的属性，如果在DataItem有则从DataItem中取，否则设计DataItem然后从DataItem中取。设定新设计的DataItem的属性。设计DataItem的原则：如果DataItem会被其它模型层次实体引用，那么建在CDM下面。如果只是本层次使用那么建立在相关的Diagram下面。如果属性是外键要引用别的实体，则在主题域中加入该实体，并建立关系，如果外键是主键的一部分那么在被引用实体和本实体之间建立IdentifyingRelationship。否则建立Non-IdentifyingRelationship。指定实体的P