学生信息管理系统开发实战：掌握多数据模型关联关系的设计和使用

前言

我们日常使用的业务系统，核心都是围绕数据展开，基于数据变化出无穷的可能。本篇文章将基于《学生信息管理系统》这样浅显易懂的场景，介绍如何设计和创建模型，如何在多模型之间建立复杂的关联关系，以及如何在云开发平台中实际操作数据。

1. 数据模型设计范式

1.1 关系型数据库设计范式

数据模型就是基于业务的深刻理解抽象出数据存储的框架，最终落实到实际使用中使数据的读写具有可靠性、扩展性和高效率，从而提升生产效率带来效益。

在传统业务应用开发过程中，首先最重要的是对数据库做好设计构建，其理论依据则是上世纪 70 年代提出的“数据库三范式”:

• 第一范式（1NF）表中的每一列都是不可拆分的，即保证列的原子性。

• 第二范式（2NF）表中必须存在主键，且普通字段必须和主键相关，即保证主键列的完全依赖。

• 第三范式（3NF）表中非主键字段不应互相依赖，即避免依赖传递。

随着时代向前演进，为了满足日益复杂的业务系统要求，范式成员中又陆续新增了BCNF、4NF、5NF 等更多的范式，高阶范式一定满足低阶范式要求且范式设计越高阶，表的精细化越高，冗余度就越低。

1.2 反范式设计

既然数据库范式是减少冗余，那顾名思义，“反范式”就是增加冗余。事实上，在面对有些业务场景时，过于追求范式设计，会将拆分更多原子表，在数据整合时也会更多使用联表操作，联表本身就带来了复杂性和性能损耗，所以适当增加冗余反而更能高效率的完成查询任务，是一种“用空间换时间”的做法。

冗余，在提高查询性能的同时会增加数据写入的难度，通常需要双写或多写来保证冗余字段的一致性问题，所以开发者应精准识别业务中可提升性能、有价值的字段进行反范式设计。

1.3 数据模型设计范式

综上所述，数据模型设计范式基本沿用关系型数据库范式：将表抽象为模型，将列抽象为字段，按照具体业务需求合理设置模型中的字段，系统已为每个模型固定内置了主键 “_id” 作为数据标识，开发者无需关心主键，只需要在模型中创建模型直接依赖的字段即可，适当增加冗余。

2. 数据模型创建与关联关系定义

接下来，我们以《学生信息管理系统》为需求背景，从数据库E-R设计延伸出数据模型设计，直到生产中如何使用模型操作数据。

说明：以下截图均来自云后台数据管理界面，点击阅读原文登录

2.1 业务模型 E-R 图

《学生信息管理系统》主要做学生相关数据管理，其中包含多对一、多对多和一对一关系，如下图所示：

2.2 创建模型

基于业务需求，我们整理成表格信息，首先我们先依次创建出每个模型单体，不考虑关联关系。说明：

• 红色表示多对一关系

• 绿色表示多对多关系

• 黄色表示一对一关系

• 关联关系方便展示，本小节先不关心，在下一小节使用