数据库原理及应用课程设计告学生会管理系统Word文档格式.docx
- 文档编号:19691381
- 上传时间:2023-01-08
- 格式:DOCX
- 页数:41
- 大小:562.97KB
数据库原理及应用课程设计告学生会管理系统Word文档格式.docx
《数据库原理及应用课程设计告学生会管理系统Word文档格式.docx》由会员分享,可在线阅读,更多相关《数据库原理及应用课程设计告学生会管理系统Word文档格式.docx(41页珍藏版)》请在冰豆网上搜索。
第三章数据库设计
3.1、需求分析
需求分析的目标及任务就是为了提取有效的信息,概念模型抽象化,转化为计算机系统能够识别的信息,通过需求分析所得的信息如下:
(1)处理对象
学生干部信息:
编号、姓名、性别,专业,电话,职务,部门,参加过的活动
部门信息:
名称、编号、副部人数,部里人数,部长电话
物品信息:
编号、名称、金额,借出时间,归还时间,借物人姓名
财务信息:
财务申请编号,用途,申请金额,申请人姓名,申请部门,申请时间,余额
活动信息:
部门活动名称,承办部门,活动职能范围
文件信息:
名称、编号、存档日期、收发对象,备注,所属部门
(2)安全性和完整性要求
安全性先通过视图机制,不同的用户只能访问系统授权的视图,这样可提供系统数据一定程度上的安全性,再通过用户授权机制,通过用户登陆来识别用户级别,根据这个级别来分配用户权限,达到数据更高层次的安全保密功能。
近而可以满足用户的基本数据安全性要求。
完整性要求用于描述各种信息之间的制约关系,以及关联关系,各个数据项的取值范围以及各个数据项是否可以不取值。
根据实际需要,采取一定的手段来满足用户的完整性需求。
详细完整性要求见于系统的逻辑设计阶段。
3.1.1数据流图
(1)顶层数据流图如下:
(2)学生基本信息流图如下:
(3)部门信息流图如下:
(4)财务信息流图如下:
(5)部门文件信息流图如下:
已批准的活动
工作
3.1.2数据字典
(1)数据项:
A
编号
数据项名
数据项含义
类型
宽度
与其他数据项关系
备注
A1
Stu_no
学生干部编号
数值型
9个字节
A2
Stu_name
学生干部姓名
字符型
6个字符
A3
Stu_position
学生干部职务
4个字符
A4
S_Depart_name
干部所属部门
14个字符
=Dep_name
A5
Stu_case
参加过的活动
20个字符
A6
Good_no
物品编号
A7
Good_name
物品名称
A8
Good_price
金额
A9
Good_Lender
借物人姓名
A10
Lend_time
借出时间
日期型
12个字符
A11
Ret_time
归还时间
A12
Fin_no
财务申请编号
4个字节
A13
Fin_purpose
用途
A14
Fin_Money
申请金额
A15
Fin_name
申请人姓名
A16
Fin_depart
申请部门
A17
Fin_time
申请时间
8个字符
A18
Fin_remain
余额
A19
Act_name
事务活动名称
10个字符
A20
Act_department
主承办部门
A21
Act_range
活动职能范围
A22
File_no
文件编号
8个字节
A23
File_name
文件名称
A24
filebeldep
所属部门
A25
fileperson
负责人
A26
RecDisPartner
收发对象
A27
ArcDate
存档日期
A28
Dep_name
部门名称
A29
Dep_no
部门编号
A30
Depmin_Name
部长姓名
=Stu_name
A31
Fubuzhangsum
副部长人数
A32
DepMemSum
部委人数
A33
Depmin_pho
部长电话
A34
solution
以往解决方案
30个字符
A35
Stu_sex
学生干部性别
A36
Stu_phone
学生干部电话
A37
Stu_pro
学生干部专业
7个字符
A38
Ret_name
归还人姓名
6字符
(2)数据结构DS
名称
组成
DS1
学生干部信息
A1+A2+A3+A4+A5+A35+A36
DS2
物品信息
A6+A7+A8
DS3
财务信息
A9+A10+A11+A12+A13+A14+A15+A16+A17+A18
DS4
日常事务活动信息
A19+A20+A21+A34
DS5
文件信息
A22+A23+A24+A25+A26+A27
DS6
部门信息
A28+A29+A30+A31+A32+A33
DS7
工作计划信息
(3)数据流F
来源
去向
F1
借还财务申请表
S1
P1
F2
未批准财务申请表
F3
已批准财务申请表
P2
F4
候选人名单
P3
F5
上下级文件
P4
F6
审核通过文件
S2
(4)数据处理P
输入
处理
输出
财务审批处理
登记财务情况
登记财务信息处理
审查资金与物品的流动
D1
选举处理
选举信息名单
D2
审批处理
文件审批
(5)数据存储D
关键字
财务登记表
DS1+A1+A2+A3+A4+A5
表现情况
DS3+A9+A10+A11+A12+A13
+A14+A15+A16+A17+A18
3.2、概念结构设计
概念结构设计的目的是获取数据库的概念模型,将现实世界的用户需求转化为概念模型。
概念模型是现实世界到机器世界的中间层,是数据模型的基础。
概念模型独立于机器,比素具模型更加抽象,更稳定。
概念模型是现实世界到信息世界的第一层抽象,是数据库设计的工具,也是数据库设计人员和用户进行交流的语言。
它主要有如下特点:
反映现实、易于理解、易于修改、易于转换。
3.2.1局部E-R图
1、实体及其属性
学生干部属性图
部门属性
物品属性
财务属性
文件属性
事务活动属性
活动参与属性
活动使用物品属性
2、局部E-R图
(1)
N1
学生会干部信息管理分图
(2)借物品管理分图
NM
(3)部门举办活动管理分图
(2)财务申请管理分图
(4)文件管理分图
3.2.2全局E-R图
合并各分E-R图,消除各类冲突,得到初步E-R图,再消除不必要冗余,得到的基本E-R图。
具体实现如下:
a.消除冲突
合并分E-R图时并不能简单地将各个分E-R图画到一起,而是必须着力消除各个分E-R图中的不一致,以形成一个能为全系统中所有的用户共同理解和接受的统一的概念模型。
合并分E-R图的主要工作与关键是合理消除各分E-R图的冲突,冲突主要有三类:
属性冲突、命名冲突和结构冲突。
b.消除冗余
在E-R
图中,可能存在一些冗余的数据和实体间的联系。
冗余数据和冗余联系容易破坏数据库的完整性,给数据库的维护增加困难,应予以消除。
但并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。
消除冗余主要采用分析法和规范化理论。
解释如下:
一个部门可以承办多个事务活动,而一个事务活动只能由一个部门去承办;
一个部门可以包括多个学生会干部,而一个学生会干部只能隶属于一个部门;
一个学生会干部可以参与多项事务活动,而一个事务活动也可以有多个学生干部参与;
一个学生会干部可以提交多份财务申请,而一份财务只能由一个学生会干部申请;
一个学生会干部可以制定多份文件,而一份文件只能由一个学生会干部制定;
一个学生会干部可以提交多份工作计划,而一份工作计划只能由一个学生会干部提交;
一份财务申请的资金可以购买多种物品,而一种物品只能由一次财务申请的资金来购买;
一次事务活动需借用多种物品,而一种物品一次只能被一项事务活动所借用;
一份工作计划可以包括多项事务活动,而一项事务活动只能有一份工作计划中制定。
2.3.新系统流程图
3.3、逻辑结构设计
3.3.1逻辑结构设计的目的
以上的概念设计阶段是独立于任何一种数据模型的,但是逻辑设计阶段就与选用的DBMS产品发生关系了,系统逻辑设计的目标就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。
3.3.2逻辑结构设计的任务:
1.数据组织
(1)实体型转换为关系模式
一个实体型转换为一个关系模式。
实体的属性就是关系的属性,实体的码就是关系的码。
学生会干部(编号,姓名,性别,职务,部门,专业,年级,电话,参加过的活动项目)
物品(编号,名称,金额,借出时间,借物人姓名,归还时间,归还人姓名)
财务(财务申请编号,资金用途,申请金额,申请人,申请部门,申请时间,余额)
工作计划(编号,名称,提交部门编号,提交人,提交时间,是否紧急活动)
事务活动(名称,职能范围,承办部门,以往解决方案)
部门(部门编号,部门名称,部长编号,副部长人数,部委人数,部长电话)
文件(编号,名称,类型,所属部门,负责人,收发对象,存档日期,备注)
(2)实体间联系转换为关系模式
逻辑结构设计的任务是将概念结构设计阶段设计的E-R图,转化为选用的DBMS所支持的数据模型相符的逻辑结构,形成逻辑模型。
概念模型向关系数据模型的转化就是将用E-R图表示的实体、实体属性、和实体联系转化为关系模式,转化规则为:
(1)、一个实体转换为一个表,则实体的属性转换为表的列,实体的码转换为表的主键。
(2)、实体间的联系根据联系的类型转换为:
1:
n的联系、1:
1的联系、m:
n的联系。
表:
学生会干部(编号,姓名,职务,性别,专业,电话,部门名称,参加过的活动);
部门(编号,部门名称,部长姓名,副部人数,部里人数,部长电话);
事务活动(部门活动名称,活动职能范围,承办部门,以往解决方案,);
活动参与(事务活动名称,学生会干部姓名,出勤情况)
活动使用物品(部门活动名称,物品名称,使用数量)
物品(编号,财务申请编号,名称,金额,借出时间,借物人姓名,归还时间,归还人姓名);
财务(财务申请编号,资金用途,申请金额,申请人姓名,申请部门,申请时间,余额);
文件(文件编号,文件名称,所属部门,制定人名称,负责人,存档日期,备注);
(3)模型优化
以上关系模式不存在非主属性对主属性的部门函数依赖,也不存在传递函数依赖,已经达到了3NF,所以已经达到建表要求。
(4)据库模式定义
经分析后,该数据库共创建8表,如下所示:
学生会干部信息表3-1
列名
数据类型
可否为空
码
说明
Char(9)
否
学生编号
Char(6)
主码
学生姓名
Char(4)
学生职位
S_depart_name
外码
所在部门
Char(20)
Null
参加的活动
Char(12)
电话
Char(5)
专业
Char(8)
性别
部门信息表3-2
Char(14)
Buzhang_name
Fubusum
Int
Busum
Buzhang_pho
部长电话号码
事务活动信息表3-3
部门活动名称
Act_departmentno
承办部门
Char(30)
以往的解决方法
活动参与表3-4
Char(10)
举办的活动名称
参与学生干部
present
出勤情况
活动使用物品信息表3-5
usesum
int
Null
使用数量
物品信息表3-6
Money
Date
Good_lender
财务信息表3-7
资金用途
Fin_money
Int
Apply_name
Apply_depart
Apply_time
学生文件信息表3-8
文件编号
File_bel_depart
File_person
Notnull
负责人名称
Recdispartner
acrdate
Date(12)
remark
null
(5)用户子模式定义,如表所示
用户子模式(view)
作用
V_1
Stuview
查询和修改学生会干部的基本信息
V_2
Depview
查询和修改各部门的信息
V_3
Goodview
查看物品信息
V_4
Finview
查看财务信息
V_5
Actview
查看部门活动信息
V_6
Fileview
查看存档文件的基本信息
V_7
Act_good_view
查询活动时借的物品信息
V_8
Workplan_view
查看
学生信息表的视图
姓名
学生性别
学生的专业
职位
学生的部门
部门
学生的职位
部门信息表的视图
部门名字
部门号
部长
活动时借的物品信息视图
活动名称
借物人
活动费用的视图:
NotNull
部门举办过的活动信息的视图:
参与人员
存档文件的基本信息视图
文件所属部门
文件负责人
date
3.4、物理结构设计
3.4.1存储结构与存取方法
1、由于基本表student、department、good、files的主码stu_name、dep_name、good_no、file_no经常在查询条件和链接操作的条件中出现,且它们的值唯一,在两个属性上建立唯一索引;
2、由于基本表usegood的属性act_name、good_name经常在查询条件中出现,所以在两个属性上建立组合索引;
3、申请财务信息基本表finance的属性fin_no、apply_name经常在查询条件中出现,在两个属性上建立组合索引;
3.4.2数据的易变与稳定部分
3.4.3建立数据库、表建立的代码
⑴建立数据库
createdatabasewarehouse;
⑵建立数据表
①学生信息表建立如下:
usewarehouse;
createtablestudent(
stu_nochar(9)notnull,
stu_namechar(6)primarykey,
stu_positionchar(4)notnull,
s_depart_name
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 原理 应用 课程设计 学生会 管理 系统