学生会管理系统的.docx

学生会管理系统的.docx

《学生会管理系统的.docx》由会员分享，可在线阅读，更多相关《学生会管理系统的.docx（47页珍藏版）》请在冰点文库上搜索。

学生会管理系统的

大连理工大学网络教育学院

《Web技术》课程设计

设计题目：

学生会管理系统

学习中心：

丽水

层次：

专升本

专业：

网络工程

年级：

2016年春

学号：

201203238493

学生姓名：

胡聪

1.系统需求分析3

1.1需求分析阶段的目标3

1.1需求分析阶段的任务3

2.数据库设计13

2.1概念设计阶段13

2.2逻辑设计阶段18

2.3物理设计阶段23

3.数据库实施阶段27

3.1数据库实施阶段目标27

3.2数据库实施阶段任务27

4.结束语35

参考文献36

1.系统需求分析

需求分析简单的说就是分析用户的要求。

需求分析是涉及数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计的结果是否合理和实用。

1.1需求分析阶段的目标

1．了解高校学生会管理的基本内容；

2．综合的理解主管学生会老师和学生会干部的不同需求；

3．了解学生会管理的基本业务流程；

4．了解学生会人工管理模式与信息系统的工作概况，以及它们之间的区别与联系；

5．通过自身的体验和与主管学生会的老师及其他学生会干部的交流，了解用户对高校学生会管理系统的业务要求，完整性和安全性要求。

1.1需求分析阶段的任务

1．处理对象：

系统处理对象是学生会的干部信息管理、财务管理、日常事务管理和文件信息管理四个方面。

在学生会的干部信息处理中主要涉及几下几个方面的信息：

（1）学生会干部基本信息（Student）：

包括编号、姓名、性别、职务、专业、年级、加入学生会日期、参加过的活动项目等信息。

（2）部门基本信息（Dpartment）：

部门编号、部门名称、部长姓名、副部长人数、部委人数、部长电话等信息。

在财务信息处理中主要涉及几下几个方面的信息：

（1）物品基本信息（Goods）：

包括物品编号、物品名称、购买时间、单价、借出时间，借物人姓名、归还时间、归还人姓名等信息。

（2）财务基本信息（Financialaffairs）：

包括财务申请编号、资金用途、申请金额、申请人、申请部门、申请时间、余额等信息。

在日常事务信息处理中主要涉及几下几个方面的信息：

（1）事务活动基本信息（Affairs）：

包括事务活动编号、事务活动名称、职能范围、承办部门、以往解决方案、是否特色活动等信息。

（2）工作计划基本信息（Workingplan）：

包括工作计划编号、工作计划名称、提交部门、提交人、提交时间、是否紧急活动等信息。

在文件信息处理中主要涉文件的基本信息（File）：

包括文件编号、文件名称、文件类型、所属部门、负责人、收发对象、存档日期、备注等信息。

2．处理功能要求

高校学生会管理系统主要实现对学生会的科学化、条理化、信息化、高效化管理。

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

具体功能描述如下：

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

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

（3）日常事务管理实现对学生会日常开展工作的管理，完成日常事务的查询与更新，从而更好地实现以下职能：

包括各部门提交的工作计划、活动计划的审核与安排、活动的筹划、各项活动的人员合理的调度与安排，确保各项活动成功地举办，更有利于学生会各项日常工作的顺利开展。

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

3．安全性和完整性要求

安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过用户授权机制，通过用户登陆来识别用户级别，根据这个级别来分配用户权限，达到数据更高层次的安全保密功能。

近而可以满足用户的基本数据安全性要求。

完整性要求用于描述各种信息之间的制约关系，以及关联关系，各个数据项的取值范围以及各个数据项是否可以不取值。

根据实际需要，采取一定的手段来满足用户的完整性需求。

4．业务流程图

学生会干部信息管理业务流程图：

财务管理业务流程图：

日常事务管理业务流程图：

文件管理业务流程图：

5．数据流程图

顶层数据流程图：

第2层数据流程图：

第3层数据流程图：

从学生干部信息管理角度出发

第3层数据流程图：

从财务管理角度出发

第3层数据流程图：

从日常事务管理角度出发

第3层数据流程图：

从文件管理角度出发

7．数据字典

（1）数据项：

系统涉及的数据项有51项

表1.1（高校学生会管理系统）数据项列表（汇总统计）

数据项编号

数据项名

数据项含义

与其它数据项的关系

存储结构

别名

DI-1

StuNo

学生干部编号

char（8）

编号

DI-2

StuName

学生干部姓名

char（10）

姓名

DI-3

StuSex

