提出问题？如果要你建立数据仓库，你如何确定数据仓库核心结构中要设计哪些表？以及表结构如何设计？下面通过问答的形势逐个解释。
Kimball模型设计过程：
1、 选定业务过程-依托业务流程
2、 确定粒度
3、 确定维度
4、 确定事实
问题1：如何确定仓库具有哪些维度表？
回答：
以有报表
业务人员沟通
原始DB，事件类表
具体到维度表设计方法要参考Kimball维度设计理论，这里不赘述。需要注意代理键、维度层级、缓慢变化维、多值维度、递归展开等场景维度设计技巧。
问题2：如何确定仓库具有哪些明细事实表？
回答：
首先我先提出两个概念：业务流和数据流。以上问题我通过对这两个概念的解释来回答。
业务流通过业务调研确定，因此数据仓库是强依赖于业务的一门技术，专业的业务知识可以更准确、更容易的建立成功数据仓库。因此，数据仓库建设我一直建议有业务专家的积极参与，要保证这些事情推进？又可以引出数据仓库很重要的一个命题？“建立成功的数据仓库需要大领导的全力支撑！（引自-数据仓库生命周期工具箱）“这句话可能新手不能理解？包括我入行时也不理解！但数仓是一门企业级项目，牵涉业务人员、业务开发、仓库本身还包括DW-BI不同组之间的协调合作。如没有大力度支撑，很难将事情在涉及参与人员这么广的情况下进行推广。据我所知，很多数仓项目就失败在这一点上。那么，了解了业务知识对于建仓的重要意义后，我们经过丰富的业务调研，需要确定主要业务流程，本人主导数仓设计主要依赖业务流程（业务上，后一个流程依赖于前一个，一个公司不一定存在一条流程）。
业务过程：业务流中不可再分的最小操作单位。
以上对业务调研结果完全可以做到不了解数据的情况下进行，并且可以确定下需要建模的业务过程，也就是说上述业务过程可能都要分别落地事实表，通过这个方法我们可以确定在DW中可能需要建立哪些事实表。这段说明也能侧面作证一个命题：数据仓库其实就是在做用数据描述业务这件事，因为我们落地哪些事实表取决于业务，而非完全参考业务DB数据表。
业务调研以确定业务流，跟据业务流判断可能落地事实表至此形成初步判断结果。下一步要根据业务流探查数据流了。
因为有了业务调研结果，就相当于为数据探查明确了目标。数据探查我们主要去找针对每一个业务过程记录的那些原始业务表存储在哪里，通过充分的了解后，我们可以制定数据采集方案，将上述业务过程相关的业务表都采集到数据仓库ODS中，为下一步ETL转化做准备。比如针对上述业务调研结果，填充数据探查结果后，流程如下：
销售：业务过程<->原始数据
至此，通过业务调研明确了业务流；通过数据探查明确了数据源。下面将数据结合业务调研结果和数据探查结果做合理调整就可以设计出仓库明细层事务时事实表表结构，并且依此结构可以进行ETL的编码转换操作了。
具体到维度表设计方法要参考Kimball维度设计理论，这里不赘述。需要说明的是，事实表可以合理进行反规范化操作。且事实表设计尽量面向业务而非直接面向需求设计。