失物招领系统数据库设计文档格式.docx
《失物招领系统数据库设计文档格式.docx》由会员分享,可在线阅读,更多相关《失物招领系统数据库设计文档格式.docx(21页珍藏版)》请在冰点文库上搜索。
(二)标示联系集:
拾主和拾物:
每位拾主可以捡到多个物品,存在“拾得”的关系:
1:
N
失主和失物:
每位失主可以捡到多个物品,存在“丢失”的关系:
拾主和失主:
失主通过系统查询的所丢的东西,并在系统中得到拾到自己所丢物品的拾主的联系方式,与拾主联系找回自己所丢之物。
(三)标示属性集
拾主(一卡通号,姓名,性别,联系方式)
拾得(拾主一卡通号,拾得物品编号,拾得时间,拾得地点)
拾得书本(编号,名称,作者,描述)
拾得U盘(编号,品牌,大小,描述)
拾得钱包(编号,颜色,内容物,描述)
拾得其他(编号,名称,描述)
失主(一卡通号,姓名,性别,联系方式)
丢失(失主一卡通号,丢失物品编号,丢失时间,丢失地点)
丢失书本(编号,名称,作者,描述)
丢失U盘(编号,品牌,大小,描述)
丢失钱包(编号,颜色,内容物,描述)
丢失其他(编号,名称,描述)
找回失物(拾物编号,拾主一卡通号,失主一卡通号)
三、逻辑结构设计
(一)初始关系模式
根据上面的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
组长:
李文涛
成员:
宋相恒、杨峰、于群、俞曹熠
(二)、任务分配
成员
工作任务
概念结构设计、物理结构设计、总结报告编写等贯穿数据库系统设计的各方面的工作
宋相恒
概念结构设计、系统实现、网站页面设计等技术实践性工作
杨峰
逻辑结构设计、协助并配合组长进行各个过程的工作,如数据库建立、存储过程的编写等
于群
项目选定、概念结构设计、需求分析、以及相关的文字编纂工作
俞曹熠
参与项目讨论、协助各个组员工作
(三)、过程总结
本小组在组长李文涛的带动下,积极讨论,努力钻研,充分调动所学知识,以客观实际为标准,以专业技术为要求,本着认真、求实的态度,合理利用时间、相关资料、以及软硬件设施等有利资源。
在针对成员具体情况的前提下合理分工,提高工作效率,使各个过程有条不紊的进行。
在具体的项目设计与实施的过程中,使大家获得了一次难得的机会,用以检验自己所学的数据库系统的相关知识,使我们认识到了“学”与“致用”之间的距离。
同时,使我们认识到了团队合作的重要性,并且对今后在数据库方向上的工作有了初步概念。
.