Kimball维度建模技术几乎已经成为数据仓库建模的最佳实践。维度建模的基本概念总结。
收集业务需求
在建模工作前，项目组需要跟使用数据的业务人员进行沟通调研，理解业务过程的KPI，数据分析的目标，利用数据进行哪些决策制定。可以收集业务人员，高层决策者经常看的报表，了解他们观察数据的维度跟指标。
协作维度建模研讨
维度建模不应该只由那些不懂业务以及业务需求的技术人员来负责，还需要企业数据管理者与使用者的参与共同制定数据分析主题。与业务代表开展一系列高级别交流讨论可以帮助技术人员和需求分析人员对数据有更深入的了解，寻找不同部门使用数据的分析维度与指标的异同。
维度建模的设计过程
维度模型设计主要设计四个步骤：
选择业务过程
业务过程是组织完成的操作型活动，例如：获得订单，处理保险索赔、学生课程注册或每个月每个账单的快照等等。过程的选择很重要，因为我们要从业务过程中得出事实的指标度量，以及事实表的粒度选取，维度划分等等。
声明粒度
声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性能的关键。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。粒度越小，描述的业务过程越详细。建议从设计最小粒度的数据开始，这样可以保证比较大的灵活性，满足无法预期的业务用户的查询需求。这对不同的事实表粒度要建立不同的物理表，在同一事实表中不要混用多种不同的粒度。
确认维度
维度表又是被称为数据仓库的“灵魂”，因为维度包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。维度提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定事实表行关联是，任何情况下都应使维度保持但一值。
确认事实
事实基本上都是以数量值表示，涉及来自业务过程事件的度量，例如销售量，销售额等。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。
星型模型与OLAP多维数据库
星型模式是部署在关系数据库管理系统(RDBMS)之上的多维结构。典型地，主要包含事实表，以及通过主键/外键关系与之关联的维度表。联机分析处理(OLAP)多维数据库是实现在多维数据库之上的数据结构，它来源于关系型星型模式。OLAP多维数据库包含维度属性和事实表，但它能够比SQL语言具有更强的分析能力和访问，比如XMLA和MDX等。
灵活扩展
维度模型对数据关系发生变化具有灵活的适用性。当发生如下变化时，不需要改变现存的BI查询或应用，就可以方便的适应。
- 当事实与存在的事实表粒度一致时，可以创建新列。
- 通过建立新的外键列，可以将维度关联到已经存在的事实表上，前提是维度列与事实表粒度保持一致。
- 可以在维度表上通过建立新列添加属性。
- 可以使事实表的烈度更原子化，方法是在维度表上增加属性。然后以更细的烈度重置事实表，小心保存事实表及维度表的列名。
参考
《The Data Warehouse Toolkit:The Definitive Guide to Dimensional Modeling》,Ralph Kimball & Margy Ross
