考察点
维度建模是数仓方法论的核心，这道题考的是你是否真做过建模而不是只背过概念。面试官希望听到四步法的顺序和每步的判断依据，更希望你能随手拿个业务（下单、支付）现场走一遍。追问常落在「粒度选错了怎么办」和「维度怎么取舍」上。
参考答案
第一步：选择业务过程
业务过程是组织里完成的一个个动作：下单、支付、发货、退款、曝光、点击。注意不是业务部门也不是报表需求，而是动作本身。选哪个过程先建模，看业务价值和数据可得性——电商一般从交易域的下单、支付开始，因为它们是收入口径的源头。一张事实表只承载一个业务过程，这是边界。新人常犯的错是把「用户交易分析」这种分析主题当成业务过程，结果一张表里既塞下单又塞支付，粒度混乱。
第二步：声明粒度
粒度回答「这张表的一行代表什么」，比如「一行 = 一个订单中的一个商品行」。粒度声明是整张表的契约，必须在动笔前用一句话写死，而且四个步骤里这一步最关键：粒度定错，后面全错。
原则是能多细就多细，选最细的原子粒度。理由很实际：汇总粒度是不可逆的，表建在订单级，业务方突然要看单品维度的数据就只能返工重建；建在订单行级，订单级汇总一个 group by 就能出来。粒度细的代价是数据量大，但在 Hadoop/MPP 体系下存储和计算都不是瓶颈，灵活性更值钱。还要警惕一个陷阱：不要为了满足当前需求混合粒度，比如大部分行是订单行、个别行是订单汇总，这种表下游用起来全是坑。
第三步：确定维度
粒度定了，维度就好定了——回答「这一行发生在什么上下文里」：谁（用户）、什么时间（日期）、在哪（地区）、对什么（商品、店铺、类目）、通过什么渠道。每个维度对应一个外键。
工程上的取舍在于维度属性怎么进表。纯 Kimball 做法是只放维度键，用的时候 join 维表；实际生产里高频属性（商品类目、用户年龄段）会维度退化直接冗余进事实表，避免下游每个查询都 join 大维表。判断标准：这个属性下游 80% 的查询都要用，就退化；偶尔用，留键 join。维度不是越多越好，先满足当前可见的需求，但维度模型的好处恰恰是加维度是向后兼容的——新加一列外键，老查询不受影响。
第四步：确定事实
事实是这一行里可以度量的数值：金额、件数、时长、次数。挑事实时要看它和粒度、维度是否自洽——订单行级的事实表里放「订单总运费」就是不自洽的（一个运费摊在多行上，直接求和会重复），要么把运费分摊到行，要么不放在这张表。
同时要检查事实的可加性：金额、件数完全可加；UV、比率不可加（这类通常放 DWS 或 ADS 再算）；余额、库存是半可加（跨时间不可加），要在元数据里标清楚，防止下游直接 sum 出荒谬的结果。
串起来走一遍
以电商下单为例：业务过程选「下单」；粒度声明为「一个订单的一个商品行」；维度取日期、用户、商品、店铺、渠道、地区；事实取下单件数、下单金额、优惠金额、分摊运费。一张 dwd_trade_order_detail 就出来了。支付过程同样走一遍，产出支付明细表，两者通过订单号可关联，但绝不合并成一张表。
可能的追问
- 粒度选错了怎么办？ 只能重建，这也是为什么强调第一次就按最细粒度建。补救做法是保留 DWD 明细不动，在 DWS 按新粒度汇总，而不是去改明细表。
- 四步法和 ER 建模什么关系？ ER 建模（Inmon 范式）面向业务流程的规范化，消除冗余、适合事务系统；维度建模面向分析，容忍冗余换查询性能和易理解性。数仓明细层用维度建模，如果公司有 ODS 之上的 EDW 层，那一层可能用三范式。
- 维度表太少，业务方要的属性没有怎么办？ 维度模型支持增量演进：先补维表，再把维度键退化进事实表，老数据该维度键置空或给默认值，并在数据字典里说明生效日期。