失物招领系统数据库设计

目录

失物招领系统数据库设计 ················································ 3 一、系统需求分析 ······················································· 3 （一）问题背景 ························································ 3 （二）系统总体目标 ··················································· 3 （三）系统主要功能 ··················································· 4 二、概念结构设计 ······················································· 6 （一）标示实体集 ······················································ 7 （二）标示联系集： ··················································· 7 （三）标示属性集 ······················································ 7 三、逻辑结构设计 ······················································ 11 （一）初始关系模式 ·················································· 11 （二）数据模型的规范化 ·············································· 12 （三）调整后的关系模式的在数据库中具体实现 ······················· 13 四、物理结构设计 ······················································ 21 （一）数据库系统选型 ················································ 21 （二）索引的设置 ····················································· 21 （三）安全性和用户权限设计 ········································· 21

1 / 26

失物招领系统数据库设计

五、系统实现描述 ······················································ 23 六、小组成员介绍与分工 ··············································· 25 （一）、小组介绍 ······················································ 25 （二）、任务分配 ······················································ 25

2 / 26

失物招领系统数据库设计

失物招领系统数据库设计

一、系统需求分析 （一）问题背景

现今社会生活中，随着人们生活需求的日益多元化，人们所持有的物质资源也随之丰富，最直观的表现就是人们所拥有的物品无论从种类还是数量上都大幅增加，这就造成了人们对自己所有的物品在看管方面难度的加大，再加之日益加快的生活节奏，就更导致了人们遗落、丢失物品的情况时有发生。这种现象在面积相对较小，而人口特别密集的大学校园来说更是屡见不鲜。老师和同学们时常丢失个人物品， 如书籍、手机、钱包、一卡通等现象时有发生。

经过调查发现，失主往往因为不能与时的找回失物而造成许多麻烦和不少的损失（像许多同学因为丢失一卡通而造成了用餐、进入图书馆、借书等许多不便）。另一方面，物品的拾取者也因为没用取得失主的联系方式而不能与时的把拾取物交还到失主手上。而传统的失物招领服务中心，采用的还是拾取者上交、手工备案、人工查询的方式。但是随之物品的增多这种管理方式的工作量不断加大，这种做法就存在费时费力、缺乏时效性、不利于调动拾取者积极性等缺点。

基于以上分析，我们认为建立一个网上失物招领系统是非常必要的。一方面，一旦网站建立好之后，拾到失物的同学可以在第一时间将失物信息发布到网上，而不是找张纸写上“失物招领”四个大字后贴到公告栏。另一方面，有一个系统处理失物信息，就减少了人工处理的工作量。 （二）系统总体目标

建立本失物招领系统是为了通过拾主对拾物信息的录入和发布，以方便失主对自己所失物品的查询，一旦查询到自己所丢物品，失主可从系统中获得拾主的

3 / 26

失物招领系统数据库设计

联系方式，以方便自己取回失物。如果失主没有查询到自己所丢物品信息，也可以发布丢失物品信息。这样，本系统旨在建立失物、失主、拾取三者之间的桥梁关系，从而使失主能与时有效的从拾取者手中取回自己所丢失的物品。 （三）系统主要功能

1、与时收集、录入、存储失主的失物信息，拾取者的拾物信息以与失主和拾取者的联系方式等信息。

2、物品信息的查询功能。

3、定期更新物品信息，注销已完成取回的物品记录。 系统（网站）运行的流程图如下：

4 / 26

失物招领系统数据库设计

网站 浏览者 会员？ 是 登录 否 注册？ 是 否 注册 修改自己所发布的信息 失物已归还，删除所发布信息 拾物/失物信息浏览 否 找到貌似自己丢失的物品 是 获得发布者的联系信息 结束退出

失物招领系统顶层数据流程图：

5 / 26

失物招领系统数据库设计

P1 失物信息处理系统 拾主 所拾物品 信息F1 在库物品信息F2 拾主联系方式F3 失物登记信息F5 失主 失物交接信息

