1、初步学习初步接触数据仓库时,建议先看维度模型,了解什么是事实表,什么是维度表。做一张事实表,定义哪些是维度、哪些是度量,然后通过SQL进行查询。有了基本概念后,可以再学习深一些的内容,例如星型模型、雪花模型。戳上图看天启关于数据模型的详解再进阶,则可以学习维度建模:选择业务过程-声明粒度-确定维度-确定事实,如果能亲身参与一个项目就更好了。2、步入设计首先要了解数据仓库的分层、每一层做什么,为什么要分层?然后,了解事实表的类型(事务、周期快照、累计快照)、维度表的类型(普通维度、缓慢变化维度)、总线矩阵、数据立方体(cube)等。3、高阶学习维度建模实践后,发现维度建模的不足,那么是时候可以开始研究其他建模了。建议通读并理解Inmon大师的范式建模(数据仓库之父Bill Inmon, Building the Data Warehouse)和Kimball大师的维度建模,两者的建模各有优劣,可以取长补短。4、解决业务问题数据模型最终解决的是业务问题,目前常见的建模以维度建模为主,但是维度建模不停的在变化, Bill Inmon提出了datavault的建模思想,数据仓库、数据平台、数据中台、数据湖等概念层出不穷。本质不变,目标还是解决实际的业务问题。我个人建议,我们数据仓库的规划可以自顶向下,采用Inmon的思想,开发和建模规范也要考虑全局,而在实施中可以采用维度建模,自底向上,采用Kimbal思想,落地快,迭代快。实际解决问题时不拘泥于一个模型,什么模型合适就用什么模型。5、阿里的创新阿里基于维度建模提出了公共模型层概念,一定程度上能解决数据共享和重复建设的问题,OneData的理念非常有研究价值。但在应用中我们需要注意,不要一味的用相同的场景做法去套不同行业,在实践中需要辩证看待,按需去用。6、模型标准数据模型没有好坏,只有用得对错。判断的标准也很简单,有没有解决业务问题?更高的要求是有没有驱动业务的变革或者创新。大白话来说就是两个问题:挣到钱了吗?省下钱了吗?