市面公司大多基础模型如图
数仓建模目标
1.访问性能-快速查询所需数据,减少IO,缩短统计路径
2.数据成本-减少不必要的数据冗余，实际计算结果数据复用,降低达数据系统中的存储成本和计算成本
3.使用效率-改善用户体验，提高使用数据率
4.数据质量-改善数据口径不一致性,减少计算错误的可能性,提供高质量的,一致的数据访问平台。
（这里我感觉数据仓库也属于为大数据计算提供便捷的一个设计或者产品吧）
大数据的数仓建摸需要通过建模的方法更好的组织,存储数据,一边在性能,成本,效率和数据质量之间找到最佳的平衡点
关系模式范式
目的:降低数据的冗余性达到数据一致性,涉及规范有
1.第一范式--表字段都应为原子性的,不可分割的
2.第二范式--实体的属性完全依赖于主键字段，不能存在依赖外键之类的字段（非主键）。（缺点：容易造成冗余，调整表字段时候造成大量列的修改）
3.第三范式--消除传递依赖（传统数据库和数据仓库一般只做到第三范式）
4.巴斯-柯德范式（对第三范式的一个补充）
5.第四范式
6.第六范式
数据仓库建模基本理论模型（实体 eg:[商品，仓库，货位，汽车]，属性 eg:[颜色，尺寸，重量，产地]，关系表示数据之间的关系）
1.ER实体模型
2.维度建模
3.dataValue模型
4.Anchor（key-value）模型
关系:实体之间建立关系时,存在对照关系一般有:
1:1
1:n
n:m
梳理步骤一般为
1.找出实体,抽象出主体
2.梳理关系
3.梳理属性
4.画ER关系图
雪花,星型模型对比（只要纬度表下还有伸衍生出的纬度表,设计方式就是雪花模型,降纬会变成星型模型）
冗余：雪花模型符合业务逻辑设计,采用三范式设计,有效降低数据冗余;星型模型的纬度表设计不符合三范式,反而更规范化,纬度表之间不会直接相关,牺牲部分存储空间
性能:雪花模型由于存在纬度间的关联,采用三范式降低冗余,通常在使用过程中,需要连接更多的维度表,导致性能偏低;星型模型反三范式,采用降纬的操作将纬度整合,以存储空间为代价有效降低纬度表连接数,性能较雪花模型高
ETL难度:雪花模型符合业务ER模型设计原则,在ETL过程中相对简单,但是由于附属模型的限制,ETL任务并行化较低；
星型模型设计纬度时反范式设计,所以在ETL过程中整合业务数据到纬度表有一定难度,但是由于避免附属纬度,可并行化处理
总结:星型模型和雪花模型之间的转换其实是一个以空间换取时间的一个过程,降低了纬度增加了数据统计的数据的速度,但是增加了数据的人冗余,增加了存储的开销
hive优化层面:星型模型少的表可以减少job数,减少资源的开销.而且星型模型虽然数据冗余,但是只有一个文件,但是雪花模型虽然符合三范式,但是却是会产生多个文件,总体文件数的大小不一定比星星模型小
（一般优选星型模型）