数据库课程设计人寿保险管理系统.docx
《数据库课程设计人寿保险管理系统.docx》由会员分享，可在线阅读，更多相关《数据库课程设计人寿保险管理系统.docx（31页珍藏版）》请在冰点文库上搜索。
数据库课程设计人寿保险管理系统
课程设计
课程名称数据库系统概论
题目名称人寿保险管理系统
学生学院管理学院__
专业班级
学号
学生姓名________
指导教师________
2011年01月10日
广东工业大学课程设计任务书
题目名称
人寿保险管理系统
学生学院
管理学院
专业班级
姓名
学号
1、课程设计的内容
要求学生结合所学管理知识，在借鉴课堂教学案例、了解家人或亲友所从事的业务及其流程的基础上，参考有关资料，选择自己了解的一项业务，运用课堂所学数据库系统与数据库设计知识，完成信息需求分析、数据库概念设计、逻辑设计、物理设计，实现完成该业务的数据库应用系统，并运行、评价改进之，最后要写出课程设计报告。
二、课程设计的要求与数据
课程设计分3个阶段进行：
首先，结合课堂教学，要求学生结合家人亲友所从事业务工作的实际，选择自己能了解的一项管理业务，完成选题和资料准备；然后，在期末的课程设计阶段，在教师的面对面与网上指导下，完成业务需求分析、数据库的概念设计、逻辑设计、物理设计和处理功能设计并用Email交初稿；教师提出指导意见用Email返回给学生，学生完成课程设计报告。
三、课程设计应完成的工作
本设计要求学生采用本课程中学习的数据库设计方法，运用其基本思路与主要图表工具完成一个自己所了解的业务的数据库应用系统信息需求分析与数据库的概念设计、逻辑设计、物理设计以及处理功能设计，用自己熟悉的数据库管理系统、程序设计语言及其相关开发工具实现该系统，并运行、评价、改进之；在此基础上严格按本大纲所附报告提纲撰写课程设计报告。
四、课程设计进程安排
序号
设计各阶段内容
地点
起止日期
1
需求分析
学校
2010.11.01
2
（数据库）概念（模型）设计
学校
2010.11.15
3
（数据库）逻辑（模型）设计
学校
2011.11.30
4
数据库物理设计与数据库保护设计
学校
2010.12.15
5
处理功能设计
学校
2010.12.30
6
数据库应用系统的实现
学校
2011.01.4
7
数据库应用系统运行
学校
2011.01.10
通过E-mail交课程设计报告初稿
2011.01.11
5、应收集的资料及主要参考文献
[1]王珊、陈虹编著，数据库系统原理教程，清华大学出版社，2003.
参考书目
[1]金银秋主编，数据库原理与设计，科学出版社，2000.
[2]李建中王珊，数据库系统原理，电子工业出版社，1998.
[3]李大友，数据库原理及应用（第二版），清华大学出版社，2000
发出任务书日期：
年月日指导教师签名：
计划完成日期：
年月日基层教学单位责任人签章：
主管院长签章：
目录
1、需求分析04
1.1用户需求04
1.2业务流程分析04
1.3信息需求分析04
1.3.1资料收集04
1.3.2事项分析07
1.4功能需求分析08
2、概念设计09
3、逻辑设计11
3.1一般逻辑模型设计11
3.2具体逻辑模型设计11
4、数据库物理设计与数据库保护设计14
4.1设计索引14
4.2设计表间关系14
4.3完整性设计14
4.4在有多个用户操作时，考虑用户授权与安全性控制14
5、处理功能设计15
5.1主控模块设计15
5.2子模块设计15
5.2.1设计输入15
5.2.2视图设计15
5.2.3查询设计15
5.2.4报表设计15
6、数据库应用系统的实现20
6.1数据库及其表结构的建立20
6.2数据输入22
6.3模块实现22
7、数据库应用系统运行22
7.1系统操作使用的简要说明22
7.2运行系统并打印出运行结果22
7.3系统评价24
8、个人感想24
1.需求分析
1.1用户需求：
系统现状，要解决的主要问题，达到的具体指标等。
作为借助于信息化、网络化开展业务服务与工作活动的典型金融企业，平安人寿已经建成了规模庞大、复杂严密而又安全可靠的保险业务系统，平安人寿的业务专用系统是支撑保险业务数据系统正常运转和自身维护的重要基石，系统围绕着行业内部与外部的运作来实现其功能，现今各大金融企业的竞争可以说是相当激烈，在这种严峻的社会环境下，有个良好的管理系统帮助管理业务，可以说是相当有必要的。
1.2业务流程分析：
描述系统的业务流程，画出规范的业务流程图。
开始
1.3信息需求分析
1.3.1资料收集：
业务流程中用到的相关单据票证帐簿报表报告等资料，画出格式，最好是填有具体内容的表格等。
客户编号
客户名称
性别
会员等级
地址
联系电话
证件号码
出生年月
投保日期
受益人编号
受益人名称
性别
地址
联系电话
证件号码
出生年月
缴费记录号
客户编号
支付方式
负责人编号
金额
缴费时间
续保单编号
负责人编号
总金额
地址
投保日期
续保类型
续保日期
1.3.2事项分析：
分析资料中标题、表头等中各栏目名，列出所有事项，作为数据项；分析这些数据项，找出组合项、导出项、非结构化数据项，确定基本项。
检查是否有要补充的基本数据项，是否有要改进的地方，补充改进之，得出所有基本项。
1、客户：
客户编号，客户名称，性别，会员等级，地址，联系电话，证件号码，
出生年月，投保日期
主码：
客户编号
2、受益人：
受益人编号，受益人名称，性别，地址，联系电话，证件号码，出
生年月
主码：
受益人编号
3、缴费记录：
缴费记录号，客户编号，支付方式，负责人编号，金额，缴费时
间
主码：
缴费记录号
外码：
客户编号参照客户表的客户编号，负责人编号参照职工表的职工
编号
4.续保单：
续保单编号，投保人编号，负责人编号，总金额，投保日期，续保
类型，续保日期
主码：
续保单编号
外码：
投保人编号参照客户表的客户编号，负责人编号参照职工表的职工
编号
1.4功能需求分析：
改进完善业务流程图，分析用户需要系统完成哪些任务，逐层分解，画出功能层次图。
开始
以上是对平安人寿保险系统的运行过程以及流程图的分析，具体分析如下：
1、客户模块数据项：
客户编号，客户名称，性别，会员等级，地址，联系电话，
证件号码，出生年月，投保日期
主码：
客户编号
2、受益人模块数据项：
受益人编号，受益人名称，性别，地址，联系电话，证
件号码，出生年月
主码：
受益人编号
3、缴费记录模块数据项：
缴费记录号，客户编号，支付方式，负责人编号，金
额，缴费时间
主码：
缴费记录号
外码：
客户编号参照客户表的客户编号，负责人编号参照职
工表的职工编号
4.续保单：
续保单编号，投保人编号，负责人编号，总金额，投保日期，续保
类型，续保日期
主码：
续保单编号
外码：
投保人编号参照客户表的客户编号，负责人编号参照职工表的职工
编号
2.（数据库）概念（模型）设计
写出由基本项构思ERD的四条原则及根据这些原则相应得出的实体、联系及其属性，并确定主实体的主标识，画出ERD（不少于两个主实体，一个从实体，一个联系和24个属性）；用原则4检查改正错误；对其中复杂的多元联系进行分析，必要则改进。
构思ERD的四条原则以及实体、联系、属性的确定：
原则1（确定实体）：
能独立存在的事物，例如人、物、事、地、团体、机构、活动、事项等等，在其有多个由基本项描述的特性需要关注时，就应把它作为实体。
原则2（确定联系）：
两个或多个实体间的关联与结合，如主管，从属，组成，占有，作用，配合，协同等等，当需要予以关注时，应作为联系。
联系通常是某类行为动作，ERD中关注的是其状态与结果而非其过程。
原则3（确定属性）：
实体的属性是实体的本质特征。
实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识。
联系的属性是联系的结果或状态。
属性具有如下几个特点：
①非多值性②非复合性③非导出性，
实体的属性还应有非关联性，只是一个实体的基本特征，与其他实体无关；联系的属性应具有关联性，是对联系结果或状态的描述。
原则4（一事一地）：
信息分析中得到的基本项要在且仅在实体联系图中的一个地方作为属性出现。
这条原则是对ERD的检验原则，对确定其构思是否正确具有很大的意义。
首先要看ERD中有没有重复出现的属性名，如果有，一定是错误的，要分析原因，消除重复。
然后要看有无不在信息分析中作为基本项出现的属性，如果有，不一定是错误，但如果不符合基本项的要求，就是错误的，要分析原因，予以改正；如果是基本项，则往往是业务流程用到的资料太完备，数据库设计者与用户协商后加上去的，要分析增加是否真有必要；如果信息分析中列出的基本项在ERD中没有作为属性出现，则一定要分析原因：
有时是不小心遗漏了，那就要补充到适当的地方。
有的是联系的表现形式，其本质上就不是基本项，在以后得到的关系中会作为外码出现，ERD中不应该出现；有一些是作为一些人工原始凭证的编号，在数据库中可能会与一条记录相对应，一般也不必在ERD中作为属性出现，还有一些是在查询或编制报表时通过系统日期生成的日期或顺序编号，其中一些重要中间结果或输出结果在它们可能与决策者的主观因素有关，而不完全取决于计算或推理结果而需要保存时，常常可以作为ERD中相关实体的从实体画出来.
则有如下E-R图：
1.受益人：
2.客户：
3.缴费记录：
4.续保单：
总的E-R图：
E-R图转变为关系模式如下：
1、客户：
客户编号，客户名称，性别，会员等级，地址，联系电话，证件号码，
出生年月，投保日期
主码：
客户编号
2、受益人：
受益人编号，受益人名称，性别，地址，联系电话，证件号码，出
生年月
主码：
受益人编号
3、缴费记录：
缴费记录号，客户编号，支付方式，负责人编号，金额，缴费时
间
主码：
缴费记录号
外码：
客户编号参照客户表的客户编号，负责人编号参照职工表的职工
编号
4、续保单：
续保单编号，投保人编号，负责人编号，总金额，投保日期，续保
类型，续保日期
主码：
续保单编号
外码：
投保人编号参照客户表的客户编号，负责人编号参照职工表的职工
编号
3.（数据库）逻辑（模型）设计
3.1一般逻辑模型设计：
写出由ERD导出一般关系模型的四条原则，列出数据库初步构思的关系框架（二维表的表头）[与具体DBMS无关]，并检查改进之。
原则1（实体转换为关系模式）：
ERD中每个独立的实体转换为一个关系模式，实体的属性组成关系的属性，实体的主标识转换成关系的主码。
原则2（从实体及其主从联系转换为关系模式）：
ERD中一个从实体及其主从联系转换为一个关系，从实体的属性及其主实体关系的属性组成该关系的属性，其主实体关系的主码，在主从联系为一对多联系时还要加上可把同一主实体个体所对应的从实体个体区分开来的、从实体的一组属性，作为该关系的主码。
对子类实体可作类似一对一联系的从实体的转换。
原则3（一对多联系在关系模式中的表示）：
ERD中的一个一对多联系通过在其“多”实体关系上增加“1”实体关系的主码（作为外码）和联系本身的属性来表示。
注：
一对一联系作为一对多联系的特例处理，其中一个实体集中的较多个体按照这个联系不与对方实体集中的任何个体对应，该实体集称为“一”实体，对方实体集称为“零”实体。
一对一联系应通过把“一”实体关系的主码与该联系本身的属性附加到“零”实体关系上来表示，即1：
1联系应附加到没造成或少造成外码及联系本身属性空白的实体关系上
原则4（多对多联系转换为关系）：
ERD中的一个多对多联系转换为一个关系，其被联系实体关系的主码作为外码和该联系本身的属性一起组成关系的属性，被联系关系的主码组成该关系的复合主码。
3.2具体逻辑模型设计：
按所用的DBM要求，设计表（文件）的具体结构，在关系框架下补充字段类型、长度、小数位数等行。
在SQLServer2005中建立数据库BOB，创建4个数据表，如下：
1.投保客户（表名：
InsuranceCustomer）
2、受益人（表名：
EarningsCustomor）
3、投保单（表名：
Toubao）
4、续保表单（表名:
RenewalForm）
4.数据库物理设计与数据库保护设计
4.1设计索引：
在表（文件）的具体结构关系框架下补充字段索引行或在框架外补充索引说明，指出索引字段或索引表达式、索引类型。
4.2设计表间关系：
列出父表与子表的关联索引，指出要建立的表间关系的类型。
4.3完整性设计：
列出主要字段完整性的字段名、完整性约束条件；列出记录完整性约束及其约束条件；列出参照完整性表。
在InsuranceCustomer表中，IC_ID是主码；
在EarningsCustomor表中，EC_ID是主码；
在Toubao表中，T_num是主码，IC_ID是外码，InsuranceCustomer表是被
参照表；
在RenewalForm表中，R_num是主码，IC_ID是外码，InsuranceCustomer
表是被参照表。
4.4在有多个用户操作时，考虑用户授权与安全性控制。
本系统对不同部门员工设置了不同的权限，用户必须输入密码才能登陆系统，能在一定程度上防止恶意的登陆与修改系统信息，详细请见以下的功能设计。
5.处理功能设计（注意：
此时系统未实现，设计结构都是写出或画出的，而不能是系统运行生成的）
5.1主控模块设计：
包括系统环境初始化、欢迎画面、用户身份验证、主控表单或菜单、告别画面、系统退出的环境恢复等功能。
5.2子模块设计：
按系统业务要求设计各项业务模块和系统管理模块，要能完成系统业务和系统管理功能，总体规模至少要达到5.2.1—5.2.4的要求。
5.2.1设计输入：
设计输入数据到表中的表单或窗口，注意实现用户定义的完整性约束，并具有输入校验，以确保输入数据正确，没有垃圾数据混入。
5.2.2视图设计：
设计不少于两个定式视图，并提供调用视图设计器的用户现场生成视图。
5.2.3查询设计：
设计不少于两个定式查询，并提供调用查询设计器的用户现场生成查询。
5.2.4报表设计：
设计不少于两个定式报表，并提供调用报表生成器的用户现场生成报表。
1.首先，对不同部门的员工设置不同的权限，在登陆系统的主页面（http:
//localhost:
8080/pingan/index.jsp）上，填入用户名和密码，如下截图：
3.由于四个部门的操作基本相同，以下仅以客户服务部为例截图：
4.点击：
查询员工的基本信息的链接，进入accessDB.jsp这个页面，实现分页显示，截图如下：
5.点击：
删除客户的基本信息的页面，课实现对撤销保单的客户的删除操作，截图如下：
6.点击：
修改客户的基本信息页面，进入如下界面，截图如下：
7.点击：
添加员工的基本信息，进入如下界面，截图如下:
6.数据库应用系统的实现
6.1数据库及其表结构的建立：
建立数据库描述文件（.DBC）及其数据库表（.DBF），注意完整性、索引与永久关联的实现，并附打印出的作为系统命令执行结果的数据库表结构及其关联图、参照完整性表。
创建四个数据库表：
受益人
createtableEarningsCustomor
（EC_IDchar（8）primarykey,
EC_Namechar（20）,
EC_addresschar（50）,
EC_phonenumchar（20）,
EC_IDNumchar（30）,
EC_sexchar
（2）,
EC_birthdaydatetime
）;
客户
createtableInsuranceCustomer
（IC_IDchar（8）primarykey,
IC_Namechar（20）,
IC_addresschar（50）notnull,
IC_phonenumvarchar（20）,
IC_IDNumvarchar（30）,
IC_sexchar
（2）,
IC_birthdaydatetime,
）；
续保单
createtableRenewalForm
（R_numchar（8）primarykey,
R_Tnumchar（8）,
R_headnochar（8）,
R_moneyfloat（20）,
R_typechar（30）,
R_toudatedatetime,
R_xudatedatetime,
foreignkey（R_Tnum）referencesInsuranceCustomer（IC_ID）,
foreignkey（R_headno）referencesemployee（E_num）
）;
投保单
createtableToubao
（T_numchar（8）primarykey,
T_tnochar（8）,
T_headnochar（8）,
T_ecnochar（8）,
T_timechar,
T_moneyfloat（20）,
T_Tdatedatetime,
T_htnumchar（8）,
T_typechar（30）
foreignkey（T_tno）referencesInsuranceCustomer（IC_ID）,
foreignkey（T_headno）referencesemployee（E_num）,
foreignkey（T_ecno）referencesEarningsCustomor（EC_ID）,
）;
6.2数据输入：
实现5.2.1中的输入程序后，用这些输入程序或系统的追加插入命令录入数据，并打印出用命令列出的各表的内容。
6.3模块实现：
用视窗菜单和/或程序编辑器实现各模块，建议参考教材[2]采用菜单与多表单技术，调试正确后打印实现的系统输出结果。
建议先实现输入模块，再实现其他子模块，然后实现主控模块。
最好建立项目，用项目管理器来管理整个系统。
打印出实现结果（表单、源程序）。
写出实现的经过与体会。
7.数据库应用系统运行
7.1写出系统操作使用的简要说明。
系统操作要在jdk环境之下，并且要启动tomcat，myeclipse，在地址栏填入http:
//localhost:
8080/pingan/index.jsp，进入后按照提示去完成所有的操作，在操作的过程中，会实现数据的查询，更新，修改以及删除的功能，是一个较为完善的系统。
7.2运行系统并打印出运行结果（至少有两个查询结果和两个报表输出结果）。
模糊查询：
提交后得到如下界面：
查询全部信息的界面：
7.3系统评价：
采用的有特色的技术与技巧；成功之处与主要特点；系统会改进完善之处和进一步工作的打算。
1、系统的外观设计不太好，这是主要完善的地方，还在就是安全性问题；
2、系统还有一些功能没有完美；
3、还可以再增加一些功能以完美整个系统的可用性和维护性，例如数据安全管理（含备份与恢复）等。
8.个人感想
制作完善这个系统是一件非常繁琐而又漫长的过程，枯燥乏味并且不断地重复，简直令人崩溃。
因为长时间做这些烦躁的工作，在制作过程中我的脾气都变得比较暴躁。
我常常因为某些问题重复犯错而差点要砸电脑。
但是不管怎样，我还是顶住了压力，冲破了重重障碍，完成了这个系统。
在做系统之前，我首先对平安人寿保险做了全面的调查和分析。
明确需求分析，然后主要分析了系统要分几个模块来实现所需的功能以及每个模块的功能，模块之间的联系。
再就是画ER图，对每个表的初步构想，明确每个表的个属性，主码，外码等问题。
最后就是进行系统的开发了。
有句话说的好，书到用时方恨少。
我在语言编写时遇到了很大的问题。
一是因为我的编程还不熟悉，二是因为我们的实践太少，遇到很多问题都不知道如何解决。
遇到问题也不算什么，最令人烦恼的是，明明写好的程序，但运行却有错误，而我们又不知道问题出在哪里。
就是找错误这方面占用了我整个系统制作时间一半以上。
还更为深刻的就是数据库的连接，屡次尝试都不得成功。
受到技术和知识的限制，我这个系统不能说是完美的。
它只是一个非常基础和普通的系统，但是它却凝结了我和所有帮助我解决问题的同学们的心血和汗水。
可能它还有很多的功能不能实现，但是起码它已经满足了我最初的设计计划。
我所需要的最基本功能也都可以实现。
在很多的细节和具体问题方面可能还存在缺陷，我会在以后的日子努力不懈，自强不息，本着学习的精神去完善这个系统。
“一分耕耘，一分收获。
”这就是我这次最大的收获和感想。
分数已经不重要了，重要的是过程。
在这个过程中的实践，学到的经验，学到了不少我们以前不曾见过的错误。
这次虽然做的不够好，但是有了这次的经验，我下次必能会更好。
升级会员 