数据仓库模型建设规范10资料.docx
《数据仓库模型建设规范10资料.docx》由会员分享，可在线阅读，更多相关《数据仓库模型建设规范10资料.docx（24页珍藏版）》请在冰豆网上搜索。
数据仓库模型建设规范10资料
数据仓库模型建设规范
1.概述
数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。
物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。
数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。
为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。
2.数聚模型架构
在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。
2.1.数据架构图
2.2.架构工作方法规范
数据类型
抽取方式
转换方式
加载方式
表类型
变化类型
加载过程
1.有时间戳
2.数据量巨大
3.交易事务表
4.周期数据处理
增量变化抽取
落地TMP区
清洗转换
标识增删改
落地DCI区
增量变化加载
维表
新增
新增代理键。
插入记录
修改
如果须保留历史，新增代理键。
插入记录
如果无须保留历史，根据代理键修改记录。
删除
若为逻辑删除，可等同修改，或在抽取时过滤。
若为物理删除，则增量抽取无法判断被删除。
事实表
新增
根据流水号删除目标表数据，查找代理键，然后再加载增量变化数据.
修改
删除
一般来说，事实表数据不物理删除，
如果物理删除，增量抽取方式无法判断出来。
1.无时间戳
2.数据量小的表
3.代码表
4.主数据表
5.初始数据加载
全量抽取
落地TMP区
清洗转换
落地DCI区
全量加载
维表
只适合系统初始化数据加载，
不区分增删改
事实表
查找对应代理键，全部加载，
适合数据量小的场合，ETL简单快捷。
清洗转换
获取增量
标识增删改
添加时间戳
落地DCI区
增量变化加载
维表
新增
新增代理键。
插入记录
修改
如果须保留历史，新增代理键。
插入记录
如果无须保留历史，根据代理键修改记录
删除
维表不处理被删除的维度记录。
事实表
新增
根据事务流水号，删除目标表。
查找代理键，直接插入目标表。
修改
删除
根据事务流水号，删除目标表.
可以处理物理删除现象。
2.3.准备层L0
2.3.1.主要数据结构
临时表：
从数据源抽取，直接落地到临时表。
临时表总是保存这次抽取的数据，不保留历史数据。
也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话，就是自从上次修改后的数据。
接口表：
从临时表，经过清洗、转换到达接口表。
接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。
接口表里面也是源系统整个表的数据。
转换表：
为了进行清洗和转换建立的中间辅助表。
2.3.2.命名规范
临时表：
L0_TMP_源系统_具体业务或L0_TMP_业务主题_具体业务（对单一源）
举例：
L0_TMP_POS_SALESORDER
接口表：
L0_DCI_业务主题_具体业务表
举例：
L0_DCI_SALES_SALESORDER
转换表：
L0_MAP_具体业务表
举例：
L0_MAP_SALES
2.3.3.开发工作
●开发数据抽取接口，落地TMP区
●开发数据清洗转换程序，落地DCI区，多源系统进行合并
●开发数据装载程序，装载到L1层
2.4.原子层L1
2.4.1.主要数据结构
维度表：
整个数据仓库一致的维度
代码表：
维度属性，非维度代码等。
原子事实表：
根据业务主题，形成原子事实表
汇总事实表：
根据分析主题，业务主题形成合并或汇总的事实表。
2.4.2.命名规范
维度表：
DW_DIM_维度。
举例：
组织维DW_DIM_ORG日期维DW_DIM_DATE.
代码表：
DW_CODE_代码。
举例：
性别DW_CODE_GENDER
原子事实表：
L1_DW_FACT_分析主题_具体分析
汇总事实表：
L1_DM_FACT_分析主题_具体分析
2.4.3.开发工作
●维护聚集。
●衍生计算，二次指标计算。
2.5.应用层L2
2.5.1.主要数据结构
宽表：
根据需求，从L1层抽取成宽表，表现形式为固定报表，仪表盘等等。
立方体：
根据分析主题，从L1生成OLAP立方体。
视图：
根据需要，从L1，L0层产生L2层的视图。
前端应用，不仅仅可以利用L2层的数据结构，还可以利用L1层的数据结构。
对于源系统，还可以利用L0层的DCI区数据，可以做详单和明细查询。
2.5.2.命名规范
宽表：
L2_FACT_【应用主题】_【分析主题】_应用。
举例：
L2_FACT_FIN_ZCFZB（财务->资产负债表）
立方体：
根据分析主题，从L1生成OLAP立方体。
视图：
根据需要，从L1，L0层产生L2层的视图。
如明细单。
举例：
L2_VIEW_原L1层表。
2.5.3.开发工作
数据从L1层经过计算，汇总，根据前端分析需求，形成可以有效支撑前端应用查询的结构。
3.建模方法
要成功地建立一个数据仓库，必须有一个合理的数据模型。
数据仓库建模在业务需求分析之后开始，是数据仓库构造的正式开始。
在创建数据仓库的数据模型时应考虑:
满足不同层次、用户的需求;兼顾查询效率与数据粒度的需求;支持用户需求变化;避免业务运营系统性能影响;提供可扩展性。
数据模型的可扩展性决定了数据仓库对新的需求的适应能力，建模既要考虑眼前的信息需求，也要考虑未来的需求。
目前两类主流的数据仓库模型分别是由Inmon提出的企业级数据仓库模型和由Kimball提出的多维模型。
Inmon提出的企业级数据仓库模型采用第三范式（3NF），先建立企业级数据仓库，再在其上开发具体的应用。
企业级数据仓库固然是我们所追求的目标，但在缺乏足够的技术力量和数据仓库建设经验的情况下，按照这种模型设计的系统建设过程长，周期长，难度大，风险大，容易失败。
这种模型的优点是信息全面、系统灵活。
由于采用了第三范式，数据存储冗余度低、数据组织结构性好、反映的业务主题能力强以及具有较好的业务扩展性等，但同时会存在大量的数据表，表之间的联系比较多，也比较复杂，跨表操作多，查询效率较低，对数据仓库系统的硬件性能要求高等问题。
另一方面，数据模式复杂，不容易理解，对于一般计算机用户来说，增加了理解数据表的困难。
Kimball提出的多维模型降低了范式化，以分析主题为基本框架来组织数据。
以维模型开发分析主题，这样能够快速实施，迅速获得投资回报，在取得实际效果的基础上，再逐渐增加应用主题，循序渐进，积累经验，逐步建成企业级数据仓库。
这也可以说是采用总线型结构先建立数据集市，使所有的数据集市具有统一的维定义和一致的业务事实，这种方法融合了自下而上和自上而下两种设计方法的思想。
这种模型的优点是查询速度快，做报表也快;缺点是由于存在大量的预处理，其建模过程相对来说就比较慢。
当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。
由于事实表的主码由所有维表的主码组成，所以这种维的变动将是非常复杂、非常耗时的。
而且信息不够全面、系统欠灵活、数据冗余多。
本规范我们主要针对维度建模的方法来阐述规范。
3.1.维度建模
多维数据建模以直观的方式组织数据，并支持高性能的数据访问。
每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。
多维模型最常见的是星形模式。
在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。
位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。
每个指标实体代表一系列相关事实，完成一项指定的功能。
位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。
每个维表有自己的属性，维表和事实表通过关键字相关联。
使用星形模式主要有两方面的原因:
提高查询的效率。
采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。
同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。
对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。
3.2.建模步骤
第一步：
选取建模的业务过程
设计过程的第一步是确定要建模的业务过程或者度量事件。
业务过程是在业务需求收集过程明确下来。
在很多的生产活动中，存在着很多价值链，这些价值链就是有一系列的业务过程来组成的。
比如在供应链管理中。
存在着下面的业务过程：
原材料购买
原材料交货
原材料库存
材料账单
生产制造
将产品运到仓库
制成品库存
客户订单
为客户送货
货品计价
付款
退货
第二步：
定义模型的粒度
业务过程被确定下来后，就建模师就必须声明事实表的粒度。
清楚地定义事实表的行到底代表什么在提出业务过程维度模型的过程至关重要。
如果没有在事实表的粒度上达成一致，那么设计过程就不可能成功地向前推进。
第三步：
选定维度
一旦事实表的粒度已经稳固地确定下来，对维的选择就相当简单了。
也正是在此时，就可以开始考虑外键的问题了。
一般来说，粒度本身就能够确定一个基本或者最小的维度集合，设计过程就是在此基础上添加其他维。
这些维在已经声明的事实表粒度都有一个唯一对应的值。
第四步：
确定事实
四步设计过程的最后一步是仔细选择适用于业务过程的事实和指标。
事实可以从度量事件中采用物理手段捕捉，或者也可以从这些度量中导出。
对于事实表粒度来说，每个事实都是必须设计存在的，不要将那些明确声明的粒度不相匹配的其他时间段的事实或者其他细节层次的事实混杂进来。
4.维度表设计
维度表包含内容：
1）代理键：
整型，不可重复，唯一标识每一条记录，不包含任何商业信息。
（必选）
2）代理键有效开始时间和结束时间。
（必选）
3）当前有效标志。
（必选）
4）主键：
传统意义的业务键，包含相应的商业信息，如员工编号。
（必选）
5）名称：
数据分析时显示的内容，如员工名称等；（必选）
6）排序键：
自定义序列。
（可选）
7）自定义汇总：
利用自定义表达式进行特定的数据运算。
可选）
8）父键：
父子维度中用来标识主键的上级。
（可选）
9）一元运算符：
在父子维度中用来定义上下级的汇总关系。
（可选）（详细）
10）属性：
属性包含有关维度的信息。
例如，Customer维度可以包含Name、PhoneNumber、Gender、City、State等属性。
属性通过属性层次结构显示出来。
维度中的属性层次结构同时包含可选的（All）级别和该属性的非重复成员。
例如，Customer维度可以包含具有两个级别的Name属性层次结构：
（All）级别以及为每个姓名包含一个成员的级别。
父子层次结构的处理方式有所不同。
属性不一定要具有属性层次结构。
如果未创建属性层次结构，多维数据集的空间将与属性无关。
例如，通常不会为PhoneNumber属性创建属性层次结构，因为通常不会按电话号码导航维度。
如果没有为属性创建属性层次结构，则该属性可用作成员属性，但不能用作用户层次结构中的级别。
属性可以通过前端展示软件进行展现。
（可选）
11）属性层次结构：
属性层次结构完全定义多维数据集的空间。
多维数据集是由多维数据集的属性层次结构的交集产生的多维空间。
（可选）
4.1.时间维度
时间维度是必不可少的一个维度，可以参考如下的模板：
Name
Code
DataType
Length
日期代理键
DATE_PK
INTEGER
日期描述
DATE_DESC
VARCHAR2（8）
8
日期长描述
DATE_LDESC
VARCHAR2（20）
20
日期中文描述
DATE_CNDESC
VARCHAR2（20）
20
天
DAY
NUMBER
天中文
DAYCN
VARCHAR2（10）
10
月
MONTH
NUMBER
月中文
MONTH_DESC
VARCHAR2（10）
10
年
YEAR
NUMBER
年中文
YEAR_DESC
VARCHAR2（10）
10
年月
YEARM_ONTH
VARCHAR2（6）
6
周月
WEEKMONTH
NUMBER
周月中文描述
WEEK_MONTH_CNDESC
VARCHAR2（20）
20
年中第几周
WEEK_YEAR
NUMBER
年中第几周描述
WEEK_YEAR_CN
VARCHAR2（20）
20
周几
WEEKNO
NUMBER
周几中文描述
WEEK_CN
VARCHAR2（10）
10
旬
XUN
NUMBER
旬中文
XUNCN
VARCHAR2（10）
10
季度
QUARTER
NUMBER
季度中文
QUAR_CN
VARCHAR2（10）
10
是否周末
IF_WEEKEND
VARCHAR2（10）
10
是否月末
IF_MONTHEND
VARCHAR2（10）
10
节假日名称
HOLIDAY
VARCHAR2（10）
10
上月同一天
LASTMONTH_DAY
VARCHAR2（8）
8
去年同一天
LASTYEAR_DAY
VARCHAR2（8）
8
4.2.层级维度
层级维度也是我们模型设计最常遇见的维度，比如组织结构，区域，产品树，行业结构等等。
在设计时，可以采用如下模板：
针对数据存储时，采用自关联的结构：
Name
Code
DataType
Length
组织代码
ORG_CODE
VARCHAR2（20）
20
上级组织代码
PORG_CODE
VARCHAR2（20）
20
组织名称
ORG_NAME
VARCHAR2（100）
100
上级组织名称
PORG_NAME
VARCHAR2（100）
100
组织类型
ORG_TYPE
VARCHAR2（20）
20
组织层级
ORG_LEVEL
VARCHAR2（20）
20
组织描述
ORG_DESC
VARCHAR2（200）
200
组织简称
ORG_SNAME
VARCHAR2（20）
20
组织地址
ORG_ADDR
VARCHAR2（100）
100
针对数据展现时，将自关联的结构展开，以列存储层次：
根据需要可以把组织层级具体化。
Name
Code
DataType
Length
组织代理键
ORG_KEY
INTEGER
组织代码
ORG_CODE
VARCHAR2（30）
30
组织名称
ORG_NAME
VARCHAR2（50）
50
组织描述
ORG_DESC
VARCHAR2（100）
100
组织简称
ORG_SNAME
VARCHAR2（50）
50
组织层级
ORG_LEVEL
VARCHAR2（30）
30
组织类型
ORG_TYPE
VARCHAR2（20）
20
上级组织代码
ORG_PCODE
VARCHAR2（30）
30
上级组织名称
ORG_PNAME
VARCHAR2（50）
50
组织1级代码
ORG_1_CODE
VARCHAR2（50）
50
组织1级名称
ORG_1_NAME
VARCHAR2（50）
50
组织2级代码
ORG_2_CODE
VARCHAR2（50）
50
组织2级名称
ORG_2_NAME
VARCHAR2（50）
50
组织3级代码
ORG_3_CODE
VARCHAR2（50）
50
组织3级名称
ORG_3_NAME
VARCHAR2（50）
50
组织4级代码
ORG_4_CODE
VARCHAR2（50）
50
组织4级名称
ORG_4_NAME
VARCHAR2（50）
50
组织5级代码
ORG_5_CODE
VARCHAR2（50）
50
组织5级名称
ORG_5_NAME
VARCHAR2（50）
50
组织6级代码
ORG_6_CODE
VARCHAR2（50）
50
组织6级名称
ORG_6_NAME
VARCHAR2（50）
50
组织7级代码
ORG_7_CODE
VARCHAR2（50）
50
组织7级名称
ORG_7_NAME
VARCHAR2（50）
50
组织8级代码
ORG_8_CODE
VARCHAR2（50）
50
组织8级名称
ORG_8_NAME
VARCHAR2（50）
50
代理键开始时间
KEY_STARTDATE
VARCHAR2（30）
30
代理键结束时间
KEY_ENDDATE
VARCHAR2（30）
30
有效标志
CURRENT_FLAG
INTEGER
修改时间
KEY_MODIFYDATE
VARCHAR2（30）
30
4.3.缓慢变化维
缓慢变化维定义
数据会发生缓慢变化的维度就叫”缓慢变化维”。
举个例子就清楚了：
在一个零售业数据仓库中，事实表保存着各销售人员的销售记录，某天一个销售人员从北京分公司调到上海分公司了，那么如何来保存这个变化呢？
也就是说销售人员维度要怎么恰当的处理这一变化。
先来回答一个问题，为什么要处理，或保存这一变化？
如果我们要统计北京地区或上海地区的总销售情况的时候，这个销售人员的销售记录应该算在北京还是算在上海？
当然是调离前的算在北京，调离后的算在上海,但是如标记这个销售人员所属区域？
这里就需要处理一下这个维度的数据，即我们缓慢变化维需要做的事情。
处理缓慢变化维一般按不同情况有以下几种解决方案：
4.3.1.新数据覆盖旧数据
此方法必须有前提条件，即你不关心这个数剧的变化。
例如，某个销售人员的英文名改了，如果你不关心员工的英文名有什么变化则可直接覆盖（修改）数据仓库中的数据。
4.3.2.保存多条记录，并添加字段加以区分
这种情况下直接新添一条记录，同时保留原有记录，并用单独的专用的字段保存区别。
如：
（以下表格中Supplier_State表示上面例子中所属区域，为描述清晰，不用代理键表示）
Supplier_key
Supplier_Code
Supplier_Name
Supplier_State
Disable
001
ABC
PhlogisticalSupplyCompany
CA
Y
002
ABC
PhlogisticalSupplyCompany
IL
N
或：
Supplier_key
Supplier_Code
Supplier_Name
Supplier_State
Version
001
ABC
PhlogisticalSupplyCompany
CA
0
002
ABC
PhlogisticalSupplyCompany
IL
1
以上两种是添加数据版本信息或是否可用来标识新旧数据。
下面一种则是添加记录的生效日期和失效日期来标识新旧数据：
Supplier_key
Supplier_Code
Supplier_Name
Supplier_State
Start_Date
End_Date
001
ABC
PhlogisticalSupplyCompany
CA
01-Jan-2000
21-Dec-2004
002
ABC
PhlogisticalSupplyCompany
IL
22-Dec-2004
空的End_Date表示当前版本数据，或者你也可一用一个默认的大时间（如:
12/31/9999）来代替空值,这样数据还能被索引识别到.
4.3.3.不同字段保存不同值
Supplier_key
Supplier_Name
Original_Supplier_State
Effective_Date
Current_Supplier_State
001
PhlogisticalSupplyCompany
CA
22-Dec-2004
IL
这种方法用不同的字段保存变化痕迹.但是这种方法不能象第二种方法一样保存所有变化记录,它只能保存两次变化记录.适用于变化不超过两次的维度。
4.3.4.另外建表保存历史记录
即另外建一个历史表来表存变化的历史记录，而维度只保存当前数据。
Supplier:
Supplier_key
Supplier_Name
Supplier_State
001
PhlogisticalSupplyCompany
IL
Supplier_History:
Supplier_key
Supplier_Name
Supplier_State
Create_Date
001
PhlogisticalSupplyCompany
CA
22-Dec-2004
这种方法仅仅记录一下变化历史痕迹，其实做起统计运算来还是不方便的。
4.3.5.混合模式
这种模式是以上几种模式的混合体，相对而言此种方法更全面，更能应对错综复杂且易变化的用户需求，也是较为常用的。
Row_Key
Supplier_key
Supplier_Code
Supplier_Name
Supplier_State
Start_Date
End_Date
CurrentIndicator
1
001
ABC001
PhlogisticalSupplyCompany
CA
22-Dec-2004
15-Jan-2007
N
2
001
ABC001
PhlogisticalSupplyCompany
IL
15-Jan-2007
1-Jan-2099
Y
此中方法有以下几条优点：
1.能用简单的过滤条件选出维度当前的值。
2.能较容易的关联出历史任意一时刻事实数据的值。
3.如果事实表中有一些时间字段（如：
OrderDate,ShippingDate,ConfirmationDate），那么我们很容易选
升级会员 