商业银行数据仓库浅析

商业银行数据仓库浅析

[1] 逻辑模型属性名以中文命名，物理模型列名以英文命名，中文名与英文名含义应严格一致；

[2] 属性/列命名不要使用不易理解的方言或有地域性/部门局限的业务术语，应使用统一的、正式的、全局范围内通用的官方业务术语；

[3] 属性/列的中文名称尽量保留实体所属主题的名称作为前缀，比如“活期账号”、“定期账号”；

[4] 属性/列名称通常由两部分组成：“主词”和“类词”，“主词”部分标明属性/列标明所描述的对象内容；“类词”部分标明属性/列所描述的内容的类别。如：属性“CUST_TP”中，“CUST”是“主词”部分，表明该属性/列描述的是“客户”；“_TP”是“类词”部分，表明该属性/列是一个描述“（客户的）类别”；

[5] 关于属性/列的命名，如果实体/表所属业务在行内有比较权威的源系统，且该系统的命名已经规范化，则尽量贴近权威源系统的命名；

[7] 英文名全部使用字母大写，如果属性/列英文名由多个单词组成，单词之间用下划线分开；

[8] 属性/列命名不超过30个字符，应尽量使用简练的英文拼写。个别超长的需要提出来，模型组统一综合考虑（主要考虑一些数据库（如TERADATA、ORACLE）定义的表名不能超过30个字符）；

[9] 对于以“编号”作为标识符的属性/列，中文名一般统一命名为“××编号”；英文名后缀应是ID，如“参与人编号 PTY_ID”，“渠道编号CHL _ID”等；

[10] 特殊的，对于一些有习惯叫法的编号类属性/列，如，“银行卡的卡号”，为了遵循使用习惯，以使模型更易理解，可不将之命名为“卡片编号”，而遵照习惯直接命名为“卡号”，其英文名也可以遵照习惯命名为“CR_NO”，而不用命名为“CR_ID”。但这种情况不多，如果遇到需要单独提出来交模型组统一批准；

[11] 日期类型的属性/列，后缀应是DT，如“开户日期OPEN_DT”等；时间类型后缀应是TM，如“事件发生时间EVT_TM”等；遇到时间戳类型称为“时间标签”，用DTTM后缀，建议尽量不要使用，如果需要提交项目组批准； [12] 实体/表和属性/列的命名中英文都应保持同步。

33

商业银行数据仓库浅析

5 历史数据

数据仓库的显著特征除了面向主题、集成、非易失性和随时间变化这几个特征之外，另外一个特征就是存储大量的历史数据。该历史数据记录了数据仓库各个源系统的每一个时间点的状态。便于对数据的追溯。历史数据的存储主要在FDS层实现。

某银行数据仓库项目中遇见的一个小小案例介绍给大家，该案例很好的说明了数据仓库的历史数据情况。情况是这样的，某银行的数据仓库一期工程建设完成上线之后，在数据仓库之上建设了一个绩效管理系统的应用，整个绩效系统的数据全部来自于数据仓库。某日，该银行的一个客户经理打电话过来到数据仓库项目组说，某月某日有一个客户存了一笔300万的定期存款，并且在银行柜台存款的时候已经将改笔存款挂在了这位客户经理的名下，属于该客户经理的揽存业绩。但是在第二天的绩效管理系统中确没有体现出该笔业绩，这样就会直接影响该客户经理的存款日均余额。接到该电话之后，我们根据该笔存款的存款账号直接到数据仓库中存款相关的数据表中查询该笔业务，通过数据仓库中的数据查询可以看出，该客户当天确实存了这笔300万的存款，但是由于该客户的这笔存款账号在晚上23点半以后由于结息又发生了余额变动，而核心系统每天晚上23点做日终及换日的处理，由于发生了日期切换，系统会将23点之后发生的交易计成第二天的日期。而核心系统在给数据仓库传送数据的时候对于存款余额信息是以增量的方式传送，由于该笔存款账户的最后一笔交易计成了第二天，因此作为增量在给数据仓库传送数据的时候就没有将该笔存款算做当天的增量传送。只有在下一日传送的时候才能将该笔存款的最新余额信息传送的数据仓库。这就是导致该笔存款没能在绩效管理系统中算做该客户经理当天的业绩的原因。这个例子说明了数据仓库能够很好的反映数据的历史状态及变化情况。

