数据仓库实践杂谈（十四）——数据模型参考

最新推荐文章于 2024-08-15 14:17:41 发布

老程序员一叶知秋

最新推荐文章于 2024-08-15 14:17:41 发布

阅读量2.3k

点赞数 1

分类专栏：数据仓库实践文章标签：数据仓库大数据概念数据模型数据建模数据分析

本文链接：https://blog.csdn.net/cfy_fantasyxx/article/details/104353604

版权

数据仓库实践专栏收录该内容

18 篇文章 56 订阅

订阅专栏

[目录]

数据仓库实践杂谈（十四）——数据模型参考

众所周知，信息系统最重要的作用就是处理并保存信息，尤其在商业应用中。以银行记账为例，最重要的是账本，不管前面的流程如何，只要记下来张三某年某月存入100元，业务就算完成了。当然，不是说业务流程的实现不重要，更便捷的流程，能提高业务效率。但核心的部分，是先要把事情做正确。

简单的定义，数据模型就是类似账本一样，能准确反映业务内涵的一组表格。由于业务的复杂性，让一般设计人员在刚开始设计数据模型的时候会无从下手。因此，各大公司都有一些逻辑数据模型的指导，如NCR、IBM等公司。

在金融业务中，由于业务复杂，往往需要大量的表格来描述业务，因此，必须分成若干的层次，若干的大模块，自顶向下的逐步细化分析。一般来说，数据模型都会分成三层。第一层是主题域，一般会分成八到十几个主题域。随着业务的不断发展以及对业务的不断理解加深，主题域有可能增加，也有可能合并。所谓的主题域，是一组描述同一主题的表的集合，如团体、资产等。在某些行业，需要对某些主题（业务范围）描述的非常完善和充分，这个主题可以作为一个主题域。但对于某些主题，由于不是业务重点，则可以合并成为一个主题域。第二层是重要实体，在这个层次，根据主题域的划分，每个主题域中可以提炼重要的实体。第三层是完整的E-R模型，包含了所有的实体和关系。

目前各公司提出的数据模型的几大主题域，都是经过特定行业不断检验的最佳实践。在设计我们自己的数据模型的时候，可以参考这些主题域，使得设计更加完善。

比如，考虑CRM模型的时候，大概会有多少实体需要去描述呢，参考各公司的模型，我们就可以大概的知道，至少包括：

团体，描述客户的基本信息，如不同的客户类型或角色等；
资产，描述客户的资产，有些模型可能增加专门域描述金融资产；
营销活动，针对客户展开的各种试图达到某种目的活动；
事件，客户发生的各种事件，与系统发生的交互也可以看做一种事件，但有些模型提示我们，可以把针对系统的交易当做一个独立的主题域；
位置：描述物理坐标或者定位（互联网位置、电话、移动终端标识等），以及这些位置标识和用户的关系等。一些模型提示我们，客户服务的渠道可以作为单独的主题域；
产品，我们能为客户提供的产品和服务信息；

如果针对金融业务较多的话，有些模型提示我们可以把金融交易，财务等作为一个单独的主题域来考虑。

另外，如果考虑的统计分类等更为灵活的设计的时候，可以把各种分类方案作为一个单独的主题域，被各种实体所引用。如IBM的模型中的“分类”。这是一种技术上的灵活处理，是由于随着业务的不断发展，会需要动态的增加新的类别。采用这样的设计，可以在业务发展的时候，不断增加模型的数据，而不破坏模型的结构。但这样的做法带来的问题的一个问题是，会导致从模型的结构上，难以全面的反应业务本身。因为很多分类往往代表了业务划分。这样做，把业务的结构变成了模型中的数据。从各种模型的主题域划分的方式上来看，IBM的模型更加具有技术性。更像元元数据模型。

如何取舍，要看具体的设计。

各种模型的主题域，参见下面。