题目重点：设计租赁服务实体关系与事实粒度，处理跨店还车、车型和车辆状态变化。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练booking与实际rental区分：预约可能取消或改车，实际租赁有pickup/dropoff与具体car；库存统计需要日期有效状态。
- 业务维度字段仅为示例，不声称题面给出完整DDL。每事实主键与粒度先写，再列字段。
解题路线
- dim_user、dim_car、dim_location、dim_date；fct_booking一行一个预约，fct_rental一行一次实际取还。一用户多预约/租赁，一车多时间不重叠rental，预约与实际关系需支持未履约/变更，不能默认一对一完整。
- rental关联pickupLocation和dropoffLocation两个role-playing外键，日期同理；当前car.location不能解释历史取车地点。车型变化或状态使用SCD/effective interval。
- 库存事实可按car-day记录可租/在租/维修/调拨状态，或事件有效区间生成快照。别把rental事实左join到当前car后直接作为任意历史日库存。
- 金额存分项/币种，quoted/charged/refunded区分，total spending可由收费事实汇总；订单行数不等于租赁天数，discount不可在join后重复。
- 数据质量验证car租赁不重叠、结束≥开始、订单/rental唯一键、状态迁移与外键；缺未还记录不能用当前日期永久写死结束，查询以asOf处理。
手动走一遍
预约车型small在门店A，实际升级large并在B还车。booking保留原意向，rental记真实car与两门店；收入分析可按实际车型，需求缺口分析按原预约车型，两者不能覆盖同一字段。
规模与取舍
事实量按预订/实际租赁次数，car-day快照按车数×天数；事件有效区间省存储但asOf查询复杂。SCD join需条件和唯一匹配避免重复事实，维表规模小不意味着join天然安全。
易错点与追问
容易失分的边界
- 把预约与实际混一表并覆盖车型，丢失需求证据。
- 当前location维度拿来重写历史，产生库存/收入错归。
继续深挖
- 同订单含多辆车时，怎样加入rental_item并防订单金额重复聚合？
- 有维护时间段时，utilization分母究竟用总车天还是可租车天？
