范式建模
3NF
- 第一范式：保证每列的原子性。即数据库表中的所有字段值都是不可分解的原子值。
- 第二范式：保证一张表只描述一件事情。即除主键外其他字段完全依赖于主键。
- 第三范式：不可传递依赖。即表中的字段和主键直接对应不依靠其他中间字段，说白了就是，决定某字段值的必须是主键。
建模方式在范式理论上符合3NF，这里的3NF与OLTP中的3NF还是有点区别的：关系数据库中的3NF是针对具体的业务流程的实体对象关系抽象，而数据仓库的3NF是站在企业角度面向主题的抽象。
优点能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。
ER实体建模
将事务抽象为"实体"（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。用实体关系模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。
维度建模
维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。维度建模以数据分析作为出发点，为数据分析服务，因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
优点
- 适配大数据的处理方式
维度模型的非强范式的，可以更好的利用大数据处理框架的处理能力，避免范式操作的过多关联操作，可以实现高度的并行化。数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。
星型模型和雪花型模型的区别 - 自下而上的建设现状
表已经存在，业务已经开发完毕，需求直接提过来了，这几乎是一个普遍现状，因为很少有公司会提前成立数据部门，让数据部门跟随着业务从头开始一直成长，都是当业务发展到一定的阶段了，想通过数据来提高公司的运营效果 - 简单的模型
这个模型相对来说是比较简单的，简单主要体现在两个方面：
（1）维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。
（2）星型结构的实现不用考虑很多正规化的因素，设计与实现都比较简单。