失物招领系统第一层数据流程图：

P1.0 拾主 所拾物品 信息F1 记录拾得物品信息 F1 失物交接信息 所失物品 信息F2 D1 失物信息数据库 F2 P2.0 检索在库拾主联系方式F4 /无此拾物信息F5 物品信息 失物信息失主 失物登记信息（失物未找到）

二、概念结构设计

根据前面对系统进行的分析，已经初步了解了排课系统的数据处理流程，找

6 / 26

失物招领系统数据库设计

出与系统有关的各个实体与其相互联系如下： （一）标示实体集：拾主、失主、拾物、失物。 （二）标示联系集：

拾主和拾物：每位拾主可以捡到多个物品，存在“拾得”的关系：1:N 失主和失物：每位失主可以捡到多个物品，存在“丢失”的关系：1:N 拾主和失主：失主通过系统查询的所丢的东西，并在系统中得到拾到自己所丢物品的拾主的联系方式，与拾主联系找回自己所丢之物。 （三）标示属性集

拾主（一卡通号，姓名，性别，联系方式）

拾得（拾主一卡通号，拾得物品编号，拾得时间，拾得地点） 拾得书本（编号，名称，作者，描述） 拾得U盘（编号，品牌，大小，描述） 拾得钱包（编号，颜色，内容物，描述） 拾得其他（编号，名称，描述）

失主（一卡通号，姓名，性别，联系方式）

丢失（失主一卡通号，丢失物品编号，丢失时间，丢失地点） 丢失书本（编号，名称，作者，描述） 丢失U盘（编号，品牌，大小，描述） 丢失钱包（编号，颜色，内容物，描述） 丢失其他（编号，名称，描述）

7 / 26

失物招领系统数据库设计

找回失物（拾物编号，拾主一卡通号，失主一卡通号）

丢失地点 编号 性别 姓名 失主一卡通号 联系方式(QQ/电话) 一卡通号丢失时间 1 失主 丢失 n 失物 类别 丢失物品编号 描述 分图1 一卡通号 拾得时间 拾得地点 性别 拾主 姓名 联系方式(QQ/电话) 1 n 拾得 拾物 编号 类别 拾主一卡通号 分图2 拾得物品编号 描述 8 / 26

失物招领系统数据库设计

一卡通号 一卡通号性别 姓名 拾主 1 找回失物 1 失主 性别 姓名 拾主一卡通号 失物 联系方式(QQ/电话) 失主一卡通号 联系方式(QQ/电话) 分图3 9 / 26

失物招领系统数据库设计

物品编号 失主一卡通号 一卡通号失主 1 姓名 1 书本 联系方式(QQ/电话) 丢失时间 丢失地编号 丢失 n ISA 其他 性别 失物 名称 描述 U盘 失主一卡通号 拾主一卡通号 找回失物 名称 描述 作者 钱包 大小 描述 颜色 描述 内容物 品牌 拾物编号 颜色 品牌 描述 大小 描述 内容物 名称 描述 作者 钱包 U盘 1 书本 其他 一卡通号 ISA 名称 n 拾物 编号 拾主一卡通号 拾得地点 性别 姓名 拾主 1 拾得 描述 联系方式(QQ/电话) 物品编号 10 / 26 拾得时间 失物招领系统数据库设计

三、逻辑结构设计 （一）初始关系模式

根据上面的E—R图，我们把它转换成数据模型，如下：

1）拾主实体可以转化成如下的关系模式，其中一卡通号为拾主关系的主键：

拾主（一卡通号，姓名，性别，联系方式）

2）拾得这一联系（拾主与所拾物品1：n 的联系）可以转化如下关系（其中拾主

一卡通号和所拾物品编号共同组成该关系的主键）：

拾得（拾主一卡通号，拾得物品编号，拾得时间，拾得地点）

