桌游吧管理系统的分析与设计Word文档格式.docx
《桌游吧管理系统的分析与设计Word文档格式.docx》由会员分享，可在线阅读，更多相关《桌游吧管理系统的分析与设计Word文档格式.docx（43页珍藏版）》请在冰豆网上搜索。
计算机技术是MIS得以实施的主要技术，在这些技术中，软件开发是MIS开发的重点。
第三个因素也不可忽视。
企业的管理数据是MIS正常运行的基础。
广义地说，各项管理制度是MIS建设成功的基础。
试想要计算一台机床的成本，需要输入每个部件、每个零件以及每个螺丝钉帽的费用，涉及企业的生产车间、采购、库房、工艺设计和财务等多个部件，必须有一整套管理制度作保证。
在计算机软件技术中，人机界面已经发展为一个重要的分支。
MIS人机界面设计一般遵循以下基本原则：
1.以通讯功能作为界面设计的核心
人机界面设计的关键是使人与计算机之间能够准确地交流信息。
一方面，人向计算机输入信息时应当尽量采取自然的方式；
另一方面，计算机向人传递的信息必须准确，不致引起误解或混乱。
另外，不要把内部的处理、加工与人机界面混在一起（人机界面程序只是通讯），以免互相干扰，影响速度。
设计MIS时，针对每个功能，都要按照模块化思想，使输入、处理与输出“泾渭分明”，充分体现人机界面的通讯功能。
这样设计出来的程序不易出错，而且易于维护。
报表打印是MIS必备的功能之一，而且打印之前常常需要计算。
计算与打印分开设计，虽然消耗时间，但易于整个MIS系统的维护。
2.界面必须始终一致
统一的人机界面不致于会增加用户的负担，让用户始终用同一种方式思考与操作。
最忌讳的是每一个屏幕用户就要换一套操作指令与操作方法。
例如在整个系统可以以问号图标表示帮助，以磁盘图标表示存盘，以打印机图标表示打印机等。
3.界面必须使用用户随时掌握任务的进展情况
人机界面应该能够告诉用户软件运行的进度。
特别是在需要长时间的等待时，必须让用户了解工作进展情况，如可以设计已经完成百分之几的任务进度条凳。
目前，Windows下的应用软件无论大小，其安装程序几乎均做到了这一点。
开发MIS软件时，这一点很值得借鉴。
4.界面友好，使用方便
多数MIS软件的数据输入量较大。
对于一些相对固定的数据，不应让用户频频输入（特别是汉字），而应让用户用鼠标轻松选择。
例如，人事管理系统中的“文化程度”是相对固定的数据，其值一般取“小学”，“高中”，“大专”，“大本”，“硕研”，“博研”等，录入数据之前，MIS软件应在相应的位置弹出一个列表框，待用户以鼠标点击，而不应该让用户每次都输入这些汉字。
总之，所开发的MIS在使用过程中，应使用户的数据输入量降至最低限度减少用户的干预量。
实践证明，用户干预愈少，MIS系统的满意度愈高。
第二章需求分析
2.1引言
进行系统设计，首先要对系统的现状进行分析。
根据系统的目标、需求和功能，制定和选择一个较好的系统方案，从而达到一个合理的优化系统。
几乎每一个大型城市的每一处繁华区或是每一所高校附近都有桌游吧的存在，最初由于桌游数量和种类较少，人工手动管理比较方便和灵活。
随着社会的发展，桌游的数量和种类越来越多，人工手动管理会降低工作的效率，希望建立一个桌游吧管理系统，是为了解决人工手动管理桌游信息在实践的问题，从而达到系统化、规范化、标准化的水平。
该系统的建立不但给管理者带来了方便，也节省了工作时间从而提高了工作效率。
需求分析是在于要弄清用户对开发的数据库应用系统的确切要求。
数据库设计的第一步是明确数据库的目的和如何使用，也就是说需要从数据库中得到哪些信息。
明确目的之后，就可以确定您需要保存哪些主题的信息（表），以及每个主题需要保存哪些信息（表中字段）。
在构造系统时，首先从需求出发构造数据库表，然后再由数据库表结合需求划分系统功能模块。
这样，就把一个大的系统分解成了几个小系统。
这里把系统的层次划分为了四个部分：
桌游维护，人员信息管理，桌游的租赁管理，信息查询。
能够实现以下功能：
1、进行新桌游的入库、现有桌游的信息修改以及删除；
2、能够实现对租赁业务顾客基本信息的查询和编辑管理；
3、能够进行超期罚款功能；
4、能够进行租赁信息的查询功能；
2.2需求分析阶段的目标与任务
2.2.1处理对象
顾客信息：
顾客编号，姓名，性别，身份证号，所在省，所在市，所在县，类型，类别编号，办证日期
管理员信息：
管理员编号，姓名，性别，权限，登录口令，住址，电话
店藏桌游信息：
桌游编号，索桌游号，桌游名称，代言人，出厂商，单价，说明，关键字，副本数，分类，出厂日期，状态
租赁信息：
桌游编号，顾客编号，桌游名，代言人，租赁日期，偿还日期，应还日期，罚金
租赁历史信息：
桌游编号，顾客编号，桌游名，代言人，租赁日期，偿还日期
罚款信息：
顾客编号，桌游编号，桌游名，代言人，租赁日期，应还日期，偿还日期，罚款金额，处理状态，管理员编号
2.2.2处理功能及要求
1．能够存储一定数量的桌游信息,并方便有效的进行相应的桌游数据操作和管理，这主要包括：
1）桌游信息的录入、删除及修改。
2）桌游信息的检索查询。
3）桌游的租赁、偿还及超期罚款或丢失赔偿。
2．能够对一定数量的顾客、管理员进行相应的信息存储与管理，这其中包括：
1）顾客信息的登记、删除及修改。
2）管理员信息的增加、删除及修改。
3）顾客资料的统计与查询。
3．能够提供一定的安全机制，提供数据信息授权访问，防止随意删改、查询。
4．对查询、统计的结果能够列表显示。
2.2.3.安全性和完整性要求
1、安全性要求
系统安全性要求体现在数据库安全性、信息安全性和系统平台的安全性等方面。
安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过分配权限、设置权限级别来区别对待不同操代言人对数据库的操作来提高数据库的安全性；
系统平台的安全性体现在操作系统的安全性、计算机系统的安全性和网络体系的安全性等方面。
2完整性要求
系统完整性要求系统中数据的正确性以及相容性。
可通过建立主、外键，使用check约束，或者通过使用触发器和级联更新。
2.3需求分析阶段成果
2.3.1体会与收获
系统需求分析主要是通过对本校桌游管理员的咨询、请教，了解我校桌游馆的管理规则和运行机制，并通过上网搜索有关桌游管理系统的知识，了解到了桌游管理的现状，以及在管理中的一些问题。
由于是第一次做这样的需求调查，开始总是觉得无从下手，不知道自己该了解、该清楚那些方面的知识，在绘制系统业务流程图时，也遇到了很多的问题，但通过老师的帮助与指导，和自己一遍一遍的分析和完善，才逐步把业务弄清楚，最终顺利完成了需求分析阶段的任务。
2.3.2桌游管理系统业务流程图
从顾客角度考虑的业务流程图：
图2.1从顾客角度考虑的业务流程图
2.3.3桌游吧管理系统数据流程图
顶层数据流图：
顾客信息租赁信息
桌游信息
查询信息管理员信息
图2.2顶层数据流图
第2层数据流图：
（顾客租赁，顾客偿还，顾客查询，管理员查询，管理员修改）
图2.3第2层数据流图
第3层数据流图：
（顾客租赁）
图2.4第3层数据流图（顾客租赁）
（顾客偿还）
.
图2.5第3层数据流图（顾客偿还）
（查询桌游信息，查询顾客信息，查询租赁历史，查询罚款信息）
图2.6第3层数据流图（管理员、顾客查询）
（管理员添加、删除、修改桌游信息）
图2.7第3层数据流图（桌游的维护）
（管理员添加、删除、修改顾客信息）
图2.8第3层数据流图（更改顾客信息）
（管理员添加、删除、修改系统用户信息）
图2.9第3层数据流图（更改管理员信息）
2.3.4桌游吧管理系统数据字典
（a）数据项：
系统涉及的数据项有44项
表1.1数据项列表
数据项编号
数据项名
数据项含义
与其它数据项的关系
存储结构
别名
DI-1
BGID
桌游条码号
char（9）
条码号
DI-2
BGNo
索桌游号
char（10）
DI-3
BGName
桌游名
char（20）
DI-4
BGCelebrity
桌游代言人
char（8）
代言人
DI-5
BGFirm
桌游出厂商
出厂商
DI-6
BGPrice
桌游单价
char（7）
单价
DI-7
BGDate
桌游出厂日期
Date
出厂日期
DI-8
BGClass
桌游分类
类别
DI-9
BGMain
桌游说明
char（200）
说明
DI-10
BGPrim
桌游关键字
char（30）
关键字
DI-11
BGCopy
桌游副本数
char（5）
副本数
DI-12
BGState
桌游是否可借
状态
DI-13
BGRNo
所属馆室号
同RoomNo
char（5）
馆室号
DI-14
CusID
顾客条码号
DI-15
CusName
顾客姓名
姓名
DI-16
CusSex
顾客性别
char
（2）
性别
DI-17
CusNo
顾客学号
char（9）
学号
DI-18
CusrLBGID
顾客类别编号
同LBGID
类别编号
DI-19
CusType
顾客类型（职务）
类型
DI-20
CusVisit
顾客所在省
省
DI-21
CusCity
顾客所在市
市
DI-22
CusCounty
顾客所在县
县
DI-23
CusDate
顾客办证时间
办证时间
DI-24
OutDate
租赁日期
租赁时间
DI-25
InDate
偿还日期
偿还时间
DI-26
YHDate
应还日期
应还时间
DI-27
Fine
罚款金额
char（3）
DI-28
CLState
是否交纳罚金
处理状态
DI-29
LBGID
同CusLBGID
DI-30
LCName
顾客类别名
类别名
DI-31
LBGnum
允许最多租桌游数量
租赁数量
DI-32
LBGbqx
允许最长持有时间
char（4）
租赁期限
DI-33
LBGqx
租赁卡有效期
有效期限
DI-34
MID
管理员编号
同RoomMID
编号
DI-35
MName
管理员姓名
DI-36
MSex
管理员性别
DI-37
Mpwd
管理员口令
口令
DI-38
MAuth
管理员权限级别
权限级别
DI-39
MTeleph
管理员电话
char（15）
电话
DI-40
MAddre
管理员地址
char（30）
住址
DI-41
RoomNo
同BGRNo
DI-42
RoomMID
馆室管理员编号
同MID
DI-43
RoomNum
馆室内桌游数目
数量
DI-44
RoomAddre
馆室地址
地址
（b）数据结构：
表1.2数据结构列表
数据结
构编号
数据结构名
数据结构
含义
组成
DS-1
BG
店藏桌游信息
BGID,BGNo,BGName,BGCelebrity,
BGFirm,BGPrice,BGDate,BGClass,BGMain,BGPrim,BGCopy,BGState,
DS-2
Customer
顾客信息
CusID,CusName,CusSex,CusNo,CusLBGID,CusType,CusVisit,CusCity,CusCounty,CusDate,
DS-3
Borrow
租赁信息
BGID,CusID,BGName,BGCelebrity,Outdate,YHdate
DS-4
History
租赁历史
BGID,CusID,BGName,BGCelebrity,Outdate,Indate
DS-5
罚款信息
BGID,CusID,BGName,Outdate,Indate,Fine,CLState，MID
DS-6
CustomerType
顾客类别
LBGID,LBGName,LBGnum,LBGbqx,LBGqx
DS-7
Maneger
管理员信息
MID,MName,MSex,Mpwd,MAuth,MTeleph,MAddre
DS-8
Room
馆室信息
RoomNO,RoomMID,RoomNum,RoomAddre
2.3.5处理逻辑描述
表1.3处理逻辑列表
处理编号
处理功能
处理过程
PR-1
判断顾客查询涉及的功能模块
店藏桌游信息模块、顾客信息模块、顾客类别信息模块、租赁信息模块、租赁历史信息模块、罚款信息模块、管理员模块、馆室信息模块：
先确定查询所涉及的功能模块；
然后，根据要查询的内容，确定查询数据流向；
最后显示查询结果。
PR-2
判断桌游、顾客修改要涉及的模块，同时把相应的修改数据传到相应的模块之中
店藏桌游信息模块、顾客信息模块、顾客类别信息模块、管理员信息模块、馆室信息模块：
先确定更新所涉及的功能模块；
然后，把更新信息传送到相应的模块中；
最后，进行相应的更新操作。
第三章概念结构设计
3.1引言
系统开发的总体目标是实现桌游吧管理的系统化和自动化，缩短顾客的等待时间，减轻工作人员的工作量，方便工作人员对它的操作，提高管理的质量和水平，做到高效、智能化管理，从而达到提高桌游吧管理效率的目的。
主要任务是对顾客信息、管理员信息、桌游资料信息、租赁信息、偿还桌游信息、罚款信息的基本信息的操作及外理。
概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型）的过程,它是整个数据库设计的关键。
3.2任务与目标
在概念结构设计阶段的设计流程为：
（1）选择中层数据流为切入点，通常选择实际系统中的子系统；
（2）设计分E-R图，即各子模块的E-R图；
（3）生成初步E-R图，通过合并方法，做到各子系统实体、属性、联系统一；
（4）生成全局E-R图，通过消除冲突等方面。
在本桌游管理系统中，从第3层数据流程图下手。
分析各3层数据流图和数据字典，知道整个系统功能围绕“顾客”、“管理员”和“桌游”的处理。
根据实体与属性间的两条准则：
作为“属性”，不能再具有需要描述的性质。
“属性”不能与其他实体具有联系。
可综合成租赁子系统的分E-R图3.1，分E-R图3.2，分E-R图3.3，分E-R图3.4。
然后采用逐步集成的方式将各分E-R图合并，消除不必要的冗余和冲突后就生成了基本E-R图3.5。
3.3阶段结果
根据不同的对象，分别画出各分E－R图如下所示：
mmn
nnm
图3.1分E-R图1
1n
图3.2分E-R图2
图3.3分E-R图3
n
1
图3.4分E-R图4
合并各E-R分图,消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步E-R图，再消除不必要冗余，得到的基本E-R图如图3.5所示：
1
m1
1nn
图3.5总E-R图
各E－R图各实体的属性如下所示：
桌游：
Boardgames（BGID,BGNo,BGName,BGCelebrity,BGFirm,BGPrice,BGDate,BGClass,BGMain,BGPrim,BGCopy,BGState,BGRN）
顾客：
Customer（CusID,CusName,CusSex,CusNo,CusLBGID,CusType,CusVisit,CusCity,CusCounty,CusDate）
管理员：
Maneger（MID,MName,MSex,Mpwd,MAuth,MTeleph,MAddre）
馆室：
Room（RoomNo,RoomMID,RoomNum,RoomAddre）
顾客类别：
CustomerType（LBGID,LBGName,LBGnum,LBGbqx,LBGqx）
各E－R图中联系的属性如下所示：
Borrow（BGID,CusID,BGName,BGCelebrity,Outdate,YHdate）
租赁历史：
History（BGID,CusID,BGName,BGCelebrity,Outdate,Indate）
Fine（BGID,CusID,BGName,Outdate,Indate,Fine,CLState,MID）
第四章逻辑结构设计
4.1逻辑设计的任务与目标
以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。
具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）、数据处理（画出系统功能模块图）两大任务。
4.2数据组织
4.2.1将E-R图转换为关系模型
实体型转换为关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
对于实体间的联系则有以下不同的情况：
1、一个m：
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
2、一个1：
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
3、一个1：
1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
4、具有相同码的关系模式可合并。
由于顾客类别与顾客、馆室与桌游的联系方式是1:
n（一对多），可以将其之间的联系与n端实体顾客、桌游合并，管
升级会员 