学生干部性别

char

（2）

性别

DI-4

StuPosition

学生干部职务

char（6）

职务

DI-5

StuDepartName

学生干部所属部门

等于DepNo

char（6）

部门

DI-6

StuMajor

学生干部所属专业

char（20）

专业

DI-7

StuGrade

学生干部所在年级

char（8）

年级

DI-8

StuPhoneNo

学生干部电话

char（12）

电话

DI-9

StuStaTime

加入学生会时间

datetime

时间

DI-10

StuCase

参加过的活动项目

varchar（50）

项目

DI-11

GoodsNo

物品编号

char（8）

编号

DI-12

GoodsName

物品名称

char（16）

名称

DI-13

GoodsBuyTime

购买时间

datetime

时间

DI-14

GoodsPrice

单价

char（6）

单价

DI-15

GoodsLendTime

借出时间

datetime

时间

DI-16

GoodsLender

借物人姓名

char（10）

姓名

DI-17

GoodsReturner

归还人姓名

char（10）

姓名

DI-18

GoodsRetTime

归还时间

datetime

时间

DI-19

FinNo

财务申请编号

char（6）

编号　

DI-20

FinPurpose

用途

char（30）

用途

DI-21

FinMoney

申请金额

char（6）

金额

DI-22

FinPerson

申请人姓名

char（10）

姓名

DI-23

FinDepartment

申请部门

char（14）

部门

DI-24

FinTime

申请时间

datetime

时间

DI-25

FinRemain

余额

char（6）

余额

DI-26

PlaNo

工作计划编号

等于FileNo

char（6）

编号

DI-27

PlaName

工作计划名称

char（30）

名称

DI-28

PlaDepartment

计划提交部门

等于DepNo

char（6）

部门

DI-29

PlaPerson

计划提交人

char（10）

姓名

DI-30

PlaTime

计划提交时间

datetime

时间

DI-31

PlaQuality

是否紧急活动

char（4）

是否

DI-32

AffNo

事务活动编号

char（6）

编号

DI-33

AffName

事务活动名称

char（20）

名称

DI-34

AffScope

事务活动职能范围

char（8）

职能

范围

DI-35

AffDepartment

主要承办部门

等于DepNo

char（6）

部门

DI-36

AffScheme

以往解决方案

char（50）

方案

DI-37

AffQuality

是否特色活动

char（4）

活动

DI-38

DepNo

部门编号

char（6）

编号

DI-39

DepName

部门名称

char（14）

名称

DI-40

DepMinName

部长姓名

等于StuName

char（8）

姓名

DI-41

DepSminSum

副部长人数

int

人数

DI-42

DepMemSum

部委人数

int

人数

DI-43

MinPhoNo

部长电话

char（12）

电话

DI-44

FilesNo

文件编号

char（6）

编号

DI-45

FilesName

文件名称

char（20）

名称

DI-46

FilesType

文件类型

char（14）

类型

DI-47

FilesBelDep

所属部门

char（6）

部门

DI-48

FilesPerson

负责人

char（8）

姓名

DI-49

RecDisPartner

收发对象

char（14）

对象

DI-50

ArcDate

存档日期

datetime

日期

DI-51

Remarks

备注

char（30）

备注

（2）数据结构：

表1-2（高校学生会管理系统）数据结构（汇总统计）

数据结构编号

数据结构名

数据结构含义

组成

DS-1

Student

学生干部信息

StuNo,StuName,StuSex,StuPosition,StuMajor,

StuDepartName,StuGrade,StuPhoneNo,StuCase,

StuStaTime,

DS-2

Goods

物品信息

GoodsNo,GoodsName,GoodsBuyTime,GoodsPric,GoodsLender,GoodsLendTime,GoodsReturner,

GoodsRetTime

DS-3

FinancialAffairs

财务信息

FinNo,FinPurpose,FinMoney,FinPerson,

FinTime,FinDepartment,FinRemain

DS-4

WorkingPlan

工作计划信息

PlaNo,PlaName,PlaDepartment,PlaPerson

PlaTime,PlaQuality

DS-5

Affairs

事务活动信息

AffNo,AffName,AffScope,AffDepartment

AffScheme,AffQuality

DS-6

Department

部门信息

DepNo,DepName,DepMinName,DepSminSum

DepMemSum,MinPhoNo

DS-7

Files

文件信息

FilesNo,FilesName,FileTyp,FilesBelDep,

FilesPerson,RecDisPartner,ArcDate,Remarks

8．处理逻辑描述（判定表或判定树）

表1-3（高校学生会管理系统）处理逻辑描述

处理编号

处理功能

