本文主要是介绍kimball维度建模步骤，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
业务需求
维度模型
1.业务处理
2.粒度
3.维度
4.事实 （数据实际）
首先对业务进行描述，以使建立的维度与事实表更容易理解。
在对业务实例研究进行描述之后，现在就可以开始维度建模的设计工作了。
第一步:选取业务处理
设计工作的第一步使，通过将对业务需求的理解与对可用数据的理解组合起来而确定
建模的业务处理内容。
建立的第一个维度模型应该是一个最有影响的模型--它应该对最紧迫的业务问题做出回答，并且对数据的抽取来说使容易访问的。
第二部：定义粒度
一旦将业务处理确定下来，数据仓库团队下一个就面临关于粒度确定的颜色课题。
应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。
原子型数据是高度维结构化。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。
原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。
维度模型的细节性数据是安如泰山的，并随时准备接受业务用户的特殊攻击。
可以总是结合业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。
不过，只要选取较高层面的粒度就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。如果不让用户存取原子型数据，则他将不可避免地在分析方面撞上南墙。
聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它绝对不能作为用户存取最底层面的细节内容的替代品。
数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个底层面的行，而是因为查询希望以很精确的方式对细节知识进行抽取。
第三步：选定维度
一旦事实表的粒度被选定，则时期、产品与商店方面的维度就应该随之被确定下来。
在基本维度框架范围内，可能需要知道其他诸如针对某种产品的促销这样的维度是否可以分配数据。这个内容可表示为另外一个设计原则。
一个经过仔细考虑的粒度定义确定了事实表的基本维度特征。同时，经常也可能向事实表的基本粒度加入更多的维度，而这些附加的维度会在基本维度的每个组合值方面自然地取得惟一的值。
如果附加的维度因为导致生产另外的事实行而违背了这个基本的粒度定义，那么必须对粒度定义进行修改以适应这个维度的情形。
第四步：确定事实
设计过程的第四步同时也是最后一步，在于仔细确定哪些事实要在事实表中出现。粒度定义在这里再次成为考虑问题的支点。只是需要支出，事实对于粒度必须是真实的。
当考虑潜在的事实时，可能会再次发现，对早先的粒度设想或者维度选取做出调整是非常必要的。
单价也是非加型事实。试图在任何维度范围内对单价进行求和，都会导致出现一些毫无意义的甚至显得荒谬的数值结果。
要针对一系列商店或者一个时间跨度分析某种产品的平均售价，就必须在用销售总量取除销售总额之前，将相关销售额与销售量加起来。虽然数据仓库市场方面的报表生成器或者查询工具都应该自动地正确完成这个功能，但是很遗憾，其中一部分工具仍旧布恩那个很圆满地做到这一点。
在设计的早期阶段，经常对可能需要的最大表即最大事实表的行数做出估计是很有益处的
这篇关于kimball维度建模步骤的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