3）对于所拾物品这一实体，由于这里有一个泛化/特化的关系，这里采用将每个子实体建立成为一个关系的方法，如下（加下划线的为主键）：

拾得书本（编号，名称，作者，描述） 拾得U盘（编号，品牌，大小，描述） 拾得钱包（编号，颜色，内容物，描述） 拾得其他（编号，名称，描述）

3）对于找回失物这一联系（拾主与失主1：1的联系），分解成的关系（这是一

个ALLkey的关系）为：

找回失物（拾物编号，拾主一卡通号，失主一卡通号）

4）对于失主这边的关系模式基本与拾主差不多，在此不再赘述，罗列如下（加下

划线的为主键）：

失主（一卡通号，姓名，性别，联系方式）

丢失（失主一卡通号，丢失物品编号，丢失时间，丢失地点） 丢失书本（编号，名称，作者，描述）

11 / 26

失物招领系统数据库设计

丢失U盘（编号，品牌，大小，描述） 丢失钱包（编号，颜色，内容物，描述） 丢失其他（编号，名称，描述）

（二）数据模型的规范化

通过对E-R图的讨论分析，并将E-R图转换成相应的关系模式后，我们对以上关系做进一步的分析，得出如下关系模式中的函数依赖集：

1. 拾主模式：

一卡通号 姓名、性别、联系方式；

2. 失主模式：

一卡通号 姓名、性别、联系方式；

3. 拾得模式：

一卡通号，物品编号 拾到时间、拾到地点；

4. 拾得书本模式：

编号 名称、作者、描述；

5. 拾得U盘模式：

编号 品牌、大小、描述；

6. 拾得钱包模式：

编号 颜色、内容物、描述；

7. 拾得其他模式：

编号 名称、描述；

8. 丢失模式：

12 / 26

失物招领系统数据库设计

失主一卡通号、丢失物品编号 丢失时间、丢失地点；

9. 丢失书本模式：

编号 名称、作者、描述；

10. 丢失钱包模式：

编号 颜色、内容物、描述；

11. 丢失U盘模式：

编号 品牌、大小、描述；

由于在做概念模式之前我们已经考虑到了关系模式的优化问题，所以至此，所有的关系模式都已经达到了3NF，符合系统要求。

（三）调整后的关系模式的在数据库中具体实现

Finder(拾主)表： 字段名 数据类型（精度范围） FrCdid Char(6) Not null key Frname 8) Frsex Frphone Char(2) Varchar(Not null Not null 13 / 26

空/非空 约束条件 说明 Primary 拾主一卡通号 拾主姓名 Varchar(Not null 拾主性别 拾主联系 失物招领系统数据库设计

13) Find（拾得）表： 字段名 数据类型（精度范围） FrCdid char(6) Not null 方式 空/非空 约束条件 说明 Primary key 拾主一卡通编号 物品编号 拾到时间 拾到地点 Fdid Fdtime Fdplace 20) Char(4) datetime Varchar(Not null Not null Not null FBook（书）表： 字段名 数据类型（精度范围） FBid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 编号 FBname 20) FBauthor 20) FBdescribe Varchar(书本姓名 Varchar(Not null 书本作者 Varchar（50） 描述 说明:拾到书本的编号为自动编号,且编号采用层次编号方法例如:编号11001,

14 / 26

失物招领系统数据库设计

左起第一位的“1”表示是拾到的物品，第二个“1”是表示书本，后面三位为流水号。

FWallet(拾得钱包)表： 字段名 数据类型（精度范围） FWid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 编号 FWcolor 8) FWinclude FWdescribe 30) Varchar(钱包颜色 Varchar(Not null 钱包内物品 Varchar（50） 描述 说明:拾到钱包的编号为自动编号,且编号采用层次编号方法例如:编号14001,左起第一位“1”表示是拾到的物品，第一个“4”是表示钱包，后面三位为流水号。

FUdisk(拾得U盘)表： 字段名 数据类型（精度范围） FUid 空/非空 约束条件 说明 自动增长类型 Not null key Not null 15 / 26

Primary 编号 FUname Varchar(U盘品牌 失物招领系统数据库设计

10) FUsize 10) FWdescribe Varchar（50） 说明:拾到U盘的编号为自动编号,且编号采用层次编号方法例如:编号13001,左起第一位“1”表示是拾到的物品，第一个“3”是表示U盘，后面三位为流水号。

Varchar(Not null U盘大小 描述 FOther（拾得其他物品）表： 字段名 数据类型（精度范围） FOid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 物品编号 FOname 10) FOdecide 50) Varchar(物品名称 Varchar(Not null 物品描述 说明:拾到U盘的编号为自动编号,且编号采用层次编号方法例如:编号12001,左起第一位“1”表示是拾到的物品，第一个“2”是表示U盘，后面三位为流水号。

16 / 26

失物招领系统数据库设计

ReBack表： 字段名 数据类型（精度范围） FrCdid char(6) Not null 空/非空 约束条件 说明 拾主一卡通编号 失主一卡通号 Primary key Lrid char(6) Not null Fdid

char(4) Not null 拾物编号 Loser表： 字段名 数据类型（精度范围） Lrid char(6) Not null key Lrname 8) Lrsex Lrphone 13)

