一、适用于银行ＣＲＭ的星型模型
 
１．流行的数据仓库模型
 ＣＲＭ是客户关系管理的简称，常需要使用数据仓库技术来实现。目前比较流行的数据仓库模型主要有两种：Ｉｎｍｏｎ提出的企业级数据仓库模型和Ｋｉｍｂａｌｌ提出的维模型。
 Ｉｎｍｏｎ提出的企业级数据仓库模型采用三范式（３ＮＦ），以企业主题为基本框架来组织数据。企业主题实际上就是企业中的各个要素。有人将银行企业归纳为十大主题：当事人、内部组织、产品、事件、渠道、协议、行销活动、资产、财务、区域。其中当事人就是银行客户的延伸，内部组织就是银行机构的延伸，事件就是银行交易的延伸。这种模型的优点是信息全面、系统灵活、数据冗余少，能适应多种应用的需要。但是，按照这种模型设计的系统建设过程很长，难度大，容易失败。
 Ｋｉｍｂａｌｌ提出的维模型降低了范式化，以分析主题为基本框架来组织数据。分析主题实际上就是具体的分析应用，如贷款欠息分析、收息分析等。这种模型的优点是能够快速实施，迅速获得投资回报；缺点是信息不够全面、系统欠灵活、数据冗余多。
 采用不同的模型，就会有不同的数据仓库建设途径。若从企业级数据仓库模型着手，走的就是一条自顶向下的建设途径：先建企业级数据仓库，再在其上开发具体的应用。企业级数据仓库固然是我们所追求的目标，但在缺乏足够的技术力量和数据仓库建设经验的情况下，走这条路风险过大，周期太长。一般来说，可以将企业级数据仓库作为一个长远的目标，先从具体的应用着手，以维模型开发ＣＲＭ的分析主题，在取得实际效果的基础上，再逐渐增加应用主题，循序渐进，积累经验，培养人才，锻炼队伍，逐步建成企业级数据仓库。这也可以说是一种自底向上的数据仓库建设途径。
 
２．建立在简化的数据仓库层基础上的ＣＲＭ星型模型
 星型模型是一种维模型，它以事实表和维表为基本框架组织数据。ＣＲＭ的源数据文本经过抽取后进入ＯＤＳ（Ｏｐｅｒａｔｉｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ，操作数据存储）层，ＯＤＳ层可以看作是一个简化的ＤＷ（Ｄａｔａ Ｗａｒｅ，数据仓库）层，在这之上是以事实表和维表为基本框架构建的星型模型，从星型模型产生出以ＭＤＤＢ（Ｍｕｌｔｉ－Ｄｉｍｅｎｓｉｏｎａｌ Ｄａｔａ Ｂａｓｅ，多维数据库）和宽表为主的数据集市，供前端分析展现（如图１所示），这样的结构简明、面向分析主题、便于联机分析。

３．星型模型的组成
 一个星型模型对应一个分析主题，它由一个事实表和一个多个维表组成。其中事实表是星型模型的核心，由分析变量和分析维度代理键组成，分析变量存放分析事实数据，分析维度代理键用于连接维表。维表是星型模型的外围，存放分析维度数据，由维的代理键、维的层次属性、维的描述信息组成。
 
４．代理键
 ＣＲＭ数据仓库中的数据是对银行业务系统数据的重新整合，一般需要重新编码。ＣＲＭ星型模型中的代理键（ＳＫ，Ｓｕｒｒｏｇａｔｅ Ｋｅｙ）用于对业务系统数据重新编码，也就是用数据仓库内部的、长度较短的代理键值取代业务系统长度较长的业务键值。
 代理键能够起到统一代码设计、节省存储空间、加快检索速度的作用。维表的数据可能来自多个源系统（如客户维、机构维的数据都来自存、贷款两个系统），各个源系统的代码可能不同，代理键可起到统一代码的作用。使用６字节长度的数值型变量作为代理键，可获得１３７４亿多个键值，足够任何一个维表的使用。例如，ＣＲＭ中使用ｌｅｎｇｔｈ＝６的ＳＡＳ数值型变量作为借据代理键，比原系统中使用３０位字符串类型变量作为借据号，可节省８０％的存储空间。在检索时，代理键由于长度较短，匹配的速度就会较快。
 ＣＲＭ中采用控制表法产生代理键，如图２所示。在系统中维护一张代理键控制表，存放每个维表的表名（ＤＩＭ＿ＴＡＢＬＥ）和该维表的下一个可用代理键（ＮＥＸＴ＿ＳＫ）。代理键产生过程由该维表的加载进程控制，当一个维表有Ｍ个新的键值需要产生时，查找代理键控制表，得到该维表的下一个可用ＳＫ（设为Ｎ），用Ｎ，Ｎ＋１，…，Ｎ＋Ｍ－１作为新记录的ＳＫ，追加到维表中，最后用Ｎ＋Ｍ更新代理键控制表中该维表的下一个可用ＳＫ。

二、ＣＲＭ模型设计方法
 
１．ＣＲＭ模型表的分类
 ＣＲＭ模型表分类如表１所示。
 
