数据仓库为什么要建模？如何找到说服老板建设的理由？
想象一个场景，你想说服老板搞数据仓库建模，该如何说清楚其价值呢？
也许你会这么说。
如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；
如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。
Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。
上面的话似乎有道理，但如此的表述还是技术化了一点，既没有站在应用的角度看模型价值，描述的也不够具体和形象，老板听起来肯定也是云里雾里。
我这么来理解数据仓库建模的价值。
数据仓库采集进来的原始数据是杂乱无章的，只有通过构建数据模型，将数据有序的组织和存储起来之后（即模型），才能为上层应用提供高效灵活的支撑，优秀的数据仓库模型对应用的价值主要体现在数据质量、响应速度、成本消耗及健壮水平四个方面：
1.数据质量
通过建模可以准确的理解业务和数据，实现业务和数据的标准映射，从而提升应用的有效性。
比如原始数据对于性别字段的枚举值既有男女，也有01等形式，这种定义的分歧会对上层的应用产生干扰，数据模型应该依据数据标准对原始数据进行标准化，所谓“书同文，车同轨”，数据治理的要求往往要落在具体的数据建模中才能发挥作用。
2.响应速度
通过建模可以提前基于源数据生成应用所需的模型，提升应用响应能力。
宽表就是一种典型的模型，如果没有宽表，应用就要将数据处理的复杂逻辑嵌入在应用中实现，无论是代码的开销、处理的开销及访问的开销都很大，因此往往需要预先生成模型来置换时间，也就是空间换时间。
风险在于应用变化无常，而模型往往后知后觉，现在只管杀不管埋的现象很多了，导致企业中80%的模型没人使用，元数据很大的一个应用场景就是模型生命周期的管理。
3.资源消耗
通过建模可以实现公共数据的共享，提升复用能力。
比如发现某些应用共同需要某个计算字段，则可以将这个计算字段预先生成（即沉淀成模型），这样有新的应用需要时可以直接使用，从而在资源和时间节省上一举两得。
这个角度讲，OLAP的CUBE其实就是一种建模，当然应用（上层模型也可以看成应用）如果不够多，复用无从谈起，建模也就失去了价值，很多时候感觉数据仓库的模型没啥卵用，大多时候是复用的效益不够明显所致。
4.健壮水平
通过建模可以实现应用与源数据的解耦，降低源数据变动对应用的影响，提升应用的健壮性。
比如有100个应用直接依赖某个源数据，如果这个源数据发生变动，则需要对100个应用都进行适配改造，代价非常大。
而如果100个应用都是基于模型支撑的，则可以在保证模型北向应用接口不动的情况下，仅改造模型和源数据的南向接口就可以了，不仅改动的工作量大幅减少（比如原来改100次现在只需要改一次），同时保证了应用的连续性。
风险在于模型强制映射转化往往开销很大，模型的冗余度、复杂度会越来越高，源数据变更后的一些新特性也会被抛弃，最终影响应用的支撑效率。
很多时候，搞清楚为什么要数据仓库建模，比数据仓库模型怎么建更有意义，因为前者决定了方向，搞清楚了本质就不容易走错路，比如一些小而美的场景往往不需要建模。
关于数据仓库模型怎么建的文章已经很多了，无论是关系还是维度，相对也比较成熟，这里就不再累述了。
立即沟通
