数据库原理及应用课程设计告学生会管理系统.docx

上传人:b****6 文档编号:6675072 上传时间:2023-01-08 格式:DOCX 页数:41 大小:562.97KB
下载 相关 举报
数据库原理及应用课程设计告学生会管理系统.docx_第1页
第1页 / 共41页
数据库原理及应用课程设计告学生会管理系统.docx_第2页
第2页 / 共41页
数据库原理及应用课程设计告学生会管理系统.docx_第3页
第3页 / 共41页
数据库原理及应用课程设计告学生会管理系统.docx_第4页
第4页 / 共41页
数据库原理及应用课程设计告学生会管理系统.docx_第5页
第5页 / 共41页
点击查看更多>>
下载资源
资源描述

数据库原理及应用课程设计告学生会管理系统.docx

《数据库原理及应用课程设计告学生会管理系统.docx》由会员分享,可在线阅读,更多相关《数据库原理及应用课程设计告学生会管理系统.docx(41页珍藏版)》请在冰豆网上搜索。

数据库原理及应用课程设计告学生会管理系统.docx

数据库原理及应用课程设计告学生会管理系统

《数据库原理及应用》课程设计告

课程名称:

《数据库原理及应用》课程设计

设计题目:

学生会管理系统

指导教师:

班级:

0814131

学号:

0814131xx

学生姓名:

xxx

成绩:

评语:

 

计算机科学与工程学院

2015年12月

第一章概述

1.1、选题的意义与背景

目前高校学生会已经成为学生组织中管理规模最高的组织。

在各高校内,学生会已经成为了学生和学校之间的桥梁作用,成为老师们的得力助手但是随着信息技术和计算机技术的发展,学生会也需要用这种技术发展来壮大自身的发展,提高办事效率,减少学生会人员的压力。

经过了解调查,高校学生会管理系统主要实现对学生会的科学化、条理化、信息化、高效化管理。

其中包括学生会干部信息、财产物品的使用以及登记,日常事务管理和文件信息管理等四大功能。

1.2、主要功能模块

第二章系统功能设计

2.1、系统总体结构设计图

2.2、系统功能模块

2.2.1模块1学生会干部信息处理

学生会人员信息查询:

主要完成干部信息的查询与更新,从而实现对学生会干部信息的科学化管理。

主要包括学生会人员的姓名,性别,专业,在学生会中的职位,参加过的活动,电话号码。

2.2.1模块2学生会部门信息处理

学生会部门管理:

主要是各部门动态的查询及更新,从而方便老师及时掌握各部门的动态,让各部门了解各自的工作活动。

包括学生会的各个部门(组织部,学习部,卫生部,信息管理部,多媒体部,女生部,文艺部等),以及各个部门的人数,部长,副部长人数等。

2.2.3模块3部门活动处理

部门举办的活动管理:

进行部门活动举办的查询和更新。

可供全院学生及时了解院系所举办的活动,并参与。

主要有举办活动的名称,内容,举办活动的部门,以及活动要求。

2.2.4模块4财务信息模块

学生会财务管理:

包括财产和物品的管理,完成对财产物品信息的查询与更新,如举办活动所需的资金申请、物品使用的登记、物品借还的登记等,从而实现学生会财务的信息化管理。

记录信息有财务状况,申请财务的编号,金额,申请人,申请时间,归还人,归还时间,申请财务的用途等。

2.2.5模块5文件信息模块

学生会批准的文件管理:

完成对学生会所有存档文件的查询与更新,实现对学生会日常的工作文件的科学化管理,从而确保各项工作顺利开展,使学生会的工作更富有条理化,避免一些重复文件的制定,造成资源的浪费。

包括被批准文件的名称,文件来源部门等。

 

第三章数据库设计

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

物品编号

数值型

4个字符

A7

Good_name

物品名称

字符型

6个字符

A8

Good_price

金额

数值型

A9

Good_Lender

借物人姓名

字符型

6个字符

A10

Lend_time

借出时间

日期型

12个字符

A11

Ret_time

归还时间

日期型

12个字符

A12

Fin_no

财务申请编号

数值型

4个字节

A13

Fin_purpose

用途

字符型

20个字符

A14

Fin_Money

申请金额

数值型

A15

Fin_name

申请人姓名

字符型

6个字符

A16

Fin_depart

申请部门

字符型

6个字符

A17

Fin_time

申请时间

日期型

8个字符

A18

Fin_remain

余额

数值型

A19

Act_name

事务活动名称

字符型

10个字符

A20

Act_department

主承办部门

字符型

6个字符

=Dep_name

A21

Act_range

活动职能范围

字符型

20个字符

A22

File_no

文件编号

字符型

8个字节

A23

File_name

文件名称

字符型

10个字符

A24

filebeldep

所属部门

字符型

6个字符

A25

fileperson

负责人

字符型

6个字符

A26

RecDisPartner

收发对象

字符型

6个字符

A27

ArcDate

存档日期

日期型

6个字符

A28

Dep_name

部门名称

字符型

14个字符

A29

Dep_no

部门编号

字符型

8个字符

A30

Depmin_Name

部长姓名

字符型

8个字符

=Stu_name

A31

Fubuzhangsum

副部长人数

数值型

A32

DepMemSum

部委人数

数值型

A33

Depmin_pho

部长电话

字符型

20个字符

A34

solution

以往解决方案