处理过程

PR-1

判断用户查询涉及的功能模块

学生会干部信息管理模块、财务管理模块、学生会日常事务管理模块、文件信息管理模块：

先确定查询所涉及的功能模块；然后，确定要查询的内容，确定查询数据流向；最后显示查询结果。

PR-2

判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中

学生会干部信息管理模块、财务管理模块、学生会日常事务管理模块、文件信息管理模块：

先确定更新所涉及的功能模块；然后，把更新信息传送到相应的模块中；最后，进行相应的更新操作。

2.数据库设计

2.1概念设计阶段

·目标

将需求分析得到用户需求抽象为信息结构即概念模型的过程就是概念结构设计。

概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型）的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段。

在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。

·具体任务

1．选择中层数据流为切入点，通常选择实际系统中的子系统；

2．设计分E-R图，即各子模块的E-R图；

3．生成初步E-R图，通过合并方法，做到各子系统实体、属性、联系统一；

4．生成全局E-R图，消除冲突。

·结果

1．各实体及其属性

2．生成分E-R图如下所示：

3．合并各分Ｅ－Ｒ图,消除各类冲突，得到初步E-R图，再消除不必要冗余，得到的基本E-R图。

具体实现如下：

a.消除冲突

合并分E-R图时并不能简单地将各个分E-R图画到一起，而是必须着力消除各个分E-R图中的不一致，以形成一个能为全系统中所有的用户共同理解和接受的统一的概念模型。

合并分E-R图的主要工作与关键是合理消除各分E-R图的冲突，冲突主要有三类：

属性冲突、命名冲突和结构冲突。

b.消除冗余

在E-R 图中，可能存在一些冗余的数据和实体间的联系。

冗余数据和冗余联系容易破坏数据库的完整性，给数据库的维护增加困难，应予以消除。

但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

消除冗余主要采用分析法和规范化理论。

经过以上分析，将所有的分E-R图综合成一个系统的总E-R图：

解释如下：

一个部门可以承办多个事务活动，而一个事务活动只能由一个部门去承办；

一个部门可以包括多个学生会干部，而一个学生会干部只能隶属于一个部门；

一个学生会干部可以参与多项事务活动，而一个事务活动也可以有多个学生干部参与；

一个学生会干部可以提交多份财务申请，而一份财务只能由一个学生会干部申请；

一个学生会干部可以制定多份文件，而一份文件只能由一个学生会干部制定；

一个学生会干部可以提交多份工作计划，而一份工作计划只能由一个学生会干部提交；

一份财务申请的资金可以购买多种物品，而一种物品只能由一次财务申请的资金来购买；

一次事务活动需借用多种物品，而一种物品一次只能给被一项事务活动所借用；

一份工作计划可以包括多项事务活动，而一项事务活动只能有一份工作计划中制定。

4．新系统流程图

2.2逻辑设计阶段

1逻辑设计阶段的目标

以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的目标就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。

2逻辑设计阶段的任务

具体任务是数据组织和数据处理。

在数据组织阶段主要要完成的任务是将E-R图转换成为关系模型；模型优化；完成数据库模式定义描述，包括各模式的逻辑结构定义、关系的完整性和安全性等内容；用户子模式设计。

以表格的形式表现出来。

数据处理阶段主要任务是画出系统功能模块图。

1．数据组织

（1）实体型转换为关系模式

一个实体型转换为一个关系模式。

实体的属性就是关系的属性，实体的码就是关系的码。

学生会干部（编号，姓名，性别，职务，部门，专业，年级，电话，加入学生会日期，参加过的活动项目）

物品（编号，名称，购买时间，单价，借出时间，借物人姓名，归还时间，归还人姓名）

财务（财务申请编号，资金用途，申请金额，申请人，申请部门，申请时间，余额）

工作计划（编号，名称，提交部门编号，提交人，提交时间，是否紧急活动）

事务活动（编号，名称，职能范围，承办部门，以往解决方案，是否特色活动）

部门（部门编号，部门名称，部长编号，副部长人数，部委人数，部长电话）

文件（编号，名称，类型，所属部门编号，负责人，收发对象，存档日期，备注）

（2）实体间联系转换为关系模式

一个1：

1联系可以转换为一个独立的关系，也可以与任意一段对应的关系模式合并。

如果转化为一个独立的关系模式，则与该联系相连的各个实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。

如果与某一个实体对应的关系合并，则需要在该关系模式的属性中加入另一个关系的主码和联系本身的属性。

一个m：

n的联系可以转化为一个单独的关系模式，这个单独的关系模式的主码事两端实体的码，再加上联系的属性。

