数据架构-之业务元数据参考表设计

目前无论是自主研发行业数据模型，还是引进业界厂商的行业模型，都是平面地描述业务，而实际情况是，平面思路的数据模型并不能解决业务逻辑定义的变化和业务逻辑结构的变化。

这里引进的新方案，就是用跟踪业务元数据的参考模型支撑业务变化中的数据模型，由于目前主流书籍和资料并没有介绍，所以只能简单介绍下基本思路。不知道Kimabll先生有没有写过相关资料，因为他指导过的项目几年前就这么设计了。虽然我这里说是引进新思路，但在几年前人家就在跑这个架构了。

首先介绍这个模型面向的实际需求：
1. 企业业务逻辑定义的变化。企业的发展是快速的，也必须快速变化才能适应竞争惨烈的世界市场。所以企业定义的业务逻辑也必须在变化中求胜，我们IT服务人员只能适应变化，不能让企业不变化。众所周知的缓慢变化维就是10多年前老前辈看见企业的业务数据会有变化和改动，于是设计出缓慢变化维解决方法，并通过三个途径去描述处理方案。

现在我们面临的问题，不仅仅是业务数据会变化，而是业务本身的逻辑定义也在变化，而不是数据。那变化维的处理方案已经鞭长莫及，必须通过更高层面的方案去解决。于是Kimabll先生考虑到了用跟踪元数据的辅助模型去处理这个棘手的问题，否则我们必须经常变化我们的模型以及对应的ETL，DW架构就无从谈起，一直在变的架构怎么能稳定运行呢？

比如企业的周定义，可以定义报表周期为周六到周五，也许某天定义会变为周日到周六；大区维的定义，也许刚开始定义的是南北大区，而后来该为东西南北，再后来改为八大大区；再比如收入的定义，财务的收入类型也许就不止一个，各大区、分公司收入定义也会不同，他们的收入定义也会变化，但是无论哪种定义，其实可以归结成收入类型去管理；再比如品类，企业产品线变化很大，而每个品类的定义也会有变化。

2.维度层级的变化需求。企业的很多维都是分层级的，比如地区可分为大区、省、地市等，也可以分为大区、分公司、省、地市。于是描述他们层级的管理表也是有必要的。当然对于层级的管理，大厂商的行业模型已经有一定的介绍，只不过建模方法可能有所不同。

具体实施办法，就是对于所有有可能定义变化的维进行一对一业务元数据跟踪，然后对于这些辅助参考表用一个总表统一管理。由于是描述元数据的表，所以都是手工输入数据，手工维护。在进入统一维度层之前和维表管理，形成由主业务模型和参考模型关联起来的新维表，这样即便业务元数据产生了变化，那么也不用对模型动手术了。这样才有可能数据仓库能使用几年甚至更长时间。