MySQL(三) 为教学管理系统的学生成绩功能设计一个数据库 作

数据库和Excel的区别

Excel

作为数据的展示工具，附带有一定的数据处理能力。本身就是应用工具，直接面向用户提供应用，既可以少量存储数据，又可以处理数据。里面的数据也是较为独立的，一个excel就是要反应的一切数据。

姓名	学号	python	mysql	linux	java
小明	010201	80	60	89	67
小红	010202	90	70	89	89
欧阳	010202	85	90	89	79

数据库(Mysql)

数据是存储工具，是体系化应用的一环。数据库更多是应用系统的底层，本身不具有面向大众的应用能力，而是由应用系统提供面向公众的应用能力，比如我们题目中说到的学生信息管理系统。

数据库用处和对实际设计思路的影响

业务分析

在拿到需求以后，不应该立刻进行代码级别的操作。要进行业务上的梳理。比如，我们所作的学生管理系统里面的学生成绩部分，它所涉及的到底有哪些东西？不明了则思路混乱。

对象分析

不同专业可能会设有“相同”的课程；那么课程为什么要归集在专业之下，而不是在整个学校层级里面？

1. 归集在不同层级在数据表层面有什么不同？

   1. 归属于学校

   课程ID	课程名称	总学分	拟定开设学期
   a001	Linux	30	0101

   2. 归属于专业

   课程ID	课程名称	总学分	拟定开设学期	专业代码
   a001	Linux	10	0102	yx001
   a002	Linux	80	0101	jsj001

   可以看到，在数据表层级，如果需要将课程归集在专业之下，需要至少多一个字段(专业代码)表明课程与专业之间的相关关系。

2. 归属于不同层级对于实际业务有什么影响？
   在这里，我们的“业务”可以理解为“教学管理”。就像是归属于专业时的表中所列出的。当我们设计数据库时，如果把课程归属于学校而非专业，那么不同专业就无法针对看似相同的课程，做出不同的规划。无法满足实际业务需求，也会出现实际业务因为应用系统而卡脖子的现象。
   比如医学专业，因为涉及到一些数据模拟，可能也需要学习一定的Linux操作，但仅仅需要在安装、操作层面即可。而计算机专业，则需要借助于Linux的学习，更彻底的了解计算机操作系统设计。

   关于实际业务因为应用系统而卡脖子的现象，比如如果数据库设计的，仅能对一个学生进行一个专业分配，那么这个学生想实现修双专业甚至三专业，则是不可能的。当然他实际可以学，但是没学分、没证书。

数据结构设计

学院 专业 课程 学生 成绩

问题一 为什么有所谓的“数据有效性标识”？

问题二 成绩表的设计，和Excel式的表有什么不同，为什么？

问题三 在应用程序的角度考虑，就学生状态编码这个字段而言，有什么未解决的问题？

问题一 为什么有所谓的“数据有效性标识”？ 解释

如果在已经积累下数据的情况下，我想删除某门课程，应该怎么办？比如学校面向农业信息化，设置了农作物病虫害防治这门课程，经过两届的培养后，发现计算机专业并不需要这门课程，要删掉。如果直接删除，那两届学生的相关专业课成绩就不可查了。

问题二 成绩表的设计，和Excel式的表有什么不同，为什么？ 解释

Excel形式的成绩表

姓名	学号	python	mysql	linux	java
小明	010201	80	60	89	67
小红	010202	90	70	89	89
欧阳	010202	85	90	89	79

数据库中的表结构
“单表不可读”

学年	学期	课程编码	学生编码	成绩	成绩日期	考试类型	数据有效性标识
01	01	a001	010201	40	2021-06-20	01	Y
01	01	a001	010201	60	2021-09-20	02	Y

数据库中，表的设计是为了方便数据的存储与管理，而不是面向单纯的数据展示。所以，很多情况下，单一的某个数据表，用户是很难读懂的。
具体到这里：

1. excel表特点：
   1. 课程字段化，成绩在横向(字段)上占据了很多空间
   2. 除成绩外几乎无额外的信息，以及大量信息都直观可读。
2. 数据表的特点
   1. 虽然是成绩表，但成绩，在占据的空间很小，只有一个字段，其他的字段看似都是无关的字段。
   2. 里面很多字段都是代码性质的，不是直接可读的信息。

为什么？

1. excel
   面向的是单次的成绩展示，给我们的更多的是某次考试的情况的汇总，更像是学生管理系统中的某个界面，需要让用户直观、快速的了解信息。
2. 数据表
   1. 成绩的纵向排列：我们需要将 的数据，放入同一个表中；而且还要保障表是在数据级别增加，而不是数据结构层面的改变。比如我们 需要放入Linux成绩，也需要放入python成绩，还需要放入农作物病虫害防治的成绩；我们需要让同一张表，在数据变动而非结构变动的情况下，应对这些可能性。
   2. 不可读性：并不是为了不可读，只是在应对信息变动。系统可以保证内建的代码不变动，但无法保证代码对应的名称不变动。就像你可以改名，但无法改身份证号。

问题三 在应用程序的角度考虑，就学生状态编码这个字段而言，有什么未解决的问题？ 解释

在学生信息表中，有个学生状态编码这个字段，首先从业务层面考虑，这个字段要解决什么问题？
比如有的学生毕业了，有的在读。这个代码，就是为了解决这个问题。

1. 为什么用代码，而不是直接用毕业、在读这种指定的词汇？
   这样当然时为了防止名称变更；但更重点是提供一种更应用方式。
   想象一下，当一个学生提前毕业了，系统管理员应该如何更改其状态？(当然实际应用系统肯定会有大量自动化的条件触发操作，我们只考虑手工) ，他需要在这个学生的信息中，选择某个状态，比如毕业，然后点击确定按钮进行更新。
   为什么采用“选择”的方式，而不是直接让管理员输入上毕业这两个字？因为输入的不可控，可能有人输入的是毕业，有人输入的是笔业。
2. 既然是选择，就需要有个列表，这个列表在哪里？
   当我们整套系统，第一次使用时，很明显学生基本信息表中是空的，这就需要有一个既有的表，提供我们需要的学生状态列表，这种类型的表，我们通常叫做字典表，提供一种名称和代码的对应关系，数据可维护且相对稳定。比如我又想起来，需要有个状态叫肄业，就可以由进行这个状态的添加，后续其他人只需要在学生基本信息中，选择这个新建的状态直接更新到对应的学生上就可以。