字符型

30个字符

A35

Stu_sex

学生干部性别

字符型

8个字符

A36

Stu_phone

学生干部电话

字符型

12个字符

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

DS2

F2

未批准财务申请表

P1

S1

DS3

F3

已批准财务申请表

P1

P2

DS4

F4

候选人名单

S1

P3

DS1

F5

上下级文件

S1

P4

DS5

F6

审核通过文件

P4

S2

DS5

(4)数据处理P

编号

名称

输入

处理

输出

备注

P1

财务审批处理

F1

登记财务情况

F3

P2

登记财务信息处理

F3

审查资金与物品的流动

D1

P3

选举处理

F4

选举信息名单

D2

P4

审批处理

F5

文件审批

F6

(5)数据存储D

编号

名称

组成

关键字

D1

财务登记表

DS1+A1+A2+A3+A4+A5

A1

D2

表现情况

DS3+A9+A10+A11+A12+A13

+A14+A15+A16+A17+A18

A12

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

列名

数据类型

可否为空

说明

Stu_no

Char(9)

学生编号

Stu_name

Char(6)

主码

学生姓名

Stu_position

Char(4)

学生职位

S_depart_name

Char(6)

外码

所在部门

Stu_case

Char(20)

Null

参加的活动

Stu_phone

Char(12)

电话

Stu_pro

Char(5)

Null

专业

Stu_sex

Char(8)

性别

部门信息表3-2

列名

数据类型

可否为空

说明

Dep_name

Char(14)

主码

部门名称

Dep_no

Char(8)

部门编号

Buzhang_name

Char(8)

外码

部长姓名

Fubusum

Int

Null

副部长人数

Busum

Int

Null

部委人数

Buzhang_pho

Char(20)

Null

部长电话号码

事务活动信息表3-3

列名

数据类型

可否为空

说明

Act_name

Char(8)

主码

部门活动名称

Act_range

Char(20)

Null

活动职能范围

Act_departmentno

Char(8)

外码

承办部门

solution

Char(30)

Null

以往的解决方法

活动参与表3-4

列名

数据类型

可否为空

说明

Act_name

Char(10)

主码

举办的活动名称

Stu_name

Char(8)

主码

参与学生干部

present

Char(5)

出勤情况

活动使用物品信息表3-5

列名

数据类型

可否为空

说明

Act_name

Char(10)

主码

部门活动名称

Good_name

Char(4)

主码

物品名称

usesum

int

Null

使用数量

物品信息表3-6

列名

数据类型

可否为空

说明

Good_name

Char(4)

主码

物品名称

Fin_no

Char(4)

外码

财务申请编号

Good_no

Char(6)

物品编号

Money

Int

金额

Lend_time

Date

Null

借出时间

Good_lender

Char(6)

Null

借物人姓名

Ret_time

Date

Null

归还时间

Ret_name

Char(6)

Null

归还人姓名

财务信息表3-7

列名

数据类型

可否为空

说明

Fin_no

Char(4)

主码

财务申请编号

Fin_purpose

Char(20)

Null

资金用途

Fin_money

Int

申请金额

Apply_name

Char(6)

外码

申请人姓名

Apply_depart

Char(6)

外码

申请部门

Apply_time

Date

Null

申请时间

Fin_remain

int

Null

余额

学生文件信息表3-8

列名

数据类型

可否为空

说明

File_no

Char(8)

主码

文件编号

File_name

Char(10)

文件名称

File_bel_depart

Char(6)

外码

所属部门

File_person

Char(6)

Notnull

外码

负责人名称

Recdispartner

Char(6)

Null

收发对象

acrdate

Date(12)

Null

存档日期

remark

Char(30)

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

查看

学生信息表的视图

列名

数据类型

可否为空

说明

姓名

Char(6)

Notnull

学生姓名

编号

Char(9)

Notnull

学生编号

性别

Char(8)

Null

学生性别

专业

Char(5)

Null

学生的专业

职位

Char(12)

Notnull

学生的部门

部门

Char(14)

Notnull

学生的职位

部门信息表的视图

列名

数据类型

可否为空

说明

部门名称

Char(14)

Notnull

部门名字

部门编号

Char(8)

Notnull

部门号

部长

Char(6)

Notnull

部长姓名

部长电话

Char(12)

Null

部长电话

活动时借的物品信息视图

列名

数据类型

可否为空

活动名称

Char(8)

Notnull

物品编号

Char(4)

Notnull

财务申请编号

Char(6)

Notnull

物品名称

Char(6)

Notnull

金额

int

Null

借出时间

Date

Notnull

借物人

Char(6)

Null

使用数量

int

null

活动费用的视图:

列名

数据类型

可否为空

活动名称

Char(8)

Notnull

财务申请编号

Char(6)

null

资金用途

Char(20)

Notnull

申请金额

int

Notnull

申请人姓名

Char(6)

NotNull

部门举办过的活动信息的视图:

列名

数据类型

可否为空

活动名称

Char(14)

Notnull

承办部门

Char(8)

Notnull

参与人员

Char(6)

Notnull

存档文件的基本信息视图

列名

数据类型

可否为空

文件名称

Char(10)

Notnull

文件所属部门

Char(14)

Notnull

文件负责人

Char(6)

null

收发对象

Char(6)

Null

存档日期

date

null

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

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 幼儿教育 > 唐诗宋词

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1