一个1：

n联系可以转化为一个独立的关系模式，也可以与n端的关系模式合并作如果与n端的关系模式合并，在n端的关系模式中加上另一端关系的码和联系属性。

为了方便系统地实现和数据库的设计，将所有的关系均作为一个单独的关系模式。

（3）通过转化后所得出的关系模型

在以下的关系模式当中，关系模式的码用直下划线标出，关系模式的外键用曲下划线标出。

学生会干部（编号，姓名，性别，职务，部门，专业，年级，电话，加入学生会日期，参加过的活动项目）

物品（编号，财务申请编号，名称，购买时间，单价，借出时间，借物人姓名，归还时间，归还人姓名）

财务（财务申请编号，资金用途，申请金额，申请人，申请部门，申请时间，余额）

工作计划（编号，名称，提交部门编号，提交人，提交时间，是否紧急活动）

事务活动（编号，名称，职能范围，承办部门，以往解决方案，是否特色活动）

部门（编号，名称，部长编号，副部长人数，部委人数，部长电话）

文件（编号，名称，类型，所属部门编号，负责人，收发对象，存档日期，备注）

活动使用物品（事务活动编号，物品编号，使用数量）

参与活动（事务活动编号，学生会干部编号，出勤情况）

（4）数据模型优化

经过检查，以上九个关系模型当中前七个的主码都只有一个属性列，所以不从在部分函数依赖，后两个关系模式也不存在部分函数依赖。

而且这九个关系模式也不存在传递函数依赖。

因此，它们均已经达到3NF。

（5）数据库模式定义

其中，包括各模式的逻辑结构定义、关系的完整性和安全性等内容。

1．学生会干部（Student）基本信息表，用于记录学生会干部的基本信息

学生会干部基本信息表

属性名

数据类型

取值范围

是否是主属性或外键

完整性

StuNo

char（8）

00000000～99999999

是

Notnull

StuName

char（10）

否

Notnull

StuPosition

char（6）

否

Notnull

StuSex

char

（2）

男、女

否

Null

StuMajor

char（14）

否

Null

StuDepart

char（20）

是

Notnull

StuGrade

char（8）

否

Null

StuPhoneNo

char（12）

否

Notnull

StuStaTime

datetime

否

Notnull

StuCase

varchar（50）

否

Null

　2．物品（Goods）基本信息表，用于记录学生会物品的基本信息：

物品基本信息表

属性名

数据类型

取值范围

是否是主属性或外键

完整性

GoodsNo

char（8）

00000000～99999999

是

Notnull

FinNo

char（6）

000000～999999

是

Notnull

GoodsName

char（16）

否

Notnull

GoodsBuyTime

datetime

否

Null

GoodsPrice

char（6）

否

Notnull

GoodsLender

char（10）

否

Null

GoodsLendTime

datetime

否

Null

GoodsReturner

char（10）

否

Null

GoodsRetTime

datetime

否

Null

3．财务（FinancialAffairs）基本信息表，用于记录财务的基本信息：

财务基本信息表

属性名

数据类型

取值范围

是否是主属性或外键

完整性

FinNo

char（6）

000000～999999

是

Notnull

FinPurpose

char（30）

否

Null

FinMoney

char（6）

否

Notnull

FinPerson

char（8）

是

Notnull

FinTime

datetime

否

Null

FinDepartment

char（6）

是

Notnull

FinRemain

char（6）

否

Null

4．工作计划（WorkingPlan）基本信息表，用于记录各部提交的工作计划的基本信息：

工作计划基本信息

属性名

数据类型

取值范围

是否是主属性或外键

完整性

PlaNo

char（6）

000000～999999

是

Notnull

PlaName

char（30）

否

Notnull

PlaDepartment

char（6）

是

Notnull

PlaPerson

char（8）

是

Null

PlaTime

datetime

否

Null

PlaQuality

char（4）

否

Notnull

5．事务活动（Affairs）基本信息表，用于记录学生会各项事务活动的基本信息：

事务活动学生基本信息

属性名

数据类型

取值范围

是否是主属性或外键

完整性

AffNo

char（6）

000000～999999

是

Notnull

PlaNo

char（6）

000000～999999

是

Notnull

AffName

char（20）

否

Notnull

AffScope

char（8）

否

Null

AffDepartment

char（6）

是

Notnull

AffScheme

char（50）

否

Null

AffQuality

char（4）

否

Notnull

6．部门（Department）基本信息表，用于记录部门的基本信息：

部门基本信息

属性名

数据类型

取值范围

是否是主属性或外键

完整性

DepNo

char（6）

000000～999999

是

N