维度建模详解
星座模型只是星型模型的维度公用，类似这种
实际开发中，针对某一主题可以有明确的星型模型，星座模型啥的。但是众多主题间也存在维度公用的情况，这样交织在一起形成一张大网，很难说是啥模型吧。
1 维度设计
1.1 代理键
维度表主键，关联事实表
解决办法：自创一个自增的id，取代source+id这种判断方法
所以有了代理键这个东西：
实现方法：前一天gid的max+新增数据的行号，就是增量的gid了。
1.2 稳定维度
1.3 缓慢渐变维 => 拉链表
这样这个id就不唯一了，跟事实表关联的话就要再弄一个代理键才行
这样按部门统计有两个，按客户统计有一个就解决问题了，没有代理键的话，就乱了。
mysql的业务数据=>事实表的时候，就要把代理键给弄进去
具体操作方法：
不管全量增量，先把今天发生的事情选出来，再去关联。
第一种是给普通数据库用的，hive不能用非等值连接，就只能先join再where了
但是这样很麻烦，一般用的不多，有时候可以用全量快照。
1.4 维度表的拆分、合并
横向拆分：销售员工、技术员工等
纵向拆分：不同员工关注不同的字段
弄一张大宽表，没有对应的属性字段就空着，谁要啥信息就从里面弄一张子表用，
没啥特殊情况就用这个就行，空间换时间。
也可以弄一个基础信息表，不同的表在这个基础上加上自己想要的相关属性字段
2 事实表设计
2.1 明细事实表
降维就是把外面关联的维度信息弄进事实表，统计的时候减少关联操作用的
有时候事实表里面没有度量，比如这个审核表
多个动作的事实表啥设计？
多事实表
单事实表，不断更新