数据建模方法及技巧

数据建模师谈建模方法及技巧
笔者从98年进入数据库及数据库房领域工作到现在已经有近八年的时间，对数据建模工作接触的比许多，创新性不敢谈，本文不过将工作中的经验总
结出来，供大家一起商讨和指正。

提起数据建模来，有一点是第一要重申的，数据建模师和DBA有着较大的不一样，对数据建模师来说，对业务的深刻理解是第一位的，不一样的建模方法和技巧是为业务需求来服务
的。

而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。

从目前的数据库及数据库房建模方法来说，主要分为四类。

第一类是大家最为熟习的关系数据库的三范式建模，往常我们将三范式建模方法用于成立各样操作
型数据库系统。

第二类是Inmon倡议的三范式数据库房建模，它和操作型数据库系统的三范式建模在重视点上有些
不一样。

Inmon的数据库房建模方法分为三层，第一层是实体关系层，也即公司
的业务数据模型层，在这一层上和公司的操作型数据库系统建模方法是相同的；第二层是数据项集层，在这一层的建模方法依据数据的产生频次及接见频次等要素与公司的操作型数据
库系统的建模方法产生了不一样；第三层物理层是第二层的详细实现。

第三类是Kimball 倡议的数据库房的维度建模，我们一般也称之为星型构造建模，有
时也加入一些雪花模型在里面。

维度建模是一种面向用户需求的、简单理解的、接奏效率高的建模
方法，也是笔者比较喜爱的一种建模方式。

第四类是更加灵巧的一种建模方式，往常用于后台的数据准备区，建模的方式不名一格，以能知足
需要为目的，建好的表不对用户供给接口，多为暂时表。

下边简单说说第四类建模方法的一些的经验。

数据准备区有一个最大的特色，就是不会直接面对用户，因此对数据准备区中的表进
行操作的人只有ETL工程师。

ETL工程师能够自己来决定表中数据的范围和数据的生命周期。

下边举两个例子：
1）数据范围小的暂时表
当需要整合或冲洗的数据量过大时，我们能够成立相同构造的暂时表，在暂时表中只
保存我们需要办理的部分数据。

这样，无论是更新仍是对表中某些项的计算都会效率提升很
多。

办理好的数据发送入准备加载到数据库房中的表中，最后一次性加载入数据库房。

2）带有冗余字段的暂时表
因为数据准备区中的表只有自己使用，因此成立冗余字段能够起到很好的作用而不用肩负风险。

举例来说，笔者在项目中曾碰到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。

此中，客户净扣
值和债项余额已知，需要计算债项净扣值。

计算的规则是按债项余额的比率分派客户的净扣
值。

这时，我们能够给两个表增添几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。

这样经过三条SQL就能够直接达成整个计算过程。

将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中经过（债项余额×客户净扣值/客户余额）公式即可直接计算处债项净扣值。

此外还有好多大家能够发挥的建表方式，如不需要主键的暂时表等等。

总结来说，正
因为数据准备区是不对用户供给接口的，因此我们必定要利用好这一点，以给我们的数据办理工作带来最大的便利为目的来进行数据准备区的表设计。

行业借鉴经验：
数据库房架构经验谈
关于数据库房的架构方法，不一样的架构师有不一样的原则和方法，笔者在这里来总结一
下目前常采纳的架构方式及其优弊端。

这些架构方式不限于某个行业，能够供各个行业借鉴使用。

第一需要说明的一点是，目前在数据库房领域比较一致的建议是在数据库房中需要保
留公司范围内一致的原子层数据。

而独立的数据市集架构（Independent datamarts）没有公司范围内一致的数据，很可能会致使信息孤岛的产生，除非在很小的公司内或只针对固定
主题，不然不建议成立这样的架构方式。

联邦式的数据库房架构
（FederatedDataWarehouse
Architecture ）无论是在地区上的联邦仍是功能上的联邦都需要先在不一样平台上成立各自的数据库房，再经过参照（reference ）数据来实现整合，而这样很简单造成整合的不完全，除非联邦式的数据库房架构也采纳Kimball 的总线架构（BusArchitecture ）中近似的功能，即在数据准备区保存一致性维度（ConformedTable）其实不停更新它。

因此，这两种架构方式不在议论范围以内。

下边主要议论剩下的三种架构方式。

（1）三范式（3NF）的原子层＋数据市集
（
（这样的数据库房架构最大的倡议者就是数据库房之父Inmon，而他的公司信息工厂
（CorporateInformationSystem）就是典型的代表。

这样的架构也称之为公司数据库房
（EnterpriseDataWarehouse，EDW）。

公司信息工厂的实现方式是，第一进行全公司的数据整合，成立公司信息模型，即EDW。

关于各样剖析需求再成立相应的数据市集或许探究库房，其数据根源于EDW。

三范式的原子层给成立OLAP 带来必定的复杂性，可是关于成立更
复杂的应用，如发掘库房、探究库房供给了更好的支持。

这种架构的建设周期比较长，相应
的成本也比较高。

2）星
型构造（StarS
chema
）的原
子层＋
HOLAP
星型构造最大的倡议者是Kimall，他的总线架构是该类架构的典型代表。

总线架构实
现方式是，第一在数据准备区中成立一致性维度、成立一致性事实的计算方法；
其次在一致
性维度、一致性事实的基础上逐渐成立数据市集。

