学生宿舍管理系统数据库设计案例Word格式.docx

学生宿舍管理系统数据库设计案例Word格式.docx

《学生宿舍管理系统数据库设计案例Word格式.docx》由会员分享，可在线阅读，更多相关《学生宿舍管理系统数据库设计案例Word格式.docx（63页珍藏版）》请在冰点文库上搜索。

从新生角度出发

从毕业生角度出发

从宿舍楼物品出入出发

从宿舍事故角度出入出发

从楼道工作人员的任用角度出发

从管理者和外来访客的角度出发

（3）数据字典

（a）数据项：

系统涉及的数据项有71项

表1.1数据项列表

数据项编号

数据项名

数据项含义

与其它数据项的关系

存储结构

别名

DI-1

StuNo

学生编号

char（9）

学号

DI-2

DepName

学生所在学院

char（20）

学院

DI-3

StuName

学生姓名

char（10）

姓名

DI-4

StuSex

学生性别

char

（2）

性别

DI-5

StuHome

学生来自省份

祖籍

DI-6

StuBorth

学生出生时间

Date

出生日期

DI-7

StuETime

学生入学时间

入学时间

DI-8

StuPerfect

学生所在专业

专业

DI-9

StuClass

学生所在班级编号

Int

编号

DI-10

WorNo

工作人员编号

char（5）

DI-11

WorName

工作人员姓名

DI-12

WorType

工作类型

char（8）

DI-13

WorWage

工作人员工资

月工资

DI-14

WorSex

工作人员性别

DI-15

WorPhNo

工作人员联系方式

char（12）

电话

DI-16

WorTime

工作人员工作时间

char（30）

工作时间

DI-17

RNo

宿舍编号

char（6）

舍号

DI-18

RHeader

舍长信息

等于StuName

舍长

DI-19

ROne

宿舍学生信息

同上

舍员1

DI-20

RTwo

舍员2

DI-21

RThree

舍员3

DI-22

RFour

舍员4

DI-23

RFive

舍员5

DI-24

RSix

舍员6

DI-25

RGrade

宿舍学生所属年级

等于StuETime

char（4）

年级

DI-26

RDepart

宿舍学生所在学院

等于DepName

DI-27

RPerfect

宿舍学生所学专业

等于StuPerfect

DI-28

RClass

等于StuClass

班级

DI-29

DorNo

宿舍楼编号

smallint

宿舍楼号

DI-30

DorCampus

宿舍楼所属校区

校区

DI-31

DorLocation

宿舍楼在校区位置

宿舍区位

DI-32

DorPhNo

宿舍楼管处电话

DI-33

DorAdminist

宿舍楼楼管员信息

等于WorNo

楼管员

DI-34

SGName

保卫处名称

char（15）

名字

DI-35

SGWorNum

保卫处人员总数

人员数目

DI-36

SGHeader

保卫处负责人信息

负责人

DI-37

SGPhone

保卫处电话

DI-38

FitName

宿舍物品名称

char（16）

宿舍物品

DI-39

FitPrice

宿舍物品价格

Float

价格

DI-40

FitNum

每一种宿舍的数量

数量

DI-41

FDFitment

损坏物品信息

等于FitName

物品名

DI-42

FDStudent

损坏的学生信息

等于StuNo

学生

DI-43

FDRoom

损坏物品宿舍信息

等于RNo

DI-44

FDFitNum

损坏物品的数量

DI-45

FCompFit

赔偿物品信息

DI-46

FCompStu

需赔偿学生信息

DI-47

FCompMon

赔偿价格

DI-48

FCompPrin

赔偿负责人信息

DI-49

FCompDate

赔偿日期

日期

DI-50

FCompNum

赔偿物品数量

DI-51

AcNo

事故编号

int

DI-52

AcType

事故类型

类型

DI-53

AcArtical

事故损失物品

DI-54

AcArNum

事故损失物品数量

DI-55

AcStu

事故受害学生

DI-56

AcDate

事故发生日期

DI-57

AcPrin

事故负责人信息

等于SGHeader

DI-58

AcStuPh

受害人联系方式

学生电话

DI-59

AcVerify

事故是否属实

Bool

核查

DI-60

ARNo

事故调查编号

DI-61

ARName

事故调查名称

调查

DI-62

ARPrin

事故调查负责人

DI-63

ARResult

事故调查结果

结果

DI-64

ACStu

事故赔偿学生信息

