学生选课系统数据库课程设计论文文档格式.docx
《学生选课系统数据库课程设计论文文档格式.docx》由会员分享，可在线阅读，更多相关《学生选课系统数据库课程设计论文文档格式.docx（31页珍藏版）》请在冰豆网上搜索。
该系统所创建的五个数据流图如下图1-3至图1-7所示：
顶层数据流图：
一层数据流图：
二层选课数据流图：
二层排课数据流图：
二层开课据流图：
1.2.3数据字典的建立
数据字典是建立数据库的数据基础，是经过多方面的数据采集、数据筛选分析所得，是系统开发的重要步骤，在数据库设计中占据着非常重要的地位。
常见的数据字典由数据项、数据结构、数据流、外部实体、数据存储及处理过程等组成。
由于时间关系，本系统只列出了数据项和数据结构。
详细数据项、数据结构见附录1表1-1和表1-2。
2．数据库结构设计
2.1概念设计
概念设计是将需求分析得到的用户需求抽象为概念模型的过程，这个阶段主要的目标是通过对用户需求进行综合、归纳与抽象，形成一个独立于DBMS的概念模型（E-R图）。
对这个阶段的要求有：
（1）能真实、充分地反映现实世界，包括事物与事物之间的联系，能满足用户对数据的处理要求，是对现实世界的一个真实模型；
（2）易于理解，因此可以用它和不熟悉计算机的用户交换意见；
（3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充；
（4）易于向关系、网状、层次等各种数据模型转换。
实现概念设计的任务和方法：
（1）设计分E-R图，生成初步E-R图；
（2）通过合并等方法，消除冲突、冗余等，生成全局E-R图。
2.1.1分E-R图建立
分E-R图就是全局概念模式下的底层概念模式向E-R图的转化。
先从用户全局需求出发，逐曾细化得到底层需求，把每个底层需求转换为一个概念模式，再逐层合成概念模式得到全局概念模式。
每个底层概念模式都要转化为分E-R图。
设计分E-R图的思想是，以中层数据流为切入点，利用抽象机制对需求分析阶段收集到的数据进行分类、聚集、概括，形成实体、实体的属性、标识实体的码、确定实体之间的联系类型（1:
1,1:
n,m:
n），再逐一设计分E-R图。
为学生选课系统所创建的实体及其属性图和两个分E-R图如下图2-1至图2-3所示：
实体及其属性E-R图：
选课E-R图：
排课E-R图：
2.1.2全局/整体E-R图
由分E-R图到全局E-R图的过程就是视图集成的过程，一般来说有两种方式：
（1）多个分E-R图一次集成，难度较大；
（2）逐步集成，用累加的方式一次集成两个分E-R图，可以降低复杂度。
无论采用哪种方式，每次集成局部E-R图时都需要分两步走：
（1）合并；
（2）修改和重构。
在合并分E-R图时，主要是为消除各分E-R图之间的冲突，包括属性冲突、命名冲突、结构冲突。
在消除属性冲突时，需要调整属性域和属性的取值单位；
消除命名冲突，主要是为预防同名异义或异名同义的情况；
结构冲突包括的比较多，每种都有自己的解决方法，主要有：
（1）同一对象在不同应用中具有不同的抽象，解决时通常是把属性变换为实体或把实体转换为属性，使同一对象具有相同的抽象；
（2）同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同，可以通过取该实体属性为各分E-R图中属性的并集，再适当调整属性的次序；
（3）实体间的联系在不同的分E-R图中为不同的类型，可以根据应用的语义对实体联系的类型进行综合或调整。
修改或重构主要是为消除不必要的冗余。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余；
此外也可以用规范化理论来消除冗余。
当然，并非所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，也会不得不以冗余信息作为代价，这个需要根据用户的整体需求来确定。
在合并和修改或重构之后，学生选课系统的全局E-R图如图2-4所示：
全局E-R图：
说明：
一个学生可以选修多门课程，一门课程可以被多名同学选修；
一个教师只可以担任一门课程，一门课程可以有多名教师担任；
一个教室可以供不同的课程使用，一门课程可以使用不同的教室；
一个学院可以包含过个专业，一个专业只属于一个学院；
一个管理员可以排多门课程，一门课程只能由一名管理员排设；
2.2逻辑设计
逻辑设计就是把概念设计阶段的基本E-R图转换为所用DBMS产品支持的数据模型。
本系统中是将概念设计所得到的E-R图转换为关系数据模型。
实现逻辑设计的任务和方法：
（1）将E-R模型转换为关系模型，明确关系模式的属性和码；
（2）利用规范化理论对现有数据模型进行优化；
（3）完成数据库模式定义，包括各模式的逻辑结构定义、关系的完整性和安全性等内容；
（4）完成用户子模式的设计。
2.2.1建立关系模式
将E-R模型转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。
转换一般遵循以下原则：
一个实体型转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
实体间的联系的转化情况：
一个1：
1联系可以转换为一个独立的关系，也可以与任意一段对应的关系模式合并；
n联系可以转化为一个独立的关系模式，也可以与n端的关系模式合并；
一个m：
n的联系必须转化为一个关系模式。
学生、教师、教务管理员、课程、教室、教学楼、学院、专业、选课时间段，这些都需要转换为关系模式。
转换结果：
学生（学号，姓名，年龄，性别，所在学院名称，所在专业，所在年级）
教师（教工号，姓名，年龄，性别，所属学院名称，研究方向）
教务管理员（编号，姓名，性别，年龄，主要负责业务）
教室（教室编号，所属教学楼编号，最大容纳学生人数，性质）
教学楼（编号，名称，拥有的教室数量，性质）
课程（编号，名称，学分，最大选课人数，性质，开课学院，面向的专业，面向的年级，起始上课周次，截止上课周次，上课时间）
学院（编号，名称，拥有专业数量，拥有学生数量，性质）
专业（编号，名称，性质，拥有的学生数量）
选课时间段（起始选课时间，截止选课时间）
完全函数依赖F：
学号—>
姓名学号—>
所在学院
所在年级学号—>
性别
教工号—>
姓名教工号—>
年龄
所在学院课程编号—>
课程名称
课程编号—>
最大选课人数课程编号—>
课程学分
管理员编号—>
姓名管理员编号—>
主要负责的业务
教室编号—>
所在教学楼教室编号—>
教室性质
最大容纳人数专业编号—>
所在学院名称
专业编号—>
专业名称学院编号—>
学院名称
等等，每个关系的属性均依赖于它的主属性。
2.2.2关系模式规范化处理
根据F可知：
学生（学号，姓名，年龄，性别，所在学院名称，所在专业，所在年级）满足3NF
教师（教工号，姓名，年龄，性别，所属学院名称，研究方向）满足3NF
教务管理员（编号，姓名，性别，年龄，主要负责业务）满足3NF
教室（教室编号，所属教学楼编号，最大容纳学生人数，性质）满足3NF
教学楼（编号，名称，拥有的教室数量，性质）满足3NF
课程（编号，名称，学分，最大选课人数，性质，开课学院，面向的专业，面向的年级，起始上课周次，截止上课周次，上课时间）满足3NF
学院（编号，名称，拥有专业数量，拥有学生数量，性质）满足3NF
专业（编号，名称，性质，拥有的学生数量）满足3NF
选课时间段（起始选课时间，截止选课时间）满足3NF
2.2.3用户子模式建立
目前关系数据库管理系统一般都提供了视图概念，可以利用这一功能来设计更符合局部用户需要的用户子模式。
考虑到用户的习惯与方便，设计了如下视图：
（1）为学生建立视图：
便于查询详细的课程及上课情况
选课信息（学号，姓名，课程号，课程名称，课程性质，教工号，教师姓名，开课学院名称，课程学分，实际上课总人数，上课时间等）
（2）为教务管理员建立视图：
便于查询学生、课程等情况
排课信息（课程编号，课程名称，学号，姓名，教学楼等）
具体用户子模式定义如下表：
表2-1（学生选课系统）关系外模式
序号
视图名称
作用
属 性
V－1
SC
学生查询选课信息
学号，姓名，课程号，课程名称，课程性质，教工号，教师姓名，开课学院名称，课程学分，实际上课总人数，上课时间等
V－2
PK
管理员查询排课信息
课程编号，课程名称，学号，姓名，教学楼等
2.2.4关系模式逻辑结构定义
根据关系模式的转换原则，该冷饮批发系统可以抽象为十一个关系模式。
在定义关系模式时，有关系模式的逻辑结构定义、关系的完整性和安全性等内容。
其中关系模式的逻辑结构定义包括关系模式各属性的确定、码的确定、外码的确定、各属性的约束等等。
具体关系模式的逻辑结构如下表：
表2-2（学生选课系统）关系模式汇总
关系名称
含 义
模式说明
S
学生
（详见附录2表2－3）
T
教师
（详见附录2表2－4）
MA
教务管理员
（详见附录2表2－5）
C
课程
（详见附录2表2－6）
CL
教室
（详见附录2表2－7）
BU
教学楼
（详见附录2表2－8）
AC
学院
（详见附录2表2－9）
DE
专业
（详见附录2表2－10）
CT
选课时间段
（详见附录2表2－11）
3．数据库物理设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
通常关系数据库物理设计的内容主要包括：
（1）为关系模式选择存取方法；
（2）设计关系、索引等数据库文件的物理存储结构。
4．数据库实施与测试
在完成数据库的物理设计之后，就要用RDBMS提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为DBMS可以接受的源代码，再经过调试产生目标模式。
然后组织数据入库，这就是数据库的实施阶段。
在实施阶段完成之后，就要对数据库系统进行预定目标的测试。
在测试期间，要考虑到数据库的安全性与完整性控制，还要对数据库性能进行监督、分析和改造。
这一切工作都要不断进行，直到测试达到预定目标。
4.1数据库实施
4.1.1数据库及数据库对象建立
此学生选课系统数据库及数据库对象的建立包括创建数据库、创建基本表、创建视图、创建触发器、创建存储过程等，具体的DDL语句及相关代码详见附录3。
4.1.2数据入库
数据入库过程就是数据录入的过程。
在SQL中，可以用EXCEL批量导入的方法录入，也可以逐条录入。
4.2数据库测试
数据库测试是数据库设计必不可少的阶段，它是对整个数据库设计合不合格的检验，也是判定此数据库设计是否达到目标的标准。
详细图片见附录4。
5．总结
两周的数据库课程设计结束了，经过紧张的两周训练，基本上完成了任务。
任务很多，量也很大，而且一步紧扣一步，只要是前面哪个部分有问题，后面再做的时候就会遇到各种问题。
让我感触最深的就是需求分析这部分，以前上课的时候老师就强调过这部分内容的重要性，他直接关系到整个系统的功能、状态等等，如果做不好，就会出现系统在实施运行时的各种问题，甚至会是一个错误的系统。
当时可能没有意识到这点，真正在做的时候才深有体会。
由于前面需求分析时间紧张，加之我们没有亲身调查的机会，可能对某些业务了解的并不是很清楚，对每一部分的具体要求可能没有掌握到位。
画业务流图、数据流图、生成数据字典等，这每一步都是极其重要和关键的。
后面再做各种结构时，每次总是会不同程度的发现部分需求分析阶段的问题，然后就要修改，然而，修改也不是每次都行得通。
在一次一次的反复修改业务流图、数据流图、数据项的过程中，逐渐深刻的体会到需求分析的重要性。
数据库的课程实习做完了，可是一留下了许多的问题等待我们解决，比如说这次课程设计中用到的存储过程和触发器，怎么用它，怎么更高效的用它等等一系列的问题就需要我们在课后自己查资料、自己实践、自己总结。
对于自己已经做的这个系统，需要回过头来再仔细思考一遍，对自己在做的时候所遇到的问题、困惑回头想想、总结、思考，真正做到从中收获知识、收货方法、收获思想。
附录
附录1
表1-1学生选课系统数据项表
数据项编号
数据项名称
数据项含义
与其他数据项的关系
类型和长度
取值范围
DI-1
Stu_No
学生学号
varchar（15）
DI-2
Stu_Name
学生姓名
varchar（20）
DI-3
Stu_Sex
学生性别
char（3）
“男”or“女”
DI-4
Stu_Age
学生年龄
smallint
15-35
DI-5
Stu_AcadName
学生所在学院名称
DI-6
Stu_DeptName
学生所属专业名称
DI-7
Stu_Grade
学生所属年级
varchar（10）
DI-8
Tea_No
教师教工号
DI-9
Tea_Name
教师姓名
DI-10
Tea_AcadName
教师所在学院名称
DI-11
Tea_Sex
教师性别
DI-12
Tea_Age
教师年龄
24-65
DI-13
Tea_Tend
教师研究方向
DI-14
Cou_No
课程编号
DI-15
Cou_Name
DI-16
Cou_Xzh
课程性质
DI-17
Cou_AcadName
开课学院名称
DI-18
Cou_DeptName
课程面向的专业名称
DI-19
Cou_Grade
课程面向的年级
DI-20
Cou_MaxStu
课程最大选课人数
DI-21
Cou_Credit
课程学分数
DI-22
Cla_No
教室编号
DI-23
Cla_Xzh
DI-24
Cla_BuildNo
教室所在教学楼编号
DI-25
Cla_MaxStu
教室最大容纳学生人数
DI-26
Cla_Sweek
上课启始周次
DI-27
Cla_Eweek
上课截止周次
DI-28
Cla_Time
上课时间
date
DI-29
Stu_TotalNo
课程实际总人数
DI-30
Manag_No
教务管理员编号
DI-31
Manag_Name
教务管理员姓名
DI-32
Manag_Sex
教务管理员性别
DI-33
Manag_Age
教务管理员年龄
DI-34
Manag_Part
教务管理员所管业务
DI-35
Build_No
教学楼编号
DI-36
Build_Name
教学楼名称
DI-37
Build_Xzh
教学楼性质
DI-38
Build_ClaNo
教学楼拥有的教室数量
DI-39
Acad_No
学院编号
DI-40
Acad_Name
DI-41
Acad_DeptNo
学院拥有的专业数量
DI-42
Acad_StuNo
学院拥有的学生数
smllint
DI-43
Acad_Xzh
学院性质
DI-44
Dept_No
专业编号
DI-45
Dept_Name
专业名称
DI-46
Dept_AcadName
专业所在学院名称
DI-47
Dept_Xzh
专业性质
DI-48
Dept_StuNo
专业拥有学生数量
DI-49
Choose_Stime
开始选课时间
DI-50
Choose_ETime
截止选课时间
表1-2学生选课系统数据结构表
数据结构编号
数据结构名
数据结构含义
组成
DS-1
Student
学生
Stu_No、Stu_Name、Stu_AgeStu_AcadNameStu_Grade等
DS-2
Teacher
教师
Tea_No、Tea_Name、Tea_Sex、Tea_AcadName、Tea_Tend等
DS-3
Manage
教务管理员
Manag_No、Manag_Name、Manag_Part等
DS-4
Class
教室
Cla_No、Cla_Xzh、Cla_BuildNo、Cla_MaxStu等
DS-5
Building
教学楼
Build_No、Build_Name、Build_ClaNo、Build_Xzh等
DS-6
Course
课程
Cou_No、Cou_Name、Cou_Credit、Cou_MaxStu、Cou_Xzh、Cou_AcadName等
DS-7
Acad
学院
Acad_No、Acad_Name、Acad_DepNo、Acad_Xzh、Acad_StuNo等
附录2
表2-3学生信息表
属性名
数据类型
是否为主属性
是否为外键
完整性要求
是
否
NotNull
表2-4教师信息表
表2-5教务管理员信息表
25-55
Manag_Pa
升级会员 