3. Schema设计与建模：从原则到实战

好，咱们进入第三章。这一章我打算聊聊Schema设计与建模。说实话，这是整个数据治理里最“手艺活”的部分。你规范定得再好，如果模型设计得一塌糊涂，后面资产质量根本没法看。我自己踩过不少坑，今天把这些经验掰开了讲。

3.1 关系型建模原则

关系型建模，说白了就是ER模型那一套。它的核心目标是——消除冗余，保证一致性。我早期做数据仓库时，特别喜欢用第三范式（3NF），觉得这样最“正统”。

但后来发现，过度范式化在分析场景下会带来灾难性的性能问题。所以我的建议是：OLTP系统严格遵循3NF，OLAP系统适度反范式。

我记得有一次接手一个客户系统，他们的订单表里居然把“客户姓名”和“客户等级”直接存进去了。结果客户改了个名字，所有历史订单都得跟着改——这就是典型的传递依赖没处理好。

3.2 维度建模原则

维度建模是Kimball老爷子提出的，专门为分析查询设计的。它的核心是星型模型和雪花模型。

我个人习惯：能用星型就别用雪花。雪花模型虽然节省了一点存储，但查询时要多join好几张表，性能损失远大于那点存储成本。

对比维度	星型模型	雪花模型
查询性能	高（join少）	低（join多）
存储冗余	较高	较低
维护复杂度	低	高
适用场景	大多数分析场景	维度层次深且稳定

你想想看，在BI报表里，用户等一个查询等10秒和等30秒，体验是完全不同的。所以我在做金融风控项目时，所有核心宽表都用的星型模型，雪花只用在一些静态字典表上。

3.3 宽表与窄表设计

这是个老生常谈但又特别容易翻车的话题。

• 窄表（Narrow Table）：行多列少，适合OLTP，更新快，但分析查询要大量聚合。
• 宽表（Wide Table）：列多行少，适合OLAP，查询快，但Schema变更成本高。

举个例子，用户画像场景。窄表可能是(user_id, attribute_name, attribute_value)，每行存一个属性。宽表则是(user_id, age, gender, city, ...)，每个属性一列。

窄表灵活，加属性不用改Schema；宽表查询快，不用做行转列。怎么选？看你的查询模式。如果属性经常一起查，用宽表；如果属性组合不确定，用窄表。

3.4 Schema On Read vs Schema On Write

这个对比很有意思。它本质上是在问：数据质量检查放在什么时候？

• Schema On Write：写入时强制校验Schema。传统关系型数据库都是这个模式。好处是数据质量高，坏处是写入慢，Schema变更成本高。
• Schema On Read：写入时不校验，读取时再解析。数据湖、Hadoop生态常用。好处是写入快，灵活，坏处是读取时可能发现数据格式不对。

所以我的建议是：关键业务数据用Schema On Write，探索性数据用Schema On Read。或者像我们现在做的，用Schema Registry做中间层——写入时注册Schema，读取时按版本解析。

3.5 本章知识体系

下面这张图，我把这四种设计模式的关系和适用场景串起来了。你可以把它当作一个决策参考。

嗯，这张图把四种设计模式的关系理清楚了。你从中心出发，根据业务场景选择一条路径，再往下细化。记住：没有银弹，只有权衡。

3.6 实战中的选择建议

最后，我把自己这些年总结的一个决策流程分享给你。遇到建模问题时，按这个顺序问自己：

1. 数据是给谁用的？ 业务系统（OLTP）还是分析系统（OLAP）？
2. 查询模式固定吗？ 固定就用宽表，不固定就用窄表或Schema On Read。
3. 数据一致性要求多高？ 高就用Schema On Write，低就用Schema On Read。
4. 团队维护能力如何？ 能力弱就别搞太复杂的模型，星型+宽表是最稳妥的。