DI-65

ACArtical

事故赔偿物品信息

DI-66

ACDate

事故赔偿日期

DI-67

ACPrin

事故赔偿负责单位

负责单位

DI-68

AIOStu

要求物品出入学生

DI-69

AIOArtical

出入物品信息

DI-70

AIOPrin

出入物品审查人

DI-71

AIODate

出入物品日期

DI-72

AIONo

物品出入序号

序号

（b）数据结构：

表1.2数据结构列表

数据结

构编号

数据结构名

数据结构

含义

组成

DS-1

Student

StuNo,DepName,StuName,StuSex,StuHome,

StuBorth,StuETime,StuPerfect,StuClass

DS-2

Worker

宿舍楼工作人员信息

WorTime,WorName,WorType,

WorWage,WorSex,WorPhNo,WorNo

DS-3

Room

宿舍信息

RNo,RHeader,ROne,RClass,

RThree,RFour,RFive,RSix,RGrade,

RDepart,RPerfect,RTwo,

DS-4

Dormitory

宿舍楼信息

DorNo,DorCampus,DorPhNo

DorLocation,DorAdminist

DS-5

SafeGuard

宿舍保卫处信息

SGName,SGWorNum,SGHeader,SGPhone

DS-6

Fitment

宿舍物品配备信息

FitName,FitPrice,FitNum

DS-7

FitmentDestruction

宿舍物品损坏信息

FDFitment,FDStudent,FDRoom,FDFitNum

DS-8

FitmentCompensate

宿舍损坏物品赔偿信息

FCompFit,FCompStu,FCompPrin,

FCompDate,FCompNum

DS-9

Accident

宿舍事故注册信息

AcNo,AcType,AcStu,AcDate,

AcArtical,AcVerify,AcPrin,

AcArNum,AcStuPh

DS-10

AccidentResearch

宿舍事故调查信息

ARNo,ARName,ARPrin,ARResult

DS-11

AccidentCompensate

事故损失物品赔偿信息

ACStu,ACArtical,ACDate,ACPrin

DS-12

ArticalInOut

宿舍楼物品出入信息

AIOStu,AIOArtical,AIOPrin,AIODate,AIONo

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

表1.3处理逻辑列表

判定条件

决策

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

宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块：

先确定查询所涉及的功能模块；

然后，确定要查询的内容，确定查询数据流向；

最后显示查询结果。

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

先确定更新所涉及的功能模块；

然后，把更新信息传送到相应的模块中；

最后，进行相应的更新操作。

2.概念设计阶段

2.1引言

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

2.2概念模型设计

（1）根据不同的对象，从第3层数据流程图（中层数据流程图）入手，分别画出分E－R图：

（a）从数据流程图图2.4与图2.5抽象出的分E－R图：

图3.1分E－R图1

图3.2分E－R图2

图3.3分E－R图3

（b）从数据流程图图2.6与图2.8抽象出的分E－R图：

图3.4分E－R图4

（c）从数据流程图图2.7抽象出的分E－R图：

图3.5分E－R图5

（2）各分E－R图中每个实体的属性如下所示：

学生：

Student（StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，StuPerfect，StuClass）；

宿舍：

Room（RNo，RHeader，ROne，RClass，RThree，RFour，RFive，RSix，

RGrade，RDepart，RPerfect，RTwo）；

宿舍楼：

Dormitory（DorNo，DorCampus，DorLocation，DorPhNo，DorAdminist）；

宿舍物品：

Fitment（FitName，FitPrice，FitNum）；

楼道工作人员：

Worker（WorNo，WorName，WorType，WorWage，WorSex,

WorPhNo，WorTime）；

保卫处：

SafeGuard（SGName，SGWorNum，SGHeader，SGPhone）；

各分E－R图中联系的属性如下所示：

物品出入：

ArticalInOut（AIONo，AIOStu，AIOArtical，AIOPrin，AIODate）；

宿舍物品处理：

包含物品损坏和物品赔偿两个数据结构（将在逻辑设计阶段给出）；

事故：

包含宿舍事故注册、宿舍事故调查、事故损失物品赔偿三个数据结构（具体的结构将在系统逻辑设计阶段给出）。

（3）合并各分Ｅ－Ｒ图,消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步E-R图，再消除不必要冗余，得到的基本E-R图如下所示：

2.3新系统流程

新系统流程图：

3．逻辑设计阶段

