写在前面：
最近有些抵触写东西，总感觉自己没有清晰的表达思路和专业的知识体系，写的东西都是更偏向个人经验的一家之谈；之前总想着把文章结构做好，图片做好，表达做好，这样能更容易让大家理解，可以让更多的人接受所要表达的观点；但是，这样写太痛苦了，似乎是为了达到某种结果而刻意为之。。。
最终还是回归表达的本质，传播思路和想法，把这个说清楚就可以了，不管是三言两语还是长篇大论，让看到的人能知道有这么一种观点和想法即可，引发思考之后接受与否已经与表达者无关了；特别是一些偏向专业的内容，只需要让有专业背景和思考的受众了解即可；
简短的表达，节约大家的时间也是一种真诚～
从数据仓库的目的说起：
企业建立自身数据仓库的目的最早应该是为了数据分析，将企业各个在线系统的数据内容合并到一个离线数仓中进行大数据量的查询分析，以获得各种业务指标数据，按照行业的各种分析思路和方法，辅助业务做出最佳的决策；
一直到现在，大部分的企业也是以数据分析为目的进行数据仓库相关建设的；
随着信息化、数字化浪潮的到来，企业自身产生的数据量越来越多，数据种类愈加丰富，数据仓库慢慢向数据湖演变，汇聚了企业的所有信息化数据，使用场景也已经不再是单纯的数据分析了；
常规的数据分层理论成为共识：
ods作为采集数据层，保持源头数据的原貌，基本不过任何加工；
cdm作为整合数据层，用数仓的建模方法对数据进行整合加工，方便查找和使用；
adm作为应用数据层，面向具体的数据应用场景，按需加工出结果数据；
我们通常讲的数仓建模也就集中在后面两层，随着从业人员经验的不断积累和丰富，衍生出很多的建模理论，被广为推崇的或者大家接触最多的就是 维度建模 和 实体关系建模，大部分偏向应用数据层开发的同学基本上只用到维度建模，觉得这是一种万金油的建模理论，因为当前80%的应用场景都是面向分析的，所以维度建模理所当然成为首选，然后慢慢成为唯一推崇的选择；
从信息整合的逻辑分析：
信息在源头的组织形式基本都是实体关系建模，符合范式标准，因为当前技术上的限制，呈现为雪花状的模型结构；信息和数据在存储上是分散的，关联关系负责，需要很多的主键、外键进行约束；
因此业务系统在使用中都会有对应的数据中间件或应用框架，来辅助数据库信息的查询，即数据对象的封装；
当这些原始数据同步到数据仓库中后，应为数仓自身的设计，不再有各种约束和中间件对数据进行封装，多级分散的数据对sql查询分析来讲非常不友好，使用成本太高；所以就有了数仓整合数据的概念；
数据的整合目的是信息的整合，最好的结果就是有一个结构清晰的数据集合，能保持源头信息的完整性，又方便进行持续维护；所以就有了 整合数据层 的数据建模，也就是常说的中间层数据模型；
从维度建模的方法分析：
具体维度建模的详细介绍和实践方法，大家可以通过内网搜索到很多，这里就不多说了；最终目的一直都是为了数据分析的使用场景，因为数据分析的逻辑是对某个数据指标进行分析，一切的设计都是围绕指标分析的目的进行的；
维度表：即指标分析的视角，某个省的销售额，某个部门的销售额，某个商品的销售额；
事实表：即指标计算的对象，订单记录中的金额计算出销售额，订单记录中的数量计算出销售量；
从数据分析的场景看是非常简单清晰的，如果放到信息整合的场景中呢？
一个用户的所有信息：归属到维度？
一个用户的所有行为：归属到事实？
这个地方我无法把自己的思路说清楚，个人结论就是不合适：
不是所有的信息都可以归为维度视角
不是所有的计算对象都可以归为事实行为
再说理解上的问题：
我想要找到某个信息或者行为的数据，需要先进行定义上的转换==》是什么维度？什么事实？
这种转换定义唯一吗？不唯一，有几个数据开发同学就有几种定义。。。
所以，真的好使用吗？还是因为好开发？
从实体建模的方法分析：
很多人对ER实体建模方法的认知停留在现实世界中的实体关系上，而在业务系统中实体和关系是非常多样化的，特别是业务系统中的各种业务单据信息，必须以业务实体的形式来定义，即 常规对象实体+业务单据实体+关系 形成对企业完整信息的覆盖；
所以，实体关系模型在实际使用中是一种泛化的概念，即 实体对象+业务单据+关系 的信息模型，在实际的信息分布上，不同种类的对象信息呈现1:N的复杂结构，单据信息因为业务链路也会有很多1:N的发散；
在数据仓库中使用ER模型可以最接近业务系统模型的信息分布，所以更适合与进行企业全局的信息整合，但是对于数据研发人员的能力要求会比较高：需要全面了解企业业务和数据、实施周期非常长；
将各个系统的数据以企业角度按主题进行组合和合并，并进行一致性处理，为企业提供统一的数据服务，个人结论是最适合中大型企业进行全局数据仓库建设的最优解，不能因为对人员能力的要求和投入成本而放弃；
写在后面：
还是那句话，个人水平有限，表达能力有限，大家各取所需；
