数据仓库实践杂谈（十四）——数据模型参考
[目录]
第一章：概述 第二章：整体数据分层 第三章：整体实现框架 第四章：元数据 第五章：ETL 第六章：数据校验 第七章：数据标准化 第八章：去重 第九章：增量/全量 第十章：拉链处理 第十一章：分布式处理增量 第十二章：列式存储 第十三章：逻辑数据模型（数仓模型） 第十四章：数据模型参考 第十五章：维模型 第十六章：渐变维 第十七章：数据回滚 第十八章：关于报表 第十九章：数据挖掘 数据仓库实践杂谈（十四）——数据模型参考众所周知，信息系统最重要的作用就是处理并保存信息，尤其在商业应用中。以银行记账为例，最重要的是账本，不管前面的流程如何，只要记下来张三某年某月存入100元，业务就算完成了。当然，不是说业务流程的实现不重要，更便捷的流程，能提高业务效率。但核心的部分，是先要把事情做正确。
简单的定义，数据模型就是类似账本一样，能准确反映业务内涵的一组表格。由于业务的复杂性，让一般设计人员在刚开始设计数据模型的时候会无从下手。因此，各大公司都有一些逻辑数据模型的指导，如NCR、IBM等公司。
在金融业务中，由于业务复杂，往往需要大量的表格来描述业务，因此，必须分成若干的层次，若干的大模块，自顶向下的逐步细化分析。一般来说，数据模型都会分成三层。第一层是主题域，一般会分成八到十几个主题域。随着业务的不断发展以及对业务的不断理解加深，主题域有可能增加，也有可能合并。所谓的主题域，是一组描述同一主题的表的集合，如团体、资产等。在某些行业，需要对某些主题（业务范围）描述的非常完善和充分，这个主题可以作为一个主题域。但对于某些主题，由于不是业务重点，则可以合并成为一个主题域。第二层是重要实体，在这个层次，根据主题域的划分，每个主题域中可以提炼重要的实体。第三层是完整的E-R模型，包含了所有的实体和关系。
目前各公司提出的数据模型的几大主题域，都是经过特定行业不断检验的最佳实践。在设计我们自己的数据模型的时候，可以参考这些主题域，使得设计更加完善。
比如，考虑CRM模型的时候，大概会有多少实体需要去描述呢，参考各公司的模型，我们就可以大概的知道，至少包括：
团体，描述客户的基本信息，如不同的客户类型或角色等； 资产，描述客户的资产，有些模型可能增加专门域描述金融资产； 营销活动，针对客户展开的各种试图达到某种目的活动； 事件，客户发生的各种事件，与系统发生的交互也可以看做一种事件，但有些模型提示我们，可以把针对系统的交易当做一个独立的主题域； 位置：描述物理坐标或者定位（互联网位置、电话、移动终端标识等），以及这些位置标识和用户的关系等。一些模型提示我们，客户服务的渠道可以作为单独的主题域； 产品，我们能为客户提供的产品和服务信息；如果针对金融业务较多的话，有些模型提示我们可以把金融交易，财务等作为一个单独的主题域来考虑。
另外，如果考虑的统计分类等更为灵活的设计的时候，可以把各种分类方案作为一个单独的主题域，被各种实体所引用。如IBM的模型中的“分类”。这是一种技术上的灵活处理，是由于随着业务的不断发展，会需要动态的增加新的类别。采用这样的设计，可以在业务发展的时候，不断增加模型的数据，而不破坏模型的结构。但这样的做法带来的问题的一个问题是，会导致从模型的结构上，难以全面的反应业务本身。因为很多分类往往代表了业务划分。这样做，把业务的结构变成了模型中的数据。从各种模型的主题域划分的方式上来看，IBM的模型更加具有技术性。更像元元数据模型。
如何取舍，要看具体的设计。
各种模型的主题域，参见下面。
NCR模型主题域
未完待续。
上一篇：数据仓库实践杂谈（十三）——逻辑数据模型（数仓模型）
作者：老程序员一叶知秋