3.1逻辑设计的任务和目标

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

具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）、数据处理（画出系统功能模块图）两大任务

3.2数据组织

3.2.1将E-R图转换为关系模型

由于宿舍楼与楼道工人的联系方式是1:

n（一对多），可以将其之间的联系与n端实体楼道工人合并，宿舍楼与宿舍之间的联系、宿舍与学生之间的联系方式也是1:

n，同样也将其之间的联系与n端实体宿舍、学生合并，而宿舍物品与学生、学生与楼道工作人员之间的联系方式则是n:

m（多对多），这样要把它们之间的联系转化为独立的关系模式，保卫处与学生之间的联系是1:

n（一对多），但是它们之间的联系事故则包含数据结构，为了便于模型优化，将其联系也转化成独立的关系模式，具体的基本E-R图向关系模型的转化如下：

楼道工人：

WorPhNo，WorTime，DorNo，DorCampus，DorLocation）；

RGrade，RDepart，RPerfect，RTwo，DorNo，DorCampus，DorLocation）；

Fitment（FitName，FitPrice，FitNum，DorNo，DorCampus，DorLocation）；

Student（StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，

StuPerfect，StuClass，RNo，DorNo，DorCampus，DorLocation）；

ArticalInOut（AIONo，StuNo，AIOArtical，AIOPrin，AIODate,DorNo，

DorCampus，DorLocation）；

宿舍物品处理包含两个数据结构（宿舍物品损坏信息，宿舍物品损坏赔偿信息），基于表的各个属性都是原子项的考虑，现将宿舍物品处理分解为：

宿舍物品损坏、宿舍损坏物品赔偿，具体如下：

宿舍物品损坏：

FitmentDestruction（FitName，StuNo，RNo，FDFitNum,DorNo，

DorCampus，DorLocation）；

（消除命名冲突）

宿舍物品损坏赔偿：

FitmentCompensate（FitName，StuNo，FCPrin，FCompDate，

FCompNum）；

宿舍事故包含三个数据结构（宿舍事故注册信息、宿舍事故调查信息、宿舍事故损失物品赔偿信息），同样基于表的原子性的考虑也将事故分解为：

事故注册、事故调查、

事故赔偿，具体如下：

事故注册：

Accident（AcNo，AcType，StuNo，AcDate，AcArtical，AcVerify，SGName，

AcArNum，AcStuPh）；

事故调查：

AccidentResearch（AcNo，ARName，SGName，ARResult）；

事故赔偿：

AccidentCompensate（AcNo，ACStu，AcArtical，ACDate，SGName）；

（注：

标有直线下划线的为主属性，标有波浪线下划线的是外键属性，主属性与外键属性一起构成主码）

3.2.2模型优化

关系模式Worker，Dormitory，Fitment，SafeGuard，ArticalInOut，FitmentDestruction，FitmentCompensate，Accident，AccidentResearch，AccidentCompensate不存在非主属性对主属性的部分函数依赖，也不存在传递函数依赖，已经达到了3NF，但是宿舍关系模式（Room）中存在着一些不应该有的数据冗余，现将模型优化为：

Room（RNo，RHeader，RGrade，RDepart，RPerfect，DorNo，DorCampus，DorLocation）；

虽然Room中还存在一些数据冗余，但可以提高查询效率。

3.2.3数据库模式定义

表2.1数据库模式定义表

逻辑结构（基本表）定义

完整性和安全性

T－１

Worker（详见附录1－1）

（详见附录1－1）

T－2

Dormitory（详见附录1－2）

（详见附录1－2）

T－3

Room（详见附录1－3）

（详见附录1－3）

T－4

Fitment（详见附录1－4）

（详见附录1－4）

T－5

Student（详见附录1－5）

（详见附录1－5）

T－6

SafeGuard（详见附录1－6）

（详见附录1－6）

T－7

ArticalInOut（详见附录1－7）

（详见附录1－7）

T－8

FitmentDestruction（详见附录1－8）

（详见附录1－8）

T－9

FitmentCompensate（详见附录1－9）

（详见附录1－9）

T－10

Accident（详见附录1－10）

（详见附录1－10）

T－11

AccidentResearch（详见附录1－11）

（详见附录1－11）

T－12

AccidentCompensate（详见附录1－12）

（详见附录1－12）

3.2.4用户子模式设计

表2.2用户子模式设计（View）列表

用户子模式（View）

作用（共性：

提供