失物招领系统数据库设计.docx
《失物招领系统数据库设计.docx》由会员分享，可在线阅读，更多相关《失物招领系统数据库设计.docx（19页珍藏版）》请在冰豆网上搜索。
失物招领系统数据库设计
失物招领系统数据库设计
一、系统需求分析
（一）问题背景
现今社会生活中，随着人们生活需求的日益多元化，人们所持有的物质资源也随之丰富，最直观的表现就是人们所拥有的物品无论从种类还是数量上都大幅增加，这就造成了人们对自己所有的物品在看管方面难度的加大，再加之日益加快的生活节奏，就更导致了人们遗落、丢失物品的情况时有发生。
这种现象在面积相对较小，而人口特别密集的大学校园来说更是屡见不鲜。
老师和同学们时常丢失个人物品，如书籍、手机、钱包、一卡通等现象时有发生。
经过调查发现，失主往往因为不能及时的找回失物而造成许多麻烦和不少的损失（像许多同学因为丢失一卡通而造成了用餐、进入图书馆、借书等许多不便）。
另一方面，物品的拾取者也因为没用取得失主的联系方式而不能及时的把拾取物交还到失主手上。
而传统的失物招领服务中心，采用的还是拾取者上交、手工备案、人工查询的方式。
但是随之物品的增多这种管理方式的工作量不断加大，这种做法就存在费时费力、缺乏时效性、不利于调动拾取者积极性等缺点。
基于以上分析，我们认为建立一个网上失物招领系统是非常必要的。
一方面，一旦网站建立好之后，拾到失物的同学可以在第一时间将失物信息发布到网上，而不是找张纸写上“失物招领”四个大字后贴到公告栏。
另一方面，有一个系统处理失物信息，就减少了人工处理的工作量。
（二）系统总体目标
建立本失物招领系统是为了通过拾主对拾物信息的录入和发布，以方便失主对自己所失物品的查询，一旦查询到自己所丢物品，失主可从系统中获得拾主的联系方式，以方便自己取回失物。
如果失主没有查询到自己所丢物品信息，也可以发布丢失物品信息。
这样，本系统旨在建立失物、失主、拾取三者之间的桥梁关系，从而使失主能及时有效的从拾取者手中取回自己所丢失的物品。
（三）系统主要功能
1、及时收集、录入、存储失主的失物信息，拾取者的拾物信息以及失主和拾取者的联系方式等信息。
2、物品信息的查询功能。
3、定期更新物品信息，注销已完成取回的物品记录。
系统（网站）运行的流程图如下：
失物招领系统顶层数据流程图：
失物招领系统第一层数据流程图：
二、概念结构设计
根据前面对系统进行的分析，已经初步了解了排课系统的数据处理流程，找出与系统有关的各个实体及其相互联系如下：
（一）标示实体集：
拾主、失主、拾物、失物。
（二）标示联系集：
拾主和拾物：
每位拾主可以捡到多个物品，存在“拾得”的关系：
1:
N
失主和失物：
每位失主可以捡到多个物品，存在“丢失”的关系：
1:
N
拾主和失主：
失主通过系统查询的所丢的东西，并在系统中得到拾到自己所丢物品的拾主的联系方式，与拾主联系找回自己所丢之物。
（三）标示属性集
拾主（一卡通号，姓名，性别，联系方式）
拾得（拾主一卡通号，拾得物品编号，拾得时间，拾得地点）
拾得书本（编号，名称，作者，描述）
拾得U盘（编号，品牌，大小，描述）
拾得钱包（编号，颜色，内容物，描述）
拾得其他（编号，名称，描述）
失主（一卡通号，姓名，性别，联系方式）
丢失（失主一卡通号，丢失物品编号，丢失时间，丢失地点）
丢失书本（编号，名称，作者，描述）
丢失U盘（编号，品牌，大小，描述）
丢失钱包（编号，颜色，内容物，描述）
丢失其他（编号，名称，描述）
找回失物（拾物编号，拾主一卡通号，失主一卡通号）
三、逻辑结构设计
（一）初始关系模式
根据上面的E—R图，我们把它转换成数据模型，如下：
1）拾主实体可以转化成如下的关系模式，其中一卡通号为拾主关系的主键：
拾主（一卡通号，姓名，性别，联系方式）
2）拾得这一联系（拾主与所拾物品1：
n的联系）可以转化如下关系（其中拾主一卡通号和所拾物品编号共同组成该关系的主键）：
拾得（拾主一卡通号，拾得物品编号，拾得时间，拾得地点）
3）对于所拾物品这一实体，由于这里有一个泛化/特化的关系，这里采用将每个子实体建立成为一个关系的方法，如下（加下划线的为主键）：
拾得书本（编号，名称，作者，描述）
拾得U盘（编号，品牌，大小，描述）
拾得钱包（编号，颜色，内容物，描述）
拾得其他（编号，名称，描述）
3）对于找回失物这一联系（拾主与失主1：
1的联系），分解成的关系（这是一个ALLkey的关系）为：
找回失物（拾物编号，拾主一卡通号，失主一卡通号）
4）对于失主这边的关系模式基本与拾主差不多，在此不再赘述，罗列如下（加下划线的为主键）：
失主（一卡通号，姓名，性别，联系方式）
丢失（失主一卡通号，丢失物品编号，丢失时间，丢失地点）
丢失书本（编号，名称，作者，描述）
丢失U盘（编号，品牌，大小，描述）
丢失钱包（编号，颜色，内容物，描述）
丢失其他（编号，名称，描述）
（二）数据模型的规范化
通过对E-R图的讨论分析，并将E-R图转换成相应的关系模式后，我们对以上关系做进一步的分析，得出如下关系模式中的函数依赖集：
1.拾主模式：
一卡通号姓名、性别、联系方式；
2.失主模式：
一卡通号姓名、性别、联系方式；
3.拾得模式：
一卡通号，物品编号拾到时间、拾到地点；
4.拾得书本模式：
编号名称、作者、描述；
5.拾得U盘模式：
编号品牌、大小、描述；
6.拾得钱包模式：
编号颜色、内容物、描述；
7.拾得其他模式：
编号名称、描述；
8.丢失模式：
失主一卡通号、丢失物品编号丢失时间、丢失地点；
9.丢失书本模式：
编号名称、作者、描述；
10.丢失钱包模式：
编号颜色、内容物、描述；
11.丢失U盘模式：
编号品牌、大小、描述；
由于在做概念模式之前我们已经考虑到了关系模式的优化问题，所以至此，所有的关系模式都已经达到了3NF，符合系统要求。
（三）调整后的关系模式的在数据库中具体实现
Finder（拾主）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FrCdid
Char（6）
Notnull
Primarykey
拾主一卡通号
Frname
Varchar（8）
Notnull
拾主姓名
Frsex
Char
（2）
Notnull
拾主性别
Frphone
Varchar（13）
Notnull
拾主联系方式
Find（拾得）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FrCdid
char（6）
Notnull
Primarykey
拾主一卡通编号
Fdid
Char（4）
Notnull
物品编号
Fdtime
datetime
Notnull
拾到时间
Fdplace
Varchar（20）
Notnull
拾到地点
FBook（书）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FBid
自动增长类型
Notnull
Primarykey
编号
FBname
Varchar（20）
Notnull
书本姓名
FBauthor
Varchar（20）
Notnull
书本作者
FBdescribe
Varchar（50）
描述
说明:
拾到书本的编号为自动编号,且编号采用层次编号方法例如:
编号11001,左起第一位的“1”表示是拾到的物品，第二个“1”是表示书本，后面三位为流水号。
FWallet（拾得钱包）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FWid
自动增长类型
Notnull
Primarykey
编号
FWcolor
Varchar（8）
Notnull
钱包颜色
FWinclude
Varchar（30）
Notnull
钱包内物品
FWdescribe
Varchar（50）
描述
说明:
拾到钱包的编号为自动编号,且编号采用层次编号方法例如:
编号14001,左起第一位“1”表示是拾到的物品，第一个“4”是表示钱包，后面三位为流水号。
FUdisk（拾得U盘）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FUid
自动增长类型
Notnull
Primarykey
编号
FUname
Varchar（10）
Notnull
U盘品牌
FUsize
Varchar（10）
Notnull
U盘大小
FWdescribe
Varchar（50）
描述
说明:
拾到U盘的编号为自动编号,且编号采用层次编号方法例如:
编号13001,左起第一位“1”表示是拾到的物品，第一个“3”是表示U盘，后面三位为流水号。
FOther（拾得其他物品）表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FOid
自动增长类型
Notnull
Primarykey
物品编号
FOname
Varchar（10）
Notnull
物品名称
FOdecide
Varchar（50）
Notnull
物品描述
说明:
拾到U盘的编号为自动编号,且编号采用层次编号方法例如:
编号12001,左起第一位“1”表示是拾到的物品，第一个“2”是表示U盘，后面三位为流水号。
ReBack表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
FrCdid
char（6）
Notnull
Primarykey
拾主一卡通编号
Lrid
char（6）
Notnull
失主一卡通号
Fdid
char（4）
Notnull
拾物编号
Loser表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
Lrid
char（6）
Notnull
Primarykey
失主一卡通号
Lrname
Varchar（8）
Notnull
失主姓名
Lrsex
Char
（2）
Notnull
失主性别
Lrphone
Varchar（13）
Notnull
失主联系方式
Lose表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
Lrid
Char（6）
Notnull
Primarykey
失主一卡通号
Lsid
Char（4）
Notnull
失物编号
Lsplace
Varchar（20）
Notnull
丢失地点
Lstime
datetime
Notnull
丢失日期
LBook表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
LBid
自动增长类型
Notnull
Primarykey
编号
LBname
Varchar（20）
Notnull
书本姓名
LBauthor
Varchar（20）
Notnull
书本作者
LBdescribe
Varchar（50）
描述
说明:
丢失物品的编号方式同拾到物品，只是在编号方法上左起第一位用“2”表示是丢失物品，例如:
编号21001,表示丢失书本的第一条记录。
LWallet表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
LWid
自动增长类型
Notnull
Primarykey
编号
LWcolor
Varchar（8）
Notnull
钱包颜色
LWinclude
Varchar（30）
Notnull
钱包内物品
LWdescribe
Varchar（50）
描述
LUdisk表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
LUid
自动增长类型
Notnull
Primarykey
编号
LUname
Varchar（10）
Notnull
U盘品牌
LUsize
Varchar（10）
Notnull
U盘大小
LUdescribe
Varchar（50）
描述
LOther表：
字段名
数据类型（精度范围）
空/非空
约束条件
说明
LOid
自动增长类型
Notnull
Primarykey
物品编号
LOname
Varchar（10）
Notnull
物品名称
LOdecide
Varchar（30）
Notnull
物品描述
各个关系的联系是:
四、物理结构设计
（一）数据库系统选型
操作系统采用微软的Windows7和Windowsxpprofessional。
数据库管理系统采用微软企业的SQLServer2005。
数据库系统的模式结构采用关系数据库，并采用B/S（浏览器/服务器）结构建设网站，开发工具采用VisualStudio2008+dreamweaver8。
（二）索引的设置
根据对对失物招领系统的分析，由于该系统的一个很大功能是为同学们提供失物的检索和拾物的发布功能我们认为为了提高查询速度，可以对经常要查询的字段设置索引，具体如下：
1、针对拾主表，为其一卡通号建立唯一索引。
2、针对所拾物品表，为每类物品的名称建立聚簇索引（因为检索可能经常用的物品名称）；并为每类物品的编号建立唯一索引。
3、针对失主表，为其一卡通号建立唯一索引。
4、针对所失物品表，为每类失物的名称建立聚簇索引（因为检索可能经常用的物品名称）；并为每类失物的编号建立唯一索引。
（三）安全性和用户权限设计
1、安全性设计
由于我们这个系统是一种B/S模式的结构，如果真的付诸实践，数据库将存放在远程服务器上，那么数据库的安全性将变得尤为重要，基于此，我们将具体采取以下措施保护数据库的安全：
（1）、设计用户权限，管理数据库
任何进入该系统的访客要想能够对数据库的相关内容进行操作（包括发布拾物或失物的信息，以及对所发布的信息的修改），必须注册成为该系统（网站）的会员，每次登陆都必须输入用户名和密码，验证通过后方进行相关操作，这样通过管理不同用户对数据库的操作权限从而达到保证数据库的安全。
（2）、定期进行数据库备份，以备数据丢失
针对失物招领系统的数据流量并不太大的状况，我们采取对数据库每周星期天进行一次完全备份，然后在接下来的六天里只对当天新增的或被修改过的数据进行差异备份。
这样做的好处是：
首先，它无需每天都对系统做完全备份，因此备份所需时间短，并节省了磁带空间，其次，它的灾难恢复也很方便。
系统管理员只需两盘磁带，即星期天的完全备份磁带与灾难发生前一天的差异备份磁带，就可以将系统恢复。
另外，我们将设在每月底进行一次完全备份，每年底进行一次全备份。
2、用户权限设计
由于我们该系统是基于网站B/S结构，系统的访问人员大致会有三类：
管理员、网站会员、普通访客。
针对不同的用户我们将设计不同的权限。
具体来说，只有网站的维护人员（管理员）可以对数据库做任何查询、修改、删除等；注册用户可以发布信息（对数据库的插入）、修改自己发布的信息（对数据库的修改）。
查询物品信息（对数据库的查询）。
非注册用户只能查询物品信息（对数据库的查询）。
用户权限
查询物品信息
发布物品信息
修改物品信息
管理员
√
√
√
注册用户
√
√（只是自己发布的信息）
√（只是自己发布的信息）
非注册用户
√
×
×
五、系统实现描述
我们的系统采用Dreamweaver8制作前台网站，并实现了前台与数据库的链接，下面是几个主要界面的截图：
1、网站首页界面：
2、信息发布选择界面：
3、物品信息录入界面
六、小组成员介绍及分工
（一）、小组介绍
组名:
Dateboys
组长：
李文涛
成员：
宋相恒、杨峰、于群、俞曹熠
（二）、任务分配
成员
工作任务
李文涛
概念结构设计、物理结构设计、总结报告编写等贯穿数据库系统设计的各方面的工作
宋相恒
概念结构设计、系统实现、网站页面设计等技术实践性工作
杨峰
逻辑结构设计、协助并配合组长进行各个过程的工作，如数据库建立、存储过程的编写等
于群
项目选定、概念结构设计、需求分析、以及相关的文字编纂工作
俞曹熠
参与项目讨论、协助各个组员工作
（三）、过程总结
本小组在组长李文涛的带动下，积极讨论，努力钻研，充分调动所学知识，以客观实际为标准，以专业技术为要求，本着认真、求实的态度，合理利用时间、相关资料、以及软硬件设施等有利资源。
在针对成员具体情况的前提下合理分工，提高工作效率，使各个过程有条不紊的进行。
在具体的项目设计与实施的过程中，使大家获得了一次难得的机会，用以检验自己所学的数据库系统的相关知识，使我们认识到了“学”与“致用”之间的距离。
同时，使我们认识到了团队合作的重要性，并且对今后在数据库方向上的工作有了初步概念。
升级会员 