开始维度建模工作前，需要理解业务需求，以及作为基础的源数据的情况。
通过与业务代表交流来发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。
还可以与源系统人员交流，构建高层次数据分析访问数据可行性来揭示。
协作维度建模讨论
维度建模应该由主题专家与企业数据管理人员合作设计而成。
工作由数据建模负责，但模型应该通过与业务代表开展一系列交互讨论获得。
这些讨论为丰富的业务提供机会。
维度建模不应该由那些不懂业务以及业务需求的人来设计，协作是成功的关键。
维度建模设计的4个步骤维度建模期间主要涉及到4个主要的决策：-
选择业务过程
-
声明粒度
-
确认维度
-
确认事实
粒度
粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的阶段。在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。 从给定的业务过程获取数据时，原子粒度是最低级的粒度。建议从关注原子级别粒度开始设计，因为原子粒度数据能够承受无法预期的用户查询。
针对不同的事实表粒度，要建立不同的物理表，在统一事实表中不要混用多种不同的粒度。简单而言就是一种事实表的一种粒度要单独建一个物理表
描述环境的维度
维度提供围绕某一业务过程事件所涉及的 “ 谁、什么、何处、何时、为什么、干了什么事 ” 等背景。
维度表包含BI应用所需要的用于过滤以及分类事实的描述性属性。掌握事实表的粒度，就能够将所有存在的维度区分开。当与给定事实表行关联时，任何情况下都应使维度保持单一值。维度表有时候被称为数据仓库的 “ 灵魂 ” ，因为维度表包含确保 DW/BI系统能够被用作业务分析的入口和描述性标识。主要的工作都放在数据管理与维度表的开发方面，因为他们是用户BI经验的驱动者。用于度量的事实
事实设计来自业务过程事件的变量，基本上都是以数量值表示。
一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此实施博爱对应一个屋里可观察事件。
在事实表内，所有的事实只允许与声明的粒度保持一致
行星模型与OLAP多维数据库星型模型是部署在关系数据库管理系统（RDBMS）之上的多维结构。
典型的，主要包括事实表，以及通过主键/外键关系与之关联的维度表。
联机分析处理（OLAP）多为数据库是实现在多为数据库之上的多维结构，他与关系型星型模式内容等价，或者说来源于关系型星型模式。
OLAP多为数据库包含维度属性和事实表，但它能够使用比SQL语言具有更强大的分析能力的语言访问
维度模型对数据关系发生变化具有灵活的适应性。当发生以下所列举的变化时，不需要改变现存的BI查询或应用，就可以方便地适应，且查询结果不会有任何变化。
-
当事实与存在的事实表粒度一致时，可以创建新列
-
通过建立新的外键列，可以将维度关联到已经存在的事实表上，前提是维度列与事实表粒度保持一致
-
可以在维度表上通过建立新列添加属性
-
可以使事实表的粒度更原子化，方法是在维度表上增加属性，然后以更细的粒度重置事实表，小心保存事实表以及维度表的列名
