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

前言

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

1. 数据模型设计范式

1.1 关系型数据库设计范式

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

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

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

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

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

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

图片

1.2 反范式设计

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

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

1.3 数据模型设计范式

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

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

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

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

2.1 业务模型 E-R 图

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

图片

2.2 创建模型

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

  • 红色表示多对一关系

  • 绿色表示多对多关系

  • 黄色表示一对一关系

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

学生 班级 课程 学籍信息
姓名 名称 编号 编号
年龄 年级 名称 学籍所在地
性别
所在班级 班内学生
所学课程
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值