空/非空 约束条件 说明 Primary 失主一卡通号 失主姓名 Varchar(Not null Char(2) Varchar(Not null Not null 失主性别 失主联系方式 Lose表：

17 / 26

失物招领系统数据库设计

字段名 数据类型（精度范围） Lrid Char(6) Not null 空/非空 约束条件 说明 Primary key 失主一卡通号 失物编号 丢失地点 Lsid Lsplace 20) Lstime

Char(4) Varchar(Not null Not null datetime Not null 丢失日期 LBook表： 字段名 数据类型（精度范围） LBid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 编号 LBname 20) LBauthor 20) LBdescribe Varchar(书本姓名 Varchar(Not null 书本作者 Varchar（50） 描述 说明:丢失物品的编号方式同拾到物品，只是在编号方法上左起第一位用“2”表示是丢失物品，例如:编号21001,表示丢失书本的第一条记录。

18 / 26

失物招领系统数据库设计

LWallet表： 字段名 数据类型（精度范围） LWid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 编号 LWcolor 8) LWinclude LWdescribe

Varchar(钱包颜色 Varchar(30) Varchar（50） Not null 钱包内物品 描述 LUdisk表： 字段名 数据类型（精度范围） LUid 空/非空 约束条件 说明 自动增长类型 Not null key Not null Primary 编号 LUname 10) LUsize 10) Varchar(U盘品牌 Varchar(Not null U盘大小 19 / 26

失物招领系统数据库设计

LUdescribe Varchar（50） LOther表： 字段名 数据类型（精度范围） LOid 空/非空 约束条件 说明 描述 自动增长类型 Not null Primary key 物品编号 LOname 10) LOdecide

Varchar(Not null 物品名称 Varchar(30) Not null 物品描述 各个关系的联系是:

20 / 26

失物招领系统数据库设计

四、物理结构设计 （一）数据库系统选型

操作系统采用微软的Windows 7和Windows xp professional。数据库管理系统采用微软企业的SQL Server 2005 。数据库系统的模式结构采用关系数据库，并采用B/S（浏览器/服务器）结构建设网站，开发工具采用Visual Studio 2008 + dreamweaver 8。 （二）索引的设置

根据对对失物招领系统的分析，由于该系统的一个很大功能是为同学们提供失物的检索和拾物的发布功能我们认为为了提高查询速度，可以对经常要查询的字段设置索引，具体如下：

1、针对拾主表，为其一卡通号建立唯一索引。

2、针对所拾物品表，为每类物品的名称建立聚簇索引（因为检索可能经常用

的物品名称）；并为每类物品的编号建立唯一索引。

3、针对失主表，为其一卡通号建立唯一索引。

4、针对所失物品表，为每类失物的名称建立聚簇索引（因为检索可能经常用

的物品名称）；并为每类失物的编号建立唯一索引。 （三）安全性和用户权限设计

1、安全性设计

由于我们这个系统是一种B/S模式的结构，如果真的付诸实践，数据库将存放在远程服务器上，那么数据库的安全性将变得尤为重要，基于此，我们将具体采取以下措施保护数据库的安全：

（1）、设计用户权限，管理数据库

21 / 26

失物招领系统数据库设计

任何进入该系统的访客要想能够对数据库的相关内容进行操作（包括发布拾物或失物的信息，以与对所发布的信息的修改），必须注册成为该系统（网站）的会员，每次登陆都必须输入用户名和密码，验证通过后方进行相关操作，这样通过管理不同用户对数据库的操作权限从而达到保证数据库的安全。

（2）、定期进行数据库备份，以备数据丢失

针对失物招领系统的数据流量并不太大的状况，我们采取对数据库每周星期天进行一次完全备份，然后在接下来的六天里只对当天新增的或被修改过的数据进行差异备份。这样做的好处是：首先，它无需每天都对系统做完全备份，因此备份所需时间短，并节省了磁带空间，其次，它的灾难恢复也很方便。系统管理员只需两盘磁带，即星期天的完全备份磁带与灾难发生前一天的差异备份磁带，就可以将系统恢复。

另外，我们将设在每月底进行一次完全备份，每年底进行一次全备份。 2、用户权限设计

由于我们该系统是基于网站B/S结构，系统的访问人员大致会有三类：管理员、网站会员、普通访客。针对不同的用户我们将设计不同的权限。具体来说，只有网站的维护人员（管理员）可以对数据库做任何查询、修改、删除等；注册用户可以发布信息（对数据库的插入）、修改自己发布的信息（对数据库的修改）。查询物品信息（对数据库的查询）。非注册用户只能查询物品信息（对数据库的查询）。

用户 权限 查询物品信息 发布物品信息 管理员 注册用户 √ √ √ 修改物品信息 √ √(只是自己发布的信息) √(只是自己发布的信息) 22 / 26

失物招领系统数据库设计

非注册用户

√ × × 五、系统实现描述

我们的系统采用Dreamweaver 8制作前台网站，并实现了前台与数据库的链接，下面是几个主要界面的截图：

1、网站首页界面：

2、信息发布选择界面：

23 / 26

失物招领系统数据库设计

3、物品信息录入界面

24 / 26

失物招领系统数据库设计

六、小组成员介绍与分工 （一）、小组介绍

组名:Date boys 组长：李文涛

成员：宋相恒、杨峰、于群、俞曹熠 （二）、任务分配 成 员 李文涛 工 作 任 务 概念结构设计、物理结构设计、总结报告编写等贯穿数据库系统设计的各方面的工作 宋相恒 杨 峰 概念结构设计、系统实现、网站页面设计等技术实践性工作 逻辑结构设计、协助并配合组长进行各个过程的工作，如数据库建立、存储过程的编写等 于 群 俞曹熠

项目选定、概念结构设计、需求分析、以与相关的文字编纂工作 参与项目讨论、协助各个组员工作 （三）、过程总结

本小组在组长李文涛的带动下，积极讨论，努力钻研，充分调动所学知识，以客观实际为标准，以专业技术为要求，本着认真、求实的态度，合理利用时间、相关资料、以与软硬件设施等有利资源。在针对成员具体情况的前提下合理分工，提高工作效率，使各个过程有条不紊的进行。

在具体的项目设计与实施的过程中，使大家获得了一次难得的机会，用以检验自己所学的数据库系统的相关知识，使我们认识到了“学”与“致用”之间的

25 / 26

失物招领系统数据库设计

距离。同时，使我们认识到了团队合作的重要性，并且对今后在数据库方向上的工作有了初步概念。

26 / 26