第一节 需求描述与分析
模拟案例：高校学分制改革得到全面普及，学生可以根据专业培养计划自主选择所修课程。且越来越多的高校开设了个性化的选修课程。需要一个信息化程序较高的在线选课系统。
据此给出一个简化的需求分析：
一 功能性需求
经调研，得知选课系统用户类型有：教务管理员、学生和教师。因此，可将系统的功能依据用户类型进行模块化划分。
1 管理员后台模块
主要用户系统的数据管理；包括学生管理、教师管理、班级管理和课程管理；其具有的功能需求如下：
（1）学生信息管理
学生信息发生变化时。
（2）教师信息管理
教师信息发生变化时。
（3）课程信息管理
课程及安发生变化时。
（4）班级管理
班级及成员信息发生变化时。
2 学生使用模块
使用学号及密码登录系统，然后浏览课程并选课。主要功能如下：
（1）查阅课程
（2）浏览课程
（3）查询成绩：本人所选课程的成绩查询。
3 教师使用模块
使用工号及密码登录系统，进程登分及查询本人开设的课程。主要功能如下：
（1）我的课程
（2）登分
二 非功能性需求
使用B/S结构（在线）；客户端使用IE；服务器使用WAMP；需要8GB内存，2TB磁盘空间，1000MB网卡等资源。
质量需求的描述：
质量需求名称 | 详细要求 |
可靠性 | 每月做多一次由外界因素导致的故障，选课期间保证系统正常运行。（这也可以保证？离谱，保证自己的问题还差不多！！） |
正确性 | DB中Data正确和各功能模块的业务逻辑正确。 |
兼容性 | 可以在IE内核兼容的任一浏览器上使用。 |
健壮性 | 要经常进行健壮性测试，不断加强对非格式化操作的应变能力。 |
第二节 系统设计
自顶向下的功能结构图。
一 功能模块设计
1 登录验证模块
验证身份信息，通过后才可进入系统。
2 管理员后台模块
教务管理员对系统数据日常维护
3 学生使用模块
学生自主选课，查询、退选以及考试后查成绩。
4 教师使用模块
查询自己开设的课程，以及每门课程的上课时间及地点等信息；还可以对课程考试后进行登分。
二 数据库设计
根据功能模块设计结果以及前期的需求分析，可①首先确定本系统的数据库范围；②然后通过E-R图为工具进行概念设计的描述，③建立本系统涉及的局部信息结构，④将局部信息结构合并成一个优化的全局信息结构；⑤最后将全局信息结构的E-R图转化为关系模型，并依据关系数据库规范化理论进行优化。
需求分析模块设计
E-R图描述的概念设计
局部信息结构
全局信息结构
关系模型
规范化的关系模型
1 确定实体
学生、教师、课程、院系、班级、系统管理员；它们包含的属性信息设计如下：
①学生：学号，姓名 ，性别，密码
②教师：教师工号，姓名，性别，年龄，职称，密码
③课程：课程编号，课程名称，学分，时间，地点，类别，开课学院，限选人数
④院系：院系名称，办公地点，教师人数
⑤系统管理员：ID，姓名，密码，邮箱，手机号码
2 局部信息结构
实体之间存在的相互联系可由如下几个E-R图描述的局部信息结构来表示。
①学生-课程的E-R图；联系命名为"选修"是M:N的关系。
②教师-课程的E-R图；联系命名为"授课"是1:N的关系。
③教师-院系的E-R图；联系命名为"属于"是N:1的关系。
④学生-院系的E-R图；联系命名为"属于"是N:1的关系。
⑤系统管理员-学生的E-R图；联系命名为"管理"是M:N的关系。
⑥系统管理员-教师的E-R图；联系命名为"管理"是M:N的关系。
⑦系统管理员-课程的E-R图；联系命名为"管理"是M:N的关系。
⑧系统管理员-院系的E-R图；联系命名为"管理"是M:N的关系。
3 全局信息结构
逐步合并，进行累加的方式。逐步消除①属性冲突②命名冲突③结构冲突
（1）将学生-课程E-R图、教师-课程E-R图、教师-院系E-R图和学生-院系E-R图合并。
注意：教师-院系E-R图和学生-院系E-R图中均具有名为"属于"的联系，但它们的含义不同，因此，将它们分别重命名为"任职"和"从属"；最终得到下图：
（2）再将系统管理员合并进来
与系统管理员相关的4个关系名均为"管理"；但含义均不相同，因此，需要分别改名。
另外并入系统管理员后，教师和学生都需要补齐各自实体中的"密码"属性。
（3）补齐图中的全部关系和属性后得到最终的全局结构信息的E-R图
4 逻辑结构与规范化设计
全局信息结构E-R图转化为关系模型（式）。
- 每个实体转化为1个独立的关系；
- 【习惯上】1:N的关系将合并到N的一方（当然合并的1的一方亦可）；
- 每个M:N的关系独立成一个独立的关系，且码是两端码的组合。
依据第三章第三节中的"逻辑结构设计方法"
①学生(学号，姓名，性别，密码，院系编号) # 院系编号为1:N关系合并而来。
②院系(院系编号，院系名称，学生人数，教师人数，办公地点) #实际工作中多出来的属性应再次之前识别出
③教师(教师工号，姓名，性别，年龄，职称，密码，院系编号) # 院系编号为1:N关系合并而来。
④课程(课程编号，课程名称，课程类别，学分，上课时间，上课地点，开课学院，限选人数，教师工号) # 教师工号为1:N关系合并而来。
⑤系统管理员(管理员ID，姓名，密码吗，邮箱，手机号码)
⑥选修(学号，课程编号，成绩) #由M:N关系独立而来
⑦管理学生(管理员ID，学号，操作时间) #由M:N关系独立而来，实际工作中多出来的属性应再次之前识别出
⑧管理教师(管理员ID，教师工号，操作时间) #由M:N关系独立而来，实际工作中多出来的属性应再次之前识别出
⑨管理院系(管理员ID，院系编号，操作时间) #由M:N关系独立而来，实际工作中多出来的属性应再次之前识别出
⑩管理课程(管理员ID，课程编号，操作时间) #由M:N关系独立而来，实际工作中多出来的属性应再次之前识别出
然后，进一步分析各关系模式是否满足目标范式（书中以3NF为目标）；若不满足目标范式则进行分解，直到满足目标范式为主；从而实现规范化。
以本案例为研究对象，可知其中8个关系模型既不包含部分函数依赖，又不包含传递函数依赖，则它们满足第三范式。
"课程"和"院系"关系模型中没有部分函数依赖，满足2NF；但是含有传递函数依赖，因此，不满足3NF；需要对其进行分解。
比如：以课程关系为例，a.由课程编号可知课程名称，b.但是由课程名称不能推出课程编号(课程会重名)，c.由课程名称可知其他字段信息；这就是传递依赖。
经分解后得：
院系编码(院系编号，院系名称)
院系(院系编号，学生人数，教师人数，办公地点)
课程(课程编号，课程名称)
课程(课程编号，课程类别，学分，上课时间，上课地点，开课学院，限选人数，教师工号)
第三节 系统实现
1 DB实现
①创建DB
CREATE DATABASE db_xuanke;②创建表
以学生表为例：
编号 | 字段名 | 数据类型 | 默认值 | 可否为空 | 说明 |
1 | StuNo | INT(8) | 无 | NOT NULL | 学号(主键) |
2 | StuName | VARCHAR(10) | 无 | NOT NULL | 姓名 |
3 | StuSex | CHAR(1) | 无 | 性别 | |
4 | Pwd | VARCHAR(8) | 无 | NOT NULL | 密码 |
5 | DeptNo | INT(8) | 无 | NOT NULL | 所属院系(外键) |
1、char类型：char类型存储的时候是初始预计字符串再加上一个记录字符串长度的字节，占用空间较大。 2、varchar类型：varchar类型存储的时候是实际字符串再加上一个记录字符串长度的字节，占用空间较小。
2 系统功能实现
开展系统功能实现的编码工作；包括必要的DB行为和软件业务逻辑。
（1）实现DB行为
用SQL语句实现与本应用相关的增删查改等DB操作；
为提高效率和安全性创建各种DB对象；比如：子查询、视图、触发器、存储过程、存储函数等。
①安全控制
按设计分配权限：
GRANT SELECT,UPDATE,INSERT,DELETE ON db_xuanke.* TO 'jin'@'localhost';②管理学生
③DB保护
例如：分数应该是介于0到100的值
CREATE TRIGGER tri_test AFTER INSERT db_xuanke.electing
FOR EACH ROW
BEGIN
IF NEW.score < 0 and NEW.score > 100 THEN
DELETE FROM FROM db_xuanke.electing WHERE score = NEW.score
END IF
END;④事务与并发
批量录入信息使用事务
BEGIN
INSERT INTO db_xuanke.teacher VALUES(10001021,'张三',NULL,NULL,NULL,DEFAULT,10)
.
.
.
COMMIT;
END;⑤数据查询统计报表
生成统计报表是许多DB应用软件所提供的一项功能，可在数据库中通过定义视图实现：
CREATE VIEW v_score(StuNo, totlescore) AS
SELECT students.StuNo,sum(courses.Credit) From students
JOIN electing ON students.StuNo = electing.StuNo
JOIN courses ON courses.CourseNo = elexting.CourseNo
WHERE electing.Score >= 60
GROUP BY students.StuNo;（2）实现应用软件的业务逻辑
应用程序开发。
第四节 系统测试与维护
交付前进行必要的测试；并修改完善。
1 登录验证功能测试
测试方案：
编号 | 测试内容 | 测试结果 |
1 | 学生：输入正确的学号和密码，可以正常登录系统进入主页 | 通过 |
2 | 学生：输入错误的学号或密码，系统弹窗提示"输入的用户名或密码错误"，并拒绝进入主页。 | 通过 |
3 | ... | ... |
4 | ... | ... |
5 | ... | ... |
这只是一个简易的示例，实际上的测试方案要比这复杂详细的多得多得多..
2 管理员后台主要功能测试
（1）学生信息管理
（2）课程信息管理
（3）院系信息管理
（4）教师信息管理