每次增添数据市集，都会在数据准备区整
合一致性维度，并将整合好的一致性维度同步更新到全部的数据市集。

这样，成立的全部数
据市集合在一起就是一个整合好的数据库房。

正是因为总线架构这个能够逐渐成立的特色，
它的开发周期比其余架构方式的开发周期要短，相应的成本也要低。

在星型构造的原子层上
能够直接成立齐集，也能够成立HOLAP。

笔者比较偏向于Kimball的星型构造的原子层架构，在这
种架构中的经验也比许多。

3）三范式（3NF）的原子层＋ROLAP
这样的数据库房架构也称为集中式架构（
CentralizedArchitecture
范式的原子层上直接成立ROLAP，做的比较优秀的就是MicroStrategy
），思路是在三。

在三范式的原子层
上定义ROLAP比在星型构造的原子层上定义ROLAP要复杂好多。

采纳这种架构需要在定义
ROLAP是多下些功夫，并且ROLAP的元数据不必定是通用的格式，因此对ROLAP 做显现很可
能会遇到工具的限制。

这种架构和第一类很相像，不过少了原子层上的数据市集。

总结来说，这三种数据库房的架构方式都是不错的选择。

关于需要奏效快、成本低的
项目能够考虑采纳第二种总线架构，关于资本充分并有成熟业务数据模型的公司能够考虑采纳第一种架构或第三种架构。

应用难点技巧：
变化数据捕捉经验谈
在数据库房系统中，一个很重要的目的就是保存数据的历史变化信息。

而变化数据捕
获（ChangeDataCapture，CDC）就是为这个目的而产生的一项技术。

变化数据捕捉常用的
方法有：1）文件或许表的全扫描对照， 2）DBMS日记获得，3）在源系统中增添触发器获得，
4）鉴于源系统的时间戳获得， 5）鉴于复制技术的获得， 6）DBMS供给的变化数据捕捉方法
等。

此中，由DBMS供给变化数据捕捉的方法是大势所趋，即详细的捕捉过程由DBMS来达成。

像银行、电信等好多行业的操作记录生成后就不会改变，只有像客户、产品等信息会
随时间发生迟缓的变化，因此往常的变化数据捕捉是针对维度表而言的。

Kimball对迟缓变化维的剖析及应付策略基本上能够办理维度表的各样变化。

而关于一些零售行业，像合同表中的合同金额近似的数值在录入后是有可能会发生改
变的，也就是说事实表的数据也有可能发生变化。

往常关于事实表数据的改正属于勘误的范畴，能够采纳近似迟缓变化维TYPE1的办理方式直接更新事实表。

笔者不太赞成对事实表
的变化采纳快照的方式插入一条新的事实勘误记录，这样会给后续的显现、剖析程序带来太多的麻烦。

接下来要议论的是笔者以前碰到的一个很是棘手的事实表数据改变的问题，该事实表的主键随表中某些数据的变化发生改变。

以此中的一个合同表为例，该合同表的主键是由
“供货单位编号”＋“合同号”生成的智能主键，当此中的“供货单位编号”和“合同号”中任何一个发生变化时，该合同表的主键都会发生变化，给变化数据捕捉带来了很大的麻烦。

项目中，笔者的办理方式是采纳触发器的方法来实现变化数据捕捉。

详细的实现方式
是：
1）成立一个新表作为保存捕捉的数据表使用，此中字段有“原主键”、“改正后主键”、及其余需要的字段，称为“合同捕捉表”。

2）在原合同表Delete 和Update时分别成立触发器，当删除操作发生时，建在Delete
上的触发器会插入一条记录到“合同捕捉表”，此中“改正后主键”字段为空，表示该记录是删除的记录；当发生更新时，将“原主键”、“改正后主键”及其余需要记录的字段都保
存入“合同捕捉表”中，表示该记录被修悔过，假如“原主键”和“改正后主键”不一样，则表示主键被改正，假如相同，则表示主键没有被改正。

3）因为操作系统中的主键往常会成为数据库房中事实表的退化维度，可能仍会起主键
的作用。

因此在数据加载时，需要分状况判断“合同捕捉表”的数据来决定能否更新事实表中的退化维度。

能够说，这样的鉴于触发器的变化数据捕捉方法其实不是一个很好的选择。

第一这需要
对源系统有较大的权限；其次，触发器会给源系统的性能带来很大的影响。

因此除非是没有其余选择，不然不建议采纳这种方法。

而关于这样的状况，我们在成立操作型数据库系统时完整能够防止。

下边是对操作型
数据库系统成立者的几点建议：1）操作型系统的主键不要成立成智能型的，起码不要成立
成会变化的。

2）操作型系统的表中需要加入操作人和操作时间字段，或许直接加入时间戳。

3）操作型系统中操作型数据最好不要直接在原值上改正，能够采纳“冲红”的方式加入新的记录。

这样后续成立数据库房时就不需要考虑事实表数据的变化问题。

最后，期望各大数据库管理系统的厂商能赶快在DBMS层供给功能强盛、简单好用的变化数据捕捉功能，目前Oracle已经有了这个功能。

毕竟技术方面复杂的事情留给厂商做是一个趋向，而我们做应用的则更关注于业务。