失物招领系统数据库设计Word下载.doc
- 文档编号:261725
- 上传时间:2023-04-28
- 格式:DOC
- 页数:26
- 大小:917.50KB
失物招领系统数据库设计Word下载.doc
《失物招领系统数据库设计Word下载.doc》由会员分享,可在线阅读,更多相关《失物招领系统数据库设计Word下载.doc(26页珍藏版)》请在冰点文库上搜索。
建立本失物招领系统是为了通过拾主对拾物信息的录入和发布,以方便失主对自己所失物品的查询,一旦查询到自己所丢物品,失主可从系统中获得拾主的联系方式,以方便自己取回失物。
如果失主没有查询到自己所丢物品信息,也可以发布丢失物品信息。
这样,本系统旨在建立失物、失主、拾取三者之间的桥梁关系,从而使失主能与时有效的从拾取者手中取回自己所丢失的物品。
(三)系统主要功能
1、与时收集、录入、存储失主的失物信息,拾取者的拾物信息以与失主和拾取者的联系方式等信息。
2、物品信息的查询功能。
3、定期更新物品信息,注销已完成取回的物品记录。
系统(网站)运行的流程图如下:
否
是
网站
浏览者
会员?
注册?
登录
注册
修改自己所发布的信息
拾物/失物信息浏览
找到貌似自己丢失的物品
获得发布者的联系信息
结束退出
失物已归还,删除所发布信息
失物招领系统顶层数据流程图:
失物交接信息
拾主联系方式F3
失物登记信息F5
在库物品信息F2
所拾物品
信息F1
拾主
失主
P1
失物信息处理系统
失物招领系统第一层数据流程图:
失物登记信息(失物未找到)
所失物品
信息F2
F1
拾主联系方式F4/无此拾物信息F5
拾主
P1.0
记录拾得物品信息
D1
失物信息数据库
失主
P2.0
检索在库物品信息
F2
失物信息F3
二、概念结构设计
根据前面对系统进行的分析,已经初步了解了排课系统的数据处理流程,找出与系统有关的各个实体与其相互联系如下:
(一)标示实体集:
拾主、失主、拾物、失物。
拾主和拾物:
每位拾主可以捡到多个物品,存在“拾得”的关系:
1:
N
失主和失物:
每位失主可以捡到多个物品,存在“丢失”的关系:
拾主和失主:
失主通过系统查询的所丢的东西,并在系统中得到拾到自己所丢物品的拾主的联系方式,与拾主联系找回自己所丢之物。
(三)标示属性集
拾主(一卡通号,姓名,性别,联系方式)
拾得(拾主一卡通号,拾得物品编号,拾得时间,拾得地点)
拾得书本(编号,名称,作者,描述)
拾得U盘(编号,品牌,大小,描述)
拾得钱包(编号,颜色,内容物,描述)
拾得其他(编号,名称,描述)
失主(一卡通号,姓名,性别,联系方式)
丢失(失主一卡通号,丢失物品编号,丢失时间,丢失地点)
丢失书本(编号,名称,作者,描述)
丢失U盘(编号,品牌,大小,描述)
丢失钱包(编号,颜色,内容物,描述)
丢失其他(编号,名称,描述)
找回失物(拾物编号,拾主一卡通号,失主一卡通号)
1
n
一卡通号通号
联系方式(QQ/电话)
姓名
性别
失物
丢失
丢失物品编号
丢失时间
丢失地点
失主一卡通号
编号
类别
分图1
描述
n
一卡通号
拾物
拾得
拾得物品编号
拾得时间
拾得地点
拾主一卡通号
分图2
1
找回失物
分图3
一卡通号号
物品编号
拾物编号
书本
U盘
钱包
其他
名称
作者
颜色
品牌
大小
ISA阿
内容物
ISA
三、逻辑结构设计
(一)初始关系模式
根据上面的E—R图,我们把它转换成数据模型,如下:
1)拾主实体可以转化成如下的关系模式,其中一卡通号为拾主关系的主键:
2)拾得这一联系(拾主与所拾物品1:
n的联系)可以转化如下关系(其中拾主一卡通号和所拾物品编号共同组成该关系的主键):
拾得(拾主一卡通号,拾得物品编号,拾得时间,拾得地点)
3)对于所拾物品这一实体,由于这里有一个泛化/特化的关系,这里采用将每个子实体建立成为一个关系的方法,如下(加下划线的为主键):
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)
拾主姓名
Frsex
Char
(2)
拾主性别
Frphone
Varchar(13)
拾主联系方式
Find(拾得)表:
char(6)
拾主一卡通编号
Fdid
Char(4)
Fdtime
datetime
拾到时间
Fdplace
Varchar(20)
拾到地点
FBook(书)表:
FBid
自动增长类型
FBname
书本姓名
FBauthor
书本作者
FBdescribe
Varchar(50)
说明:
拾到书本的编号为自动编号,且编号采用层次编号方法例如:
编号11001,左起第一位的“1”表示是拾到的物品,第二个“1”是表示书本,后面三位为流水号。
FWallet(拾得钱包)表:
FWid
FWcolor
Notnull
钱包颜色
FWinclude
Varchar(30)
钱包内物品
FWdescribe
拾到钱包的编号为自动编号,且编号采用层次编号方法例如:
编号14001,左起第一位“1”表示是拾到的物品,第一个“4”是表示钱包,后面三位为流水号。
FUdisk(拾得U盘)表:
FUid
FUname
Varchar(10)
U盘品牌
FUsize
U盘大小
拾到U盘的编号为自动编号,且编号采用层次编号方法例如:
编号13001,左起第一位“1”表示是拾到的物品,第一个“3”是表示U盘,后面三位为流水号。
FOther(拾得其他物品)表:
FOid
FOname
物品名称
FOdecide
物品描述
编号12001,左起第一位“1”表示是拾到的物品,第一个“2”是表示U盘,后面三位为流水号。
ReBack表:
Lrid
char(4)
Loser表:
Lrname
失主姓名
Lrsex
失主性别
Lrphone
失主联系方式
Lose表:
Lsid
失物编号
Lsplace
Lstime
丢失日期
LBook表:
LBid
LBname
LBauthor
LBdescribe
丢失物品的编号方式同拾到物品,只是在编号方法上左起第一位用“2”表示是丢失物品,例如:
编号21001,表示丢失书本的第一条记录。
LWallet表:
LWid
LWcolor
LWinclude
LWdescribe
LUdisk表:
LUid
LUname
LUsize
LUdescribe
LOther表:
LOid
Primarykey
LOname
LOdecide
各个关系的联系是:
四、物理结构设计
(一)数据库系统选型
操作系统采用微软的Windows7和Windowsxpprofessional。
数据库管理系统采用微软企业的SQLServer2005。
数据库系统的模式结构采用关系数据库,并采用B/S(浏览器/服务器)结构建设网站,开发工具采用VisualStudio2008+dreamweaver8。
(二)索引的设置
根据对对失物招领系统的分析,由于该系统的一个很大功能是为同学们提供失物的检索和拾物的发布功能我们认为为了提高查询速度,可以对经常要查询的字段设置索引,具体如下:
1、针对拾主表,为其一卡通号建立唯一索引。
2、针对所拾物品表,为每类物品的名称建立聚簇索引(因为检索可能经常用的物品名称);
并为每类物品的编号建立唯一索引。
3、针对失主表,为其一卡通号建立唯一索引。
4、针对所失物品表,为每类失物的名称建立聚簇索引(因为检索可能经常用的物品名称);
并为每类失物的编号建立唯一索引。
(三)安全性和用户权限设计
1、安全性设计
由于我们这个系统是一种B/S模式的结构,如果真的付诸实践,数据库将存放在远程服务器上,那么数据库的安全性将变得尤为重要,基于此,我们将具体采取以下措施保护数据库的安全:
(1)、设计用户权限,管理数据库
任何进入该系统的访客要想能够对数据库的相关内容进行操作(包括发布拾物或失物的信息,以与对所发布的信息的修改),必须注册成为该系统(网站)的会员,每次登陆都必须输入用户名和密码,验证通过后方进行相关操作,这样通过管理不同用户对数据库的操作权限从而达到保证数据库的安全。
(2)、定期进行数据库备份,以备数据丢失
针对失物招领系统的数据流量并不太大的状况,我们采取对数据库每周星期天进行一次完全备份,然后在接下来的六天里只对当天新增的或被修改过的数据进行差异备份。
这样做的好处是:
首先,它无需每天都对系统做完全备份,因此备份所需时间短,并节省了磁带空间,其次,它的灾难恢复也很方便。
系统管理员只需两盘磁带,即星期天的完全备份磁带与灾难发生前一天的差异备份磁带,就可以将系统恢复。
另外,我们将设在每月底进行一次完全备份,每年底进行一次全备份。
2、用户权限设计
由于我们该系统是基于网站B/S结构,系统的访问人员大致会有三类:
管理员、网站会员、普通访客。
针对不同的用户我们将设计不同的权限。
具体来说,只有网站的维护人员(管理员)可以对数据库做任何查询、修改、删除等;
注册用户可以发布信息(对数据库的插入)、修改自己发布的信息(对数据库的修改)。
查询物品信息(对数据库的查询)。
非注册用户只能查询物品信息(对数据库的查询)。
用户 权限
查询物品信息
发布物品信息
修改物品信息
管理员
√
注册用户
√(只是自己发布的信息)
非注册用户
×
五、系统实现描述
我们的系统采用Dreamweaver8制作前台网站,并实现了前台与数据库的链接,下面是几个主要界面的截图:
1、网站首页界面:
2、信息发布选择界面:
3、物品信息录入界面
六、小组成员介绍与分工
(一)、小组介绍
组名:
Dateboys
组长:
李文涛
成员:
宋相恒、杨峰、于群、俞曹熠
(二)、任务分配
成员
工作任务
概念结构设计、物理结构设计、总结报告编写等贯穿数据库系统设计的各方面的工作
宋相恒
概念结构设计、系统实现、网站页面设计等技术实践性工作
杨峰
逻辑结构设计、协助并配合组长进行各个过程的工作,如数据库建立、存储过程的编写等
于群
项目选定、概念结构设计、需求分析、以与相关的文字编纂工作
俞曹熠
参与项目讨论、协助各个组员工作
(三)、过程总结
本小组在组长李文涛的带动下,积极讨论,努力钻研,充分调动所学知识,以客观实际为标准,以专业技术为要求,本着认真、求实的态度,合理利用时间、相关资料、以与软硬件设施等有利资源。
在针对成员具体情况的前提下合理分工,提高工作效率,使各个过程有条不紊的进行。
在具体的项目设计与实施的过程中,使大家获得了一次难得的机会,用以检验自己所学的数据库系统的相关知识,使我们认识到了“学”与“致用”之间的距离。
同时,使我们认识到了团队合作的重要性,并且对今后在数据库方向上的工作有了初步概念。
26/26
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 失物招领 系统 数据库 设计