kimball推出维度建模。
按照事实表，维度表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）
维度建模法的缺点也是非常明显的，
1 由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。
而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。
而在这些与处理过程中，往往会导致大量的数据冗余。
2 如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
二，什么是维度表和事实表
事实表：存放大量有业务性能的度量值
维度表：包含有业务的文字描述
三，维度建模的方法
当一个人业务总是随时间发生变化，那么需要什么呢？
四步维度建模：
1，选取业务处理过程 （选取业务处理）
维度模型一致性
第一个维度模型应该是一个最有影响的模型（POS零售业务）
2，定义业务处理的粒度（定义粒度）
粒度的定义：对事实表的行给出确定的说明。也就是，如何描述事实表的单个行？
应根据业务处理过程中产生的最具有原子性信息，来开发维度模型（原子型数据就是不能再做进一步的细分）
最佳粒度的数据是：POS事物的单个分列项（）
3，选定用于每个事实表行的维度(选定维度)
引出的问题是：业务人员如何描述从业务处理过程得到的数据？
常见的维度有：日期，车，车主，账户，套餐，事件类型等
粒度定义后，可以确定基本维度，我们往往会在基本粒度上，加入更多的维度，而且这些附加维度不会产生另外的事实行
4，确定用于形成每个事实表行的数字型事实
回答的问题：要对什么内容进行评测（度量）？
典型的事实是：银行的账户余额，电商的订货量这样的可加性数字数据
这四步建模，以用户对业务的理解作为确定维度和事实的内容依据
但是，许多公司企图用数据驱动最省力的方式建模，结果很少有成功
----Question-----
数据仓库建模三范式建模为什么能保证口径的一致性？
三范式规则（不背原文了）是一种互斥的排他法规则，
按三范式设计出来的成员属性，
只可能从属于一个实体，
依赖于一个主键（其他都是引用），
换句话说只存于一个地方，其他都从这个地方取数，这当然就保证了数据一致。
而“维度”设计的本质，就是从不同角度来解读数据，
是一种包容性的方式（因为没有界限定义，所以连法则都不能算）。
比如我把楼上的例子再扩大化，国家和省市是可以作为两个维度来分析的（比如在统计营业收入时）但是国家又包括省市，
这就造成了一个成员可能在多个地方出现，数据相对三范式也就难以保证口径一致（因为要同步更新多个地方，可能会有时差或误差）