数据库和Excel的区别
Excel
作为数据的展示工具，附带有一定的数据处理能力。本身就是应用工具，直接面向用户提供应用，既可以少量存储数据，又可以处理数据。里面的数据也是较为独立的，一个excel就是要反应的一切数据。
| 姓名 | 学号 | python | mysql | linux | java |
|---|---|---|---|---|---|
| 小明 | 010201 | 80 | 60 | 89 | 67 |
| 小红 | 010202 | 90 | 70 | 89 | 89 |
| 欧阳 | 010202 | 85 | 90 | 89 | 79 |
数据库(Mysql)
数据是存储工具，是体系化应用的一环。数据库更多是应用系统的底层，本身不具有面向大众的应用能力，而是由应用系统提供面向公众的应用能力，比如我们题目中说到的学生信息管理系统。
业务分析
在拿到需求以后，不应该立刻进行代码级别的操作。要进行业务上的梳理。比如，我们所作的学生管理系统里面的学生成绩部分，它所涉及的到底有哪些东西？不明了则思路混乱。
不同专业可能会设有“相同”的课程；那么课程为什么要归集在专业之下，而不是在整个学校层级里面？
-
归集在不同层级在数据表层面有什么不同？
- 归属于
学校
课程ID 课程名称 总学分 拟定开设学期 a001 Linux 30 0101 - 归属于
专业
课程ID 课程名称 总学分 拟定开设学期 专业代码 a001 Linux 10 0102 yx001 a002 Linux 80 0101 jsj001 可以看到，在数据表层级，如果需要将课程归集在专业之下，需要至少多一个
字段(专业代码)表明课程与专业之间的相关关系。 - 归属于
-
归属于不同层级对于实际业务有什么影响？
在这里，我们的“业务”可以理解为“教学管理”。就像是归属于专业时的表中所列出的。当我们设计数据库时，如果把课程归属于学校而非专业，那么不同专业就无法针对看似相同的课程，做出不同的规划。无法满足实际业务需求，也会出现实际业务因为应用系统而卡脖子的现象。
比如医学专业，因为涉及到一些数据模拟，可能也需要学习一定的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 |
数据库中，表的设计是为了方便数据的存储与管理，而不是面向单纯的数据展示。所以，很多情况下，单一的某个数据表，用户是很难读懂的。
具体到这里：
- excel表特点：
- 课程字段化，成绩在横向(字段)上占据了很多空间
- 除成绩外几乎无额外的信息，以及大量信息都直观可读。
- 数据表的特点
- 虽然是成绩表，但
成绩，在占据的空间很小，只有一个字段，其他的字段看似都是无关的字段。
- 里面很多字段都是代码性质的，不是直接可读的信息。
- 虽然是成绩表，但
为什么？
- excel
面向的是单次的成绩展示，给我们的更多的是某次考试的情况的汇总，更像是学生管理系统中的某个界面，需要让用户直观、快速的了解信息。 - 数据表
-
成绩的纵向排列：我们需要将的数据，放入同一个表中；而且还要保障表是在数据级别增加，而不是数据结构层面的改变。比如我们
需要放入
Linux成绩，也python成绩，还农作物病虫害防治的成绩；我们需要让同一张表，在数据变动而非结构变动的情况下，应对这些可能性。 -
不可读性：并不是为了不可读，只是在应对信息变动。系统可以保证内建的代码不变动，但无法保证代码对应的名称不变动。就像你可以改名，但无法改身份证号。
-
问题三 在应用程序的角度考虑，就学生状态编码这个字段而言，有什么未解决的问题？ 解释
在学生信息表中，有个学生状态编码这个字段，首先从业务层面考虑，这个字段要解决什么问题？
比如有的学生毕业了，有的在读。这个代码，就是为了解决这个问题。
- 为什么用代码，而不是直接用
毕业、在读这种指定的词汇？
这样当然时为了防止名称变更；但更重点是提供一种更应用方式。
想象一下，当一个学生提前毕业了，系统管理员应该如何更改其状态？(当然实际应用系统肯定会有大量自动化的条件触发操作，我们只考虑手工) ，他需要在这个学生的信息中，选择某个状态，比如
毕业，然后点击确定按钮进行更新。
为什么采用“选择”的方式，而不是直接让管理员输入上毕业这两个字？因为输入的不可控，可能有人输入的是毕业，有人输入的是笔业。 - 既然是选择，就需要有个列表，这个列表在哪里？
当我们整套系统，第一次使用时，很明显学生基本信息表中是空的，这就需要有一个既有的表，提供我们需要的学生状态列表，这种类型的表，我们通常叫做字典表，提供一种名称和代码的对应关系，数据可维护且相对稳定。比如我又想起来，需要有个状态叫肄业，就可以由进行这个状态的添加，后续其他人只需要在学生基本信息中，选择这个新建的状态直接更新到对应的学生上就可以。
