数据库总报告通讯录.docx
- 文档编号:1943899
- 上传时间:2023-05-02
- 格式:DOCX
- 页数:19
- 大小:837.32KB
数据库总报告通讯录.docx
《数据库总报告通讯录.docx》由会员分享,可在线阅读,更多相关《数据库总报告通讯录.docx(19页珍藏版)》请在冰点文库上搜索。
数据库总报告通讯录
《数据库系统课程设计》
课程报告
课题名称:
通讯录
课题负责人姓名:
熊建(学号):
1143041073
廖力1143041275
指导教师:
李川
评阅成绩:
评阅意见:
提交报告时间:
通讯录的设计与实现
熊建1143041073
摘要:
本程序的制作背景是基于数据库理论课程和实验实践课程的系统学习的基础上,以增加个人动手能力、实践开发能力、和巩固知识系统的学习为目的,由学生合作开发的一款个人资源管理系统。
本通讯录的功能为编辑(添加,删除,修改),查询等功能,简捷方便易操作。
本系统的开发工具为Delphi7和SQLServer,可在WindowsXP及Win7上运行。
通过本系统的开发,我们希望可以对数据库的各方面有更加系统深入的认识和理解。
关键词:
数据库设计ER图逻辑模型通讯录
一、系统规划与需求分析-------------------------------------------------
1.1需求分析阶段的目标与任务
通讯录有多个功能。
每个功能都建立在创建的实体和联系的上面,通过实体和联系来实现添加、删除、修改等操作。
通讯录的使用者通过其各自的实体来标识。
通过系统添加并存储每个用户的姓名、电话、出生年月及其通讯地址等,用户在变更信息的情况下就修改之前提供的通讯信息。
通讯录在记录个人信息的同时,顺便也保存好家庭住址和QQ号码,以便在未及时修改个人信息的情况下能有其他方式联系用户,做到数据的多元选择。
通讯录使用者在管理通讯录记录时,及时删除无用记录和信息并修改,让通讯录总体结构清晰自然。
1.1.1处理对象
通讯录信息:
联系人姓名、性别、关系、手机、座机、QQ号、Email、家庭住址、工作单位
1.1.2处理功能及要求
1.通讯录联系人的信息添加、修改、删除
2.查询功能
3.点击网格也能查看联系人的信息
1.1.3安全性和完整性要求
1.安全性要求
系统安全性要求体现在数据库安全性、信息安全性和系统平台的安全性等方面。
安全性先通过视图机制,不同的用户只能访问系统授权的视图,这样可提供系统数据一定程度上的安全性,再通过分配权限、设置权限级别来区别对待不同操作者对数据库的操作来提高数据库的安全性;系统平台的安全性体现在操作系统的安全性、计算机系统的安全性和网络体系的安全性等方面。
2.完整性要求
系统完整性要求系统中数据的正确性以及相容性。
可通过建立主、外键,使用check约束。
1.2需求分析阶段成果
1.2.1数据流图
通讯录数据流图
1.2.2数据字典
数据结构:
list
含义说明:
是通讯录的主体数据结构,定义了一个记录的有关信息
组成:
list_name,list_sex,list_mobile_number,list_age和list_QQ
数据项:
list_name
含义说明:
唯一标识每个记录
别名:
姓名
类型:
字符型
长度:
8
取值范围:
取值含义:
通讯录记录的姓名
数据项:
list_sex
含义说明:
唯一标识每个记录
别名:
性别
类型:
字符型长度:
4
取值范围:
取值含义:
被记录者的性别
数据项:
list_mobile_number
含义说明:
唯一标识每个记录
别名:
手机号码
类型:
字符型
长度:
16
取值范围:
取值含义:
被记录者的手机号码,区别于办公电话
数据项:
list_age
含义说明:
唯一标识每个记录
别名:
年龄
类型:
字符型
长度:
8
取值范围:
取值含义:
被记录者的年龄
数据项:
list_QQ
含义说明:
唯一标识每个记录
别名:
QQ号码
类型:
字符型
长度:
20
取值范围:
取值含义:
被记录者的QQ号码
数据结构:
family
含义说明:
是通讯录的主体数据结构,定义了一个记录的有关信息
组成:
family_family_number和family_family_address
数据项:
family_family_number
含义说明:
唯一标识每个记录
别名:
家庭电话(座机)
类型:
字符型
长度:
16
取值范围:
取值含义:
被记录者的家庭电话(座机)
数据项:
family_family_address
含义说明:
唯一标识每个记录
别名:
家庭住址
类型:
字符型
长度:
80
取值范围:
取值含义:
被记录者的家庭住址
数据结构:
office
含义说明:
是通讯录的主体数据结构,定义了一个记录的有关信息
组成:
office_office_address和office_e_mail
数据项:
office_office_address
含义说明:
唯一标识每个记录
别名:
工作单位
类型:
字符型
长度:
80取值范围:
取值含义:
被记录者的工作单位
数据项:
office_e_mail
含义说明:
唯一标识每个记录
别名:
电子邮箱
类型:
字符型
长度:
20
取值范围:
取值含义:
被记录者的电子邮箱
1.数据项
数据项编号
数据项名
数据项含义
与其它数据项的关系
存储结构
别名
DI-1
ID
用户名
Char(10)
登录名
DI-2
Password
用户密码
Char(20)
密码
DI-3
Name
联系人姓名
Char(10)
姓名
DI-4
Phone
联系人电话
Char(15)
电话
DI-5
Birthday
联系人生日
Date
生日
DI-6
联系人电子邮箱
Char(30)
电子邮箱
DI-7
Homepage
联系人个人主页
Char(30)
个人主页
Dl-8qnumber联系人qq号Char(30)qq
Dl-9address联系人地址Char(30)地址
Dl-10work_out联系人工作地址Char(30)工作
Dl-11relationship联系人关系Char(20)关系
2.数据结构
数据结
构编号
数据结构名
数据结构
含义
组成
DS-1
User
用户信息
ID,Password
DS-2
AddressBook
通讯录信息
Name,Phone,age,E-mail,Homepage
Qq,address,work_out,reltionship
3.处理逻辑描述
处理编号
处理功能
处理过程
PR-1
判断用戶查询涉及的功能模块
通讯录信息模块
根据要查询的内容确定查询数据流向,最后显示查询结果。
PR-2
判断用户修改要涉及的模块,同时把相应的修改数据传到相应的模块之中
通讯录信息模块
先确定更新所涉及的功能模块,然后把更新信息传送到相应的模块中,最后进行相应的更新操作。
PR-3
网格信息显示
为方便查看联系人信息,点击信息表网格也可显示所有信息
二、概念设计------------------------------------------------------------------------
2.1任务与目标
1.设计分E-R图,即各子模块的E-R图。
2.生成初步E-R图,通过合并方法,做到各子系统实体、属性、联系统一。
3.生成全局E-R图,通过消除冲突等方面。
2.2阶段结果
1.用户E-R图
2.编辑E-R图
3.联系人E-R图
4.查询E-R图
合并各分E-R图
三、逻辑设计------------------------------------------
3.1逻辑设计的任务和目标
以上的概念设计阶段是独立于任何一种数据模型的,但是逻辑设计阶段就与选用的DBMS产品发生关系了,系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。
具体内容包括数据组织,即将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计。
3.2数据组织
3.2.1将E-R图转换为关系模型
实体型转换为关系模式。
实体的属性就是关系的属性,实体的码就是关系的码。
对于实体间的联系则有以下不同的情况:
一个m:
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
一个1:
n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。
一个1:
1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
具有相同码的关系模式可合并。
由于用户与联系人People的联系方式是1:
n(一对多),可以将其之间的联系与n端实体图片合并。
具体的基本E-R图向关系模型转化如下:
用户:
login(用户名,密码)
联系人People:
People(姓名、性别、关系、手机号、座机号、QQ号、住址、工作单位、Email)
3.2.2模型优化
关系模式User,AddressBook都不存在非主属性对主属性的部分函数依赖,也不存在传递函数依赖,已经达到了3NF.
3.2.3数据库模式定义
1.用户信息表
列名
数据类型
可否为空
说明
用户名
Char
notnull
用户名
密码
Char
notnull
用户密码
2.联系人信息表
列名
数据类型
可否为空
说明
姓名
Char
notnull
联系人姓名
性别
Char
notnull
联系人性别
关系
Char
联系人关系
手机
Char
联系人手机
座机
Char
联系人座机
Char
联系人QQ
邮箱
Char
联系人电子邮箱
住址
Char
联系人住址
工作单位
Char
联系人工作单位
四、物理设计
4.1物理设计阶段的目标与任务
数据库的物理设计就是为逻辑数据模型选取一个最合适应用要求的物理结构的过程,在这个阶段中要完成两大任务:
(1)确定数据库的物理结构,在关系数据库中主要是存取方法和存储结构;
(2)对物理结构进行评价,评价的重点是时间和空间效率。
4.2数据存储方面
为数据库中各基本表建立的索引如下:
由于通讯录基本表AddressBook的属性Name经常在查询条件和连接操作的连接条件中出现,且它们的值唯一,在两个属性上建立唯一性索引;
4.3建立索引
createclusteredindexTimeonAddressBook(Name);
4.4建立触发器
当AddressBook表中一条Name提醒更改时,
createtriggerAddressBook_insert1
onAddressBook
forinsert
as
declare@Namechar(12)
select@Name=getdate()
frominserted
updateAddressBook
setState='已更改'
whereName<@Name
五、应用设计
5.1系统功能模块图
5.2系统功能模块
5.2.1用户注册和登录模块
5.2.2联系人查询更新模块
六、Delphi设计过程描述
6.1登录
登陆界面由用户和密码输入栏Edit1和Edit2、确定和重置按钮Button1和Button2等组件,本界面通过ADOQuery1和SQLServer用户数据库Walnuts中的登陆表Wsignup相连进行登录操作,登陆成功后跳转至主界面。
6.2注册
主界面由两个Label、两个TEdit、两个Panel、Battonl、Batton2组成Pagecontroler。
在TEdit中输入注册信息,点击注册按钮进行注册
6.3主页
主界面由标题板、主题背景板、子界面进入控制板Panel1、Panel2组成。
包括编辑,查询,退出功能。
6.4联系人管理
联系人管理在tabsheet2和tabsheet3页面中。
两个页面中分别有Panel1和Panel2两个控件,Panel1供用户添加、修改、删除联系人信息,Panel2供用户查询联系人信息。
七、系统试运行
1.登录
3.注册
4.主界面
5.联系人信息操作
6.查询操作
八、总结
8.1开发总结
通过实验,我们小组了解了Delphi和SQL的使用。
在实践中,我们不仅对编程有了进一步的学习,也对数据库系统的开发有了更深的认识。
首先,需求分析是很重要的,这样能确定自己的开发要完成什么任务;然后就是要落实开发过程的每个步骤,追求完美。
如此,我们不仅能开发出好的数据库系统,更能学习到更多的东西。
由于自己准备得不充分,我们组开发的是一个本机运行的通讯录,但有了这一次的学习和经验,我们相信在未来的软件开发中,能做的更好。
8.2个人总结
有关于数据库实验的心得体会真的很多。
首先我们学到了很多东西,包括建表,导入数据,查询,插入等等。
其次也是最重要的,我们能自己亲自动手进行实践,这也是学习的好机会。
虽然这次做的数据库系统很一般,但是我们会继续努力,争取在以后的学习中做得更好。
总的来说,这次的数据库实验真是让我们受益匪浅。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 报告 通讯录
![提示](https://static.bingdoc.com/images/bang_tan.gif)