最近频繁参与数据仓库模型设计，按照概念模型、逻辑模型和物理模型这三个层面、阶段来划分进行设计，每一阶段都存在难以厘清的地方，需要一些权衡，尤其逻辑模型的设计为重中之重。
现在按照这三个阶段分别谈一些经历。
1. 概念设计
划清需求边界，就是我这一套设计要回答什么问题，功能集引领设计的推进。这里要避免陷入两种不恰当的思辨：
a. 数据源是否存在，现有技术能否获取足够的数据源
b. 如果需求不能满足怎么办
这两种想法均不要在这一阶段去做深入考虑，我们现在要做一个完整、总体的规划，其实很多需求还没有商业价值或者暂时没有开发的必要，但是我们必须在这里全面考虑，对于主题的划分和建设尤为有用。
接下来就是主题的提炼和抽象，很多人都会问及一个问题，主题是怎么来的，传统行业可以根据几十年经验来得出一些主题，但是互联网领域的创新企业面临不断变化的业务，不能以经验来提炼主题，我们必须对我们的需求进行归纳，形成一定的规范，比如互联网金融企业中对贷款分析收集的一些需求，根据整理、提炼和总结如下图：
通过这种方式，我们就能不断完善存在的主题，并提炼出、增加新的主题，不断的来形成完整的主题域。
2. 逻辑设计
通过完整的功能集和主题，我们就能够根据主题设计一张支持回答某一主题分析的各种问题的宽表，但是为了如下三点，我们必须要规划出一个层次模型：
a. 对数据进行缓冲，
b. 使得表模型具有可扩展性，增删字段不能影响层次的划分，
c. 减少重复计算，使得同一个功能模块的实现仅仅计算一次而后多次复用。
伴随理念的传播，现在各企业在数据仓库模型设计上均根据上述三原则基本上划分如下几个层次：
接口数据层是承上启下的阶段，首先它应包含一个主题的所有信息，且需要确立决定一行记录的主键，或为一个entity或为一个session，由此它决定基础数据层根据原有表信息需要做怎样的清洗、转换，且在有限表数量的前提下实现接口数据层的主题表，也由此决定应用数据层中各张表的计算，必须力求高效、快速和表达清晰。一些人对接口数据层存在两种不解
a. 有了基础数据层，为什么还要有这一层模型，并告诉你做事要有geek精神，
b. 这一层到底由应用层决定还是由基础层决定？他们有的为了厘清这个问题划分两个阶段，需求积累不多的时候，由应用层来决定；等到需求稳定后由基础层来决定。甚或有人设计如下开发过程，首先由基础层支撑各种业务需求，在积累达到一定规模后再规划设计接口层重构以前的计算，如下图：
这些思想都不能充分体现概念设计的关键，也不能尊重数仓模型的原则和要义。在上图的规划中难免让人怀疑接口层存在的必要。
3. 物理设计
在这里不多赘述了，明确如下几点：
a. 数据源的收集，增量还是全量以及各自如何操作。
b. 根据数据库的选择，配置好数据类型、存储属性，特别是分布式数据库要配置好散列原则
c. 分区表明确建立分区的原则和生成机制，拉链表明确生成算法。