6 常见问题

在数据仓库的建设和运行过程中，需要注意的问题有很多，在此主要列举一些主

34

商业银行数据仓库浅析

要和常见的问题。

6.1 数据量

存储大量的历史数据是数据仓库的显著特征之一。然而当数据量到达一定程序势必会影响数据的访问效率，因此数据量的规模和增长速度是建设数据仓库必须考虑因素之一。随着时间的推移、数据量在增长这种事实是肯定的，但是数据量的增长速度从某种层面来说是可以控制的。在数据仓库中经常考虑的因素就是通过拉链表、快照表和流水表这三种数据存储方式来控制数据量的增长速度。拉链表是最能控制数据量增长的一种方式，即除了新增的数据之外，对于原有的数据如果不发生变化就不会产生针对该条数据的新链。

但是在某家银行数据仓库项目的实际过程中，我们发现对于总账科目表，无论采取上面哪种数据存储方式存储，数据量的增长速度都非常快，以至于我们按照快照表的方式存储数据在三个月的数据量已经达到1.5亿条数据。因为该总账科目表中的数据是由核心系统供数，并且供数的方式是全量，里面包含日、旬、月、季、半年、年几个频度的数据，核心系统的数据每天还在增长，在这种情况下通过快照表存储的方式就出现了大量的冗余数据。最后经过项目组内部分析决定，总账科目表的数据存储方式采取每天全量加载、只留当天数据的方式。这种方式存储，既保留了全量表中的各个频度的历史数据，满足各个下游系统数据的需求，又大大的减小了数据量，节省了存储空间，提供了数据的访问效率。如果在将来的莫一天总账表数据出现问题，需要追数，想看历史的某一天的总账科目表的数据，可以通过加载ODS层的接口文件的方式进行追数。

这个案例说明了，在数据仓库建设过程中很多对于数据存储和访问的技术和策略不是一成不变的，需要根据数据的实际情况灵活进行处理。

6.2 拉链表

拉链表最常见的问题是数据没有正常关链而重新开了一条链。这种情况通常发生于对于拉链表的逻辑主键的定义不够准确。当数据变化时，恰恰发生在我们所定义的逻辑主键上面，那么程序会认为是新增了一条数据，因此就不会对原有的数据进行关链，不会更新原有数据的EDATE字段。而是产生一条新链。

35

商业银行数据仓库浅析

因此，在建设数据仓库时，如果确认某张表以拉链表的方式进行存储时，一定要在业务层面对该张表的数据有深刻的理解，确认哪些字段会发生变化，哪些字段永远不会发生变化，需要将永远不会发生变化的字段作为逻辑主键才不会导致上面的错误。

6.3 索引

索引是对数据库表中的一列或多列的值进行排序的一种结构，使用索引可以快速访问数据库表中的特定信息。数据库索引好比是一本书前面的目录，能加快数据库的查询速度。

但是创建索引也是有代价的：一是增加了数据库的存储空间，数据库中的表除了数据占空间外，每一个索引还要占一定的物理空间；二是在插入和修改数据时要花费较多的时间（因为索引也要随之变动）；三是创建索引和维护索引要耗费时间，这种时间会随着数据量的增加而增加。

数据仓库最大的特点是保存大量的历史数据，那么当数据量达到一定规模后，数据仓库的存取访问效率就是需要关注的重要问题之一。因此，对数据仓库中的物理表建立索引就显得尤为重要。那么索引的建立通常要考虑以下的几个问题： 第一，索引要创建在需要经常搜索的列上，可以加快搜索的速度。例如数据仓库中

的流水表或快照表，可以在FDATE列上设置独立索引。

第二，索引要创建在经常进行表与表间的连接的列上，这些列主要是一些外键，可

以加快连接的速度。

第三，索引要创建在经常需要根据范围进行搜索的列上，因为索引已经排序，其指

定的范围是连续的。

第四，索引要创建在经常需要排序的列上，因此索引已经排序，这样查询可以利用

索引的排序，加快排序查询速度。

第五，索引要创建在经常使用WHERE子句中的列上面，这样可以加快条件的判断速

度。

36