数据库原理与应用论文---校园卡管理系统数据库设计.doc
《数据库原理与应用论文---校园卡管理系统数据库设计.doc》由会员分享，可在线阅读，更多相关《数据库原理与应用论文---校园卡管理系统数据库设计.doc（54页珍藏版）》请在冰点文库上搜索。
.
信息工程学院
《数据库原理与应用》课程设计论文
题目：
校园卡管理系统数据库设计
学号：
专业班级：
姓名：
指导老师：
完成日期：
二零零九年六月
.
摘要
高校“校园卡”是将采取非接触式电子钱包和电子化校务管理相整合的方式。
校园卡管理系统是应对学生校园生活的现代化、网络化，逐步摆脱当前学生在校生活中的消费管理、身份认证管理的人工管理方式，提高学生校园生活管理效率，方便学生校园生活而开发的，它包括三个子系统：
校园卡日常管理子系统、电子钱包子系统、身份认证子系统。
每个子系统包含多个功能模块，并提供了对各功能模块的查询和更新功能，且这两种功能都是通过存储过程实现的，其中食堂就餐管理、超市购物管理、各种充值管理、宿舍楼门控管理、公共课考勤管理是本系统开发的重点。
该系统开发由系统需求分析阶段、概念设计阶段、逻辑设计阶段、物理设计阶段、数据库实施阶段、系统调试和测试阶段、参考文献、附录等阶段组成。
关键字：
电子钱包；身份认证；现代化；人工管理；存储过程
目录
1.系统需求分析阶段 1
1.1引言 1
1.2目标与任务 1
1.2.1需求分析阶段的目标 1
1.2.2需求分析阶段的任务 1
1.2.3需求分析阶段成果 1
2.概念设计阶段 1
2.1引言 1
2.2概念模型设计 1
3．逻辑设计阶段 1
3.1逻辑设计的任务和目标 1
3.2数据组织 1
3.2.1将E-R图转换为关系模型 1
3.2.2模型优化 1
3.2.3数据库模式定义 1
3.2.4用户子模式设计 1
3.3数据处理 1
4．物理设计阶段 1
4.1物理设计阶段的目标与任务 1
4.2数据存储方面 1
5．数据库实施阶段 1
5.1建立数据库、数据表、视图、索引 1
5.1.1建立数据库 1
5.1.2建立数据表 1
5.1.3建立视图 1
5.1.4建立索引 1
5.2数据入库 1
5.3创建各个功能的存储过程 1
6．系统调试和测试 1
7．收获与体会 1
8．存在的问题及建议 1
致谢 1
参考文献 1
附录1数据库逻辑结构定义 1
附录2存储过程定义 1
附录3数据查看和存储过程功能的验证 1
附录4所有的SQL运行语句 1
.
.
1系统需求分析阶段
1.1引言
通过对南北校区学生日常生活、学习情况的实地调查加上自己亲生体验，了解到现在许多高校学生生活消费管理仍然停留在各种消费分块进行，相对独立的运行模式，而宿舍楼门控管理和上课考勤管理仍然是完全的人工管理阶段，人工管理方式对于宿舍楼管理员和任课教师来说费时、费事、费力，造成工作效率低下。
开发出合适的学生校园生活管理系统，可以方便学生，提高高校消费管理和身份认证管理的工作效率及查询效率。
1.2目标与任务
1.2.1需求分析阶段的目标
（1）了解目前高校学生消费管理和身份认证管理的现状以及SQLServer2000的功能和特点。
（2）通过平时观察、思考、亲身体会，再加上重点实地调查和记录的方式了解和收集大部分学生所向往的消费模式和身份认证模式的工作业务流程，确定基本的系统开发方向。
（3）与指导教师交流个人想法，征求意见，改正不合理的地方，确定新系统的边界，为下面的概念设计与逻辑设计奠定基础。
1.2.2需求分析阶段的任务
（1）处理对象：
系统要处理的对象包括：
学生基本信息，高校学生工作办公室基本信息，校园卡日常事务管理基本信息、“校园卡”基本信息、食堂消费基本信息、超市消费基本信息、身份认证基本信息等日常管理、电子钱包、身份认证三个方面，各个对象包括信息如下所示（详细的数据见于数据字典）：
1．学生基本信息（Student）：
包括学生身份证号、学生学号、学生性别、学生出生年份、学生所在院系、学生的专业、学生所在班级等方面的信息，可以方便学生信息的查询和更新；
3．高校学生工作办公室基本信息（Office,OfficeManage）：
包括两个数据结构Office（办公室信息），OfficeManage（办公室学生管理信息）,每个数据结构中的数据项见数据字典；
4．校园卡日常事务管理基本信息（Bkxx,LosInf,UnLos,FillInf）：
包括四个数据结构Bkxx（办卡信息）,LosInf（挂失信息）,UnLos（解挂信息）,FillInf（充值信息）,每个数据结构中的数据项见数据字典；
5．“校园卡”基本信息（Card）：
包括校园卡的编号、持卡人学生学号、持卡学生身份证号、校园卡的状态、校园卡内的余额；
6．食堂消费基本信息（DinPress，DinWinds，DinInf）：
包括三个数据结构DinPress（食堂刷卡记录）,DinWinds（食堂窗口信息）,DinInf（学生食堂信息），具体的数据项见数据字典；
7．超市消费基本信息（SupPress,SupReader,SupInf）：
包括三个数据结构SupPress（超市刷卡信息）,SupReader（超市刷卡机信息）,SupInf（超市信息）,具体的数据项见数据字典；
8．身份认证基本信息（Course,CourPress,DormInf,DormPress）：
包括四个数据结构Course（学生课程信息）,CourPress（上课刷卡记录信息）,DormInf（学生宿舍楼基本信息）,DormPress（学生归宿刷卡信息）,具体的数据项见数据字典；
（2）处理功能要求
系统主要完成一下几个功能：
1．学生基本信息查询与更新；
2．校园卡日常事务管理情况基本信息查询与更新；
3．校园卡在某个时刻所处状态的查询；
4．食堂月营业额基本信息的查询和修改，查询所有食堂的营业额以了解食堂总体的收入情况，查询各个食堂的收入为评价各个食堂的服务质量提供依据；
5．超市的月营业额基本信息的查询和修改，以了解超市总体的收入情况；
6．学生每月在食堂或者超市的消费金额的查询，以了解学生的真正的月生活消费情况；
（3）安全性和完整性要求
安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过用户授权机制、域用户登陆方式来识别用户级别，根据这个级别来分配用户权限，达到数据更高层次的安全保密功能。
完整性要求用于描述学生基本信息，高校学生工作办公室基本信息，校园卡日常事务管理基本信息、“校园卡”基本信息、食堂消费基本信息、超市消费基本信息、身份认证基本信息中数据项能否为null，以及一些用户自定义完整性（符合实际要求），此处用触发器实现，详细完整性要求见于系统的逻辑设计阶段和数据库实施阶段。
1.2.3需求分析阶段成果
（1）校园卡需求分析的实际过程
系统需求分析是数据库系统开发的最重要的环节，直接关系到后面每个阶段的具体实施，也关系到系统最终的开发方向，因此做好需求分析对于数据库应用系统开发至关重要。
在初步确定课题“校园卡管理系统”以后，首先，我再次细致地总结了南北校区目前食堂学生饮食消费和超市购物消费管理的现状，以及学生宿舍楼归宿管理和教师上课考勤管理方式；其次，亲自到图书馆查阅了关于数据库设计方面的书籍，在这期间我还上网搜索了一些关于校园卡的信息，手头有了一些资料，我也有了自己的一些想法；再次，虽然找到了一些资料，但是我对系统的有些地方仍然感到比较困惑，例如：
校园卡系统涉及范围的取舍问题。
于是，我又向杨老师请教，让她帮我参考我的想法，并给我提一些宝贵的修改建议。
除了这些方面，我还询问了大三学长当时做数据库课程设计的感受，借鉴了学长们在做数据库开发这方面的经验。
通过以上调查，最终确定了我的校园卡系统涉及到的范围，校园卡日常管理、电子钱包、身份认证三个子系统，涉及到了学生在校园的食堂饮食、超市购物、课程考勤、宿舍住宿等多方面的管理。
（2）校园卡管理系统业务流程图
校园卡办理（包括补办）业务流程图：
校园卡充值业务流程图：
校园卡挂失业务流程图：
校园卡解挂业务流程图：
食堂消费业务流程图：
超市消费业务流程图：
学生奖助学金发放管理业务流程图：
宿舍门控管理业务流程图：
智能考勤管理业务流程图：
（3）数据流程图
顶层数据流程图：
第1层数据流程图：
第2层数据流程图：
从后勤中心角度出发
第2层数据流程图：
从校园卡日常事务管理角度出发
第2层数据流程图：
从校园卡消费管理角度出发
第2层数据流程图：
从校园卡的身份认证管理角度出发
（4）数据字典
（a）数据项：
系统涉及的数据项有67项
表1.1数据项列表
数据项编号
数据项名称
简述
类型及宽度
取值范围
DI-1
Sid
学生身份证号
char（18）
"0"-"999999999999999999"
DI-2
Sno
学生学号
char（8）
"0"-"99999999"
DI-3
Sname
学生姓名
char（10）
DI-4
Sage
学生性别
char（4）
"男"、"女"
DI-5
Sbirth
学生出生年
Int
DI-6
Sdept
学生所在院系
char（20）
DI-7
Sspecial
学生所在专业
char（20）
DI-8
Sclass
学生所在班级
char（20）
DI-9
char（6）
学生生源地
char（6）
DI-10
Officeaddr
学生办公室地址
char（40）
DI-11
Officemanage
学生办公室负责人
char（10）
DI-12
Cardno
校园卡编号
char（8）
"0"-"99999999"
DI-13
Cardstate
校园卡状态
char（6）
"可用"、"不可用"
DI-14
Cardmoney
校园卡内余额
Float
DI-15
Bkrq
办卡日期
Datetime
DI-16
jbr
校园卡日常事务负责人姓名
char（10）
DI-17
Gsrq
挂失所在时间
Datetime
DI-18
Jgrq
解挂的时间
Datetime
DI-19
Czrq
充值的时间
Datetime
DI-20
Czje
充值金额
Float
DI-21
Czlx
充值类型
char（40）
“补助”、“奖学金”、“用户自充”
DI-22
Czno
充值次数编号
Int
DI-23
Supname
超市名称
char（40）
DI-24
Supcheckno
超市读卡机编号
char（4）
DI-25
Supmoney
超市购物刷卡金额
Float
DI-26
Suptime
超市购物刷卡时间
Datetime
DI-27
Supmanage
超市负责人姓名
char（10）
DI-28
Supaddr
超市所在校区
char（10）
DI-29
Dinno
食堂编号
char（4）
DI-30
Windsno
食堂窗口编号
char（4）
DI-31
Dinmoney
食堂刷卡金额
Float
DI-32
Dintime
食堂刷卡所时间
Datetime
DI-33
Dinmanage
食堂负责人姓名
char（10）
DI-34
Dinaddr
食堂所在校区
char（10）
DI-35
Pressno
消费次数编号
Int
DI-36
Place
消费所在地点
char（10）
DI-37
Pno
所在地点刷卡机编号
char（4）
DI-38
Pmoney
本次刷卡金额
Float
DI-39
Ptime
本次刷卡所在时间
Datetime
DI-40
Pmanage
刷卡地点负责人姓名
char（10）
DI-41
Paddr
刷卡地点所在校区
char（10）
DI-42
Teacher
任课教师姓名
char（10）
DI-43
Cname
课程名称
char（40）
DI-44
property
课程属性
char（10）
DI-45
Cno
课程编号
char（10）
DI-46
Grade
课程学分
Float
"0"-"5"
DI-47
Classtime
到课刷卡时间
Datetime
DI-48
Classroom
上课所在教室号
char（10）
DI-49
Dormregion
宿舍楼所在校区
char（10）
DI-50
Dormno
宿舍楼编号
char（10）
DI-51
Backtime
回宿舍时间
Datetime
DI-52
ReqOff
学生递交申请的部门
char（40）
DI-53
ReqInf
学生申请的内容
char（40）
DI-54
ReqDate
学生申请时间
Datetime
DI-55
ScanMessage
审批内容
char（40）
DI-56
ScanDate
审批时间
Datetime
DI-57
ScanResult
审批结果
char（40）
DI-58
ScanOff
审批部门
char（40）
DI-59
Scanmanage
审批人
char（10）
DI-60
IdentiInf
确认内容
char（40）
DI-61
IdentiDtae
确认时间
Datetime
DI-62
DutyDorm
值班楼管姓名
char（10）
DI-63
Dinlist
饭菜名称
char（40）
DI-64
DinPrice
饭菜单价
Float
DI-65
TotalPrice
总价格
Float
DI-66
ThingName
商品名称
char（40）
DI-67
ThingPrice
商品单价
Float
（b）数据结构：
表1.2数据结构列表
数据结构编号
数据结构名称
数据结构别名
数据结构含义
数据项组成
DS-1
学生信息
Student
记录学生的信息
Sid、Sno、Sname、Ssex、Sbirth、Sdept、Sspecial、Sclass、Saddr
DS-2
学生工作办公室
Office
记录办公室的信息
Officename、Officeaddr、Officemanage
DS-3
学生管理信息
OfficeManage
记录办公室管理学生的信息
Officename、Sno、Officemanage
DS-4
办卡信息
Bkxx
记录办卡信息
Cardno、Sno、Sid、Bkrq、jbr
DS-5
挂失信息
LosInf
记录挂失信息
Cardno、Sno、Sid、Gsrq、jbr
DS-6
解挂信息
UnLos
记录解挂信息
Cardno、Sno、Sid、Jgrq、jbr
DS-7
充值信息
FillInf
记录充值相关信息
Czno、Cardno、Sno、Czlx、Czje、jbr
DS-8
校园卡信息
Card
记录校园卡信息
Cardno、Sno、Sid、Cardstates、Cardmoney
DS-9
食堂刷卡信息
DinPress
记录食堂刷卡信息
Dinno、Windsno、Cardno、Dinmoney、Dintime
DS-10
食堂窗口信息
DinWinds
记录食堂窗口信息
Dinno、Windsno
DS-11
学生食堂信息
DinInf
记录食堂信息
Dinno、Dinmanage、Dinaddr
DS-12
超市刷卡信息
SupPress
记录超市刷卡信息
Supname、Supcheckno、Cardno、Supmoney、Suptime
DS-13
超市读卡机信息
SupReader
记录收银台信息
Supname、Supcheckno
DS-14
超市信息
SupInf
记录超市信息
Supno、Supname、Supmanage、Supaddr
DS-15
超市食堂消费刷卡信息
PressInf
消费刷卡记录
Pressno、Place、Pno、Cardno、Pmoney、ptime、Pmanage、Paddr
DS-16
课程信息
Course
记录课程信息
Cname、Cno、property、Grade、Teacher、Classroom
DS-17
上课刷卡信息
CourPress
记录到课刷卡情况
Sno、Sid、Cno、Classtime
DS-18
宿舍楼信息
DormInf
记录宿舍楼信息
Dormregion、Dorno、Sdept
DS-19
归宿刷卡信息
DornPress
记录归宿刷卡信息
Sno、Sid、Dorno、Backtime
（5）处理逻辑描述（判定表或判定树）
表1.3处理逻辑列表
判定条件
决策
判断用户查询涉及的功能模块
校园卡充值模块、校园卡刷卡消费模块、校园卡身份认证模块：
先确定查询所涉及的具体功能模块；然后，确定要查询的内容，确定查询数据流向；最后显示查询结果。
判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中
校园卡的各种类型充值情况记录模块、食堂和超市的消费记录模块、回宿舍和上课刷卡的记录模块：
先确定更新所涉及的功能模块；然后，把更新信息传送到相应的模块中；最后，进行相应的更新操作，这个过程可能会用到触发器的操作。
2概念设计阶段
2.1引言
概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型）的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段。
2.2概念模型设计
（1）根据不同的对象，从第3层数据流程图（中层数据流程图）入手，分别画出分E－R图：
（a）第2层数据流程图图2.2抽象出分E-R图
（b）从数据流程图图2.3抽象出的分E－R图：
（c）从数据流程图图2.4抽象出的分E－R图：
（c）从数据流程图图2.5抽象出的分E－R图：
（2）各分E－R图中关键实体和联系的属性如下所示：
学生：
{学号，身份证号，姓名，性别，出生日期，学院，专业，班级，生源地}
学生工作办公室：
{办公室名称，办公室地址，办公室负责人}
校园卡：
{卡号，持卡人学号，持卡人身份证号，卡状态，卡内余额，卡的冻结时间}
学生超市：
{超市编号，超市名称，超市负责人，超市所在校区}
超市刷卡：
{本次消费编号，刷卡类型，该类刷卡地点编号，卡编号，本次消费金额，本次消费时间，该处负责人姓名}
学生食堂：
{食堂编号，食堂负责人，食堂所在校区}
食堂刷卡：
{本次消费编号，刷卡类型，该类刷卡地点编号，卡编号，本次消费金额，本次消费时间，该处负责人姓名}
课程：
{课程编号，课程名称，课程性质，课程学分，任课老师，上课所在教室}
上课刷卡：
{学生上课刷卡次序编号，校园卡卡号，学生学号，学生身份证号，课程编号，课程名称，上课刷卡时间，上课所在教室}
宿舍楼：
{宿舍楼编号，宿舍楼所属院系，宿舍楼所属校区}
归宿刷卡：
{返回宿舍楼刷卡次数编号，校园卡卡号，学生学号，学生身份证号，宿舍楼所属校区，宿舍楼编号，归宿时间}
（注:
为了节省篇幅，实体与属性的关系没有用图形表示，实体和联系的主码分别用下划线划出。
）
（3）合并各分Ｅ－Ｒ图,消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步E-R图，再消除不必要冗余，得到的基本E-R图如下所示：
3逻辑设计阶段
3.1逻辑设计的任务和目标
以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。
具体内容包括数据组织（将E-R图转换成具体的关系模型、模型优化、数据库模式定义、用户子模式（视图）设计）、数据处理（画出系统功能模块图）两大任务。
3.2数据组织
3.2.1将E-R图转换为关系模型
通过分析所要实现的功能以及现有的实体和联系，确定把学生实体、校园卡实体、课程实体、餐厅实体、超市实体、宿舍楼实体分别转化为单独的关系模式，为了便于查询学生在食堂、超市用校园卡刷卡消费的信息，将消费型刷卡联系转化为独立的关系模式；考虑到学生回宿舍和上课考勤记录信息的查询，把身份认证型的刷卡联系转化为独立的关系模式；最后考虑到学生要往校园卡里充值，再从学生和校园卡的拥有联系中抽取出校园卡的充值关系模式，具体的关系模式转化结果如下：
学生：
student（Sno、Sid、Sname、Ssex、Sbirth、Sdept、Sspecial、Sclass、Saddr）3NF
校园卡：
Card（Cardno、Sno、Sid、Cardstates、Cardmoney、Cardtime）3NF
食堂：
DinInf（Dinno、Dinmanage、Dinaddr）3NF
超市：
SupInf（Supno、Supname、Supmanage、Supaddr）3NF
课程：
Course（Cno、Cname、property、Grade、Teacher、Classroom）3NF
宿舍：
DormInf（Dorno、Sdept、Dormregion）3NF
上课刷卡：
CourPress（Classno、Cardno、Sno、Sid、Cno、Cname、Classtime、Classroom）3NF
归宿刷卡：
DormPress（Backno、Cardno、Sno、Sid、Dormregion、Dormno、Backtime）3NF
充值：
FillInf（Czno、Cardno、Sno、Czlx、Czje、Czrq、jbr）3NF
消费刷卡：
PressInf（Pressno、Place、Pno、Cardno、pmoney、ptime、Pmanage）3NF
（注：
标有直线下划线的为主属性，标有波浪线下划线的是外键属性）
3.2.2模型优化
关系模式student，Card，DinInf，SupInf，Course，DormInf，CoursePress，DormPress、FillInf，PressInf不存在非主属性对主属性的部分函数依赖，也不存在传递函数依赖，已经达到了3NF。
同时关系模式（CourseP
升级会员 