２．ＣＲＭ模型设计方法
 ＣＲＭ模型设计的依据是《业务需求》、《数据源分析报告》、《需求分析报告》、《功能设计》，ＣＲＭ模型设计的步骤是从逻辑模型到物理模型。
 （１）ＣＲＭ逻辑模型设计过程
 ①根据业务分析主题，确定模型主题（如根据贷款收息分析主题，确定贷款收息模型；根据贷款欠息分析主题，确定贷款欠息模型等）。
 ②列出每个模型主题的分析量和分类量。
 ③设计事实表。事实表可以由分析量＋分析维度代理键得到。
 ④设计维表。维表可以由维ＳＫ＋层次ＤＫ＋其他属性信息得到，其中维ＳＫ、层次ＤＫ和其他属性信息可以从各个业务分析主题中总结得到。
 ⑤设计对照表。根据源系统中数据项的取值与数据仓库中数据项的取值的对照关系得到，采用ＳＡＳ的ＦＯＲＭＡＴ技术可以方便地使用对照表。
 ⑥决定模型中每个字段的来源和算法。根据《数据源分析报告》，决定模型中每个字段来自哪个表哪个字段、在何种条件下得到、通过何种计算得到。
 ⑦决定表的分割。表的分割是时间和空间的权衡折衷，ＣＲＭ采用下列分割方法：按汇总粒度的分割，逐笔表、日表、月表、年表等；按当前和历史分割，当前表、历史表；按访问频度分割，高访问频度表、低访问频度表；按变化频度分割，高变化频度表、低变化频度表。
 （２）ＣＲＭ物理模型设计过程
 ①表定义：表名、设计者、数据量估计。
 ②字段定义：名称、类型、长度、主键、索引。
 ③表与表之间的关系定义。

三、ＣＲＭ模型设计考虑
 ＣＲＭ模型设计应有时间效率考虑和空间效率考虑两个方面。
 
１．时间效率考虑
 ＣＲＭ模型中对时间效率考虑主要体现在中间表的设计和按访问频度的不同分割表两方面。
 （１）中间表的设计
 ＣＲＭ中间表的设计有利于并行处理、降低模块间的耦合性。如图３所示，中间表与事实表一一对应，用业务键而不是数据仓库的代理键保存了对应事实表的新增事实数据；使用ＳＡＳ的ＤＡＴＡ步扫描数据源表一次，就能得到多张中间表；将每个中间表的业务键连接维表得到代理键，就能实现中间表到事实表的转换。这样，不仅不同数据源表抽取到中间表的过程可以并行处理，而且各个中间表到事实表的转换也可以并行处理。此外，每个模块间的耦合性降低了许多，模块的灵活性和可维护性得到大大的提高。
 （２）按访问频度的不同分割表
 ＣＲＭ中维表或事实表的各项数据的访问频度常常是不同的。如果该维表或事实表的数据量较大，那么访问速度就会受到影响。如果将访问频度高的数据分离出来，放在不同的表中，就可以加快该部分数据的访问速度。                             
 
２．空间效率考虑
 ＣＲＭ模型对空间效率的考虑主要体现在应用级数据压缩设计和按变动频度的不同分割表两方面。
 （１）应用级数据压缩设计
 ＣＲＭ的事实表和维表都保留历史信息。为使数据量不至于过大，事实表和维表都采用时间轴压缩设计，用有效开始日（ＥＦＦＥＣＴＩＶＥ＿ＦＲＯＭ）、有效截止日（ＥＦＦＥＣＴＩＶＥ＿ＴＯ）来压缩这段时间内未发生变化的数据。在使用压缩的历史数据时，若进行解压缩，必然既耗费时间又浪费空间。通过巧妙设计ＪＯＩＮ（下转第３９页）（上接第３７页）方法，就可以不经过解压缩而得到准确的历史数据。例如：事实表ａ和维表ｂ都经过了时间轴压缩，现在事实表ａ需要ＪＯＩＮ维表ｂ中相应时间点的信息，那么正确的结果应该是事实表ａ中的记录能够ＪＯＩＮ到维表ｂ中所有在时间段上与之相交的记录，并出现表２所示的四种基本相交情况。
 若将上述各种情况都写入ＳＱＬ语句的ＷＨＥＲＥ条件，势必很复杂。经过对时间段交集的分析，可归纳出下列的ＷＨＥＲＥ条件：
 ａ．ｅｆｆｅｃｔｉｖｅ＿ｆｒｏｍ ＜＝ ｂ．ｅｆｆｅｃｔｉｖｅ＿ｔｏ ａｎｄ
 ａ．ｅｆｆｅｃｔｉｖｅ＿ｔｏ ＞＝ ｂ．ｅｆｆｅｃｔｉｖｅ＿ｆｒｏｍ
 就能够保证事实表和维表ＪＯＩＮ结果的正确。
 （２）按变动频度的不同分割表
 ＣＲＭ中的各项数据变动频度常常是不同的，例如客户的开户许可证、法人代表等数据往往变动频度较小，而信用等级等数据可能变动频度较大。由于要保存历史数据的变动，变动频度不同的数据放在同一张表中容易造成数据的冗余。将变动频度较小的数据分离出来，放在不同的表中，就可以降低数据的冗余。