【面试】拿到需求后你是如何设置合理的数据库模型的？

之前面试技术主管的时候遇到的这个题目，当时其实是将问题想得太复杂了，“什么进行 WBS 分解”、“怎么做概要设计”等等的都给人回答了。但其实面试官只想问“合理设置数据库模型”这个点而已。

没办法，那时阅历少只要有面试机会就想将自己知道的都讲了，反正多说肯定比少说要好，万一人家看不上我技术看上我其他能力呢…

回归正题，围绕着“合理设置数据库模型”重新回答一下吧。

数据库建模是一个综合性过程，需要结合对业务的理解、数据特点以及数据库理论才能设计出高质量的模型。我认为要做到以下 6 点：

1. 之所以题目里面说“拿到需求后”，是想将前置条件摆出来，这里隐藏的信息是“需求已过评审”，你作为设计人员已经充分了解了业务需求内容。唯有这样你才能够正确识别出实体并区分出不同类型；
2. 在识别出实体后自然也能够定义实体属性了，属性设置要明确数据类型、长度、允许为空、默认值等约束条件；
3. 单有实体也不行，这世间万物无不存在着各种各样的“关系”。在设计实体关系时要考虑不同的卡迪纳利提（Cardinality），一对一、一对多还是多对多，同时考虑关系的可选性和依赖性，这都跟“充分了解业务需求”密不可分；
4. 之后在进行规范化设计时，还需识别功能依赖和联合主键，避免产生冗余数据。但是这个还需要结合实际情况，若通过部分数据冗余能够解决性能瓶颈问题，那么冗余数据还是有必要存在的。说到底这个还是要取决于业务需要；
5. 在进行物理模型设计时要根据查询和操作特征选择合适的索引和存储结构，譬如：尽量采用主键索引查询、注意联合索引字段先后顺序和 SQL 执行机制之间的关系、数据库引擎在 OLAP（联机分析处理）和 OLTP（联机事务处理）类型应用之间的选择等等；
6. 设计权限和安全策略，保证数据安全，譬如：有些项目需要做读写分离的情况下，建议写库不要直接使用 root 账号且“可写”用户只能够检索到自己的 schema 内容，而“可读”用户只开放“只读”能力即可。“可读可写”两个用户应具备不同的权限限制，避免访问权限过大；

在以上 6 点中，前 4 点都是数据概念建模的工作，这数据概念建模属于逻辑设计，此时并不需要考虑具体的实现技术。目的是创建一个准确反映业务需求的概念模型为后续的物理实现打下基础，这也是整个数据库模型设计的核心。

数据库模型形成后并不是直接投入开发，而是需要验证以确保结果符合预期。这就要与业务团队多沟通讨论，以获得他们的反馈（在这一步就要拉上项目经理或者产品经理，让两位经理牵头去做这件事，确保大家对于业务理解是一致的。不然只跟业务人员开会确认，两位经理不认账之后要对质就比较麻烦了）。我总结为以下 5 点：

1. 跟业务人员复核实体和属性，确保没有遗漏重要信息；
2. 检查实体间的关系，确认关系的定义符合业务逻辑；
3. 通过插入示例数据的方式，测试模型是否可以符合各种预期情况；
4. 通过编写相关查询，验证是否可以获取到所需的数据结果集；
5. 反复调整模型，直到验证结果表明模型满足业务需求并且设计合理；

直到现在为止，数据库模型的设计才算是完成。