为了正常的体验网站,请在浏览器设置里面开启Javascript功能!

车辆理赔系统

2019-08-21 41页 doc 172KB 32阅读

用户头像

is_841159

暂无简介

举报
车辆理赔系统目录 第1章概述    2 1.1 选题的背景与意义    2 1.2 相关技术分析    3 第2章系统功能设计    4 2.1 系统总体结构设计图    4 2.2 系统功能模块    6 2.2.1 理赔管理部    6 2.2.2 理赔操作部    6 2.2.3 客户服务部    6 2.2.4 财务部    6 2.2.5 客户管理    6 第3章数据库设计    7 3.1 需求分析    7 3.1.1 系统数据流图    7 3.1.2 数据字典    11 3.2 概念结构设计    15 3.2.1...
车辆理赔系统
目录 第1章概述    2 1.1 选题的背景与意义    2 1.2 相关技术    3 第2章系统功能设计    4 2.1 系统总体结构设计图    4 2.2 系统功能模块    6 2.2.1 理赔管理部    6 2.2.2 理赔操作部    6 2.2.3 客户服务部    6 2.2.4 财务部    6 2.2.5 客户管理    6 第3章数据库设计    7 3.1 需求分析    7 3.1.1 系统数据流图    7 3.1.2 数据字典    11 3.2 概念结构设计    15 3.2.1 局部E-R图    15 3.2.2 全局E-R图    17 3.3 逻辑结构设计    19 3.3.1 关系模式及模式判定    19 3.3.2 子模式的设计    20 3.4物理结构设计    21 3.4.1 存取路径设计    21 3.4.2 存储结构设计    21 3.4.3 设计评价及说明    22 3.5 数据库实施    23 3.5.1 相应代码    23 3.5.2 数据库、表截图    28 3.5.3 存储过程和触发器    28 3.6 数据库运行与维护    30 第4章结束语    31 参考文献    32 第1章概述 1.1选题的背景与意义 随着车辆的问世和发展,现在汽车是我们生活中不可分割的一部分,汽车的出现就伴随着事故的必然性,所以汽车保险为我们的生活提供了损失补偿,为人民的生活起到了很大的作用,再对平安保险和其他保险公司业务流程进行查阅及一些网上查询。站在被保险人的立场来看,就是要求保险公司最大程度的进行赔偿,可是对于保险公司,当然是将赔偿损失降的越低越好了。最重要的一点,买了保险就要要求保险公司最大限度的去赔偿损失,只要是在保险责任范围内的,就不能不赔。该系统能很大限度减少理赔的错误,该系统的充分开发和应用,可以改善公司的运营,使公司获得收益,加快车险管理信息化建设的目标应该是:提高车险结算速度,争取客户,赢得效益。具体体现在: (1)能够优化理赔结算的过程,提高对理赔清单信息的处理速度,减少各种繁琐程序,使结算流程清晰明朗。 (2)做好理赔结算过程的理算操作与以及核赔过程,使理算尽量严谨。 首先,通过汽车事故理赔,被保人所享受的保险利益得到实现,即如果发生交通事故,并且通过签订保险的方式,在安定缴纳一定保险费用时,事故中所产生的车辆损失人员伤亡等会及时扥到损失补偿的权利;其次,通过汽车保险理赔,使人民生活安定,社会再生产得到保障,交通事故往往伴随着经济损失,汽车理赔能使被保人心灵上得到慰藉,并得到相应的补偿,以重建家园,安定生活,对社会稳定发展起到积极的作用;然后,通过汽车保险理赔,汽车保险承担的质量得到检验,汽车保险承担手续是否齐全,以及保险费是否合理,平时不容易察觉,当发生赔偿事件时,上诉问题就容易暴漏,只有通过汽车保险理赔,才能有利于承保工作的改进以及合法,和业务的提高;最后,通过汽车保险的理赔,汽车保险的经济效益得到充分反映。 车险理赔结算是根据检验报告提供的损失情况,结合保险合同条款和相关法律的有关规定,计算应支付的保险赔款,并将赔款划付被保险人。查勘定损与理算是相互依赖密不可分的,查勘定损是理算工作的基础和前提,理算工作是查勘定损的目的,同时,理算工作还对查勘定损起到监督和检查的作用。 关键词:汽车保险,查勘定损,赔款理算,理赔调查 1.2相关技术分析 系统采用何种技术架构,取决于系统的运行商业环境以及客户的需要,车险理赔系统是保险公司的关键业务系统,需要24小时的稳定运行,能够支持多人在线,数据需要极高的安全性,同时能够支持互联网访问。考虑到上述的关键因素同时结合保险公司的实际成本支出,本系统采用B/S的系统结构。为了提高系统的性能,系统中计算量非常大的赔款计算模块使用了规则引擎技术,基于JBoss的Drools规则引擎对赔款计算进行优化,减少了数据库层的访问,提高计算性能。由于本系统较小所以数据库层不需要采用Oracle数据库而采用SQL server 2008 R2,从可行性分析 (1)经济可行性 现在各家保险公司在发展业务的同时,必须要注重业务的质量。做车险业务己从追求规模效益有效益的规模的转变,品质优先才能最好的实现利润导向。从而更好服务于客户,使得客户满意度不断提升,达到原有的目的。 (2)管理可行性 该系统的最大特点是提供远程定损、核损功能。利用信息技术平台,较好地解决了理赔速度和管控的关系问题,只要有一定权限的理赔人员就能够完成定损、核损、理算、核赔工作,减少了一些不必要的繁琐过程,大大加快了效率和效果。 第2章系统功能设计 2.1系统总体结构设计图 该系统系统的设计采用自顶向下,逐层分解的结构化设计方法。系统总体设计根据系统分析的要求和组织的实际情况对新系统的总体结构形式和可利用的资源进行大致的设计。把系统划分为理算清单导出子系统,理算信息导入子系统,理算核赔子系系统,任务提交子系统,立案处理子系统。而子系统又划分为若干功能模块,层层划分直到每一个模块是相对独立,功能单一的独立程序为止。该系统系统的管理人员及用户结构设计图如下图1、图2所示 2.2系统功能模块 2.2.1理赔管理部 加强立案过程管理,确保立案时估损金额尽量准确。公司原则上应实行报案立案。接到报案后应及时在理赔信息系统中进行立案处理。系统应设置超过一定时间尚未立案则强制自动立案功能。 2.2.2理赔操作部 定损人员应准确记录损失部位和项目,提出修理、更换建议,及时录入理赔信息系统。并请客户签字确认损失部位和项目,调度,查勘核算理赔价格。 2.2.3客户服务部 接收、记录客户送达的索赔资料时,应按照“索赔须知”当场查验索赔资料是否齐全,及时出具接收回执。回执上应注明公司接收人、接收时间和公司咨询电话。 2.2.4财务部 负责企业财政运作情况及财务管理,处理各类账单、发票等。 2.2.5客户管理 客户自行登录理赔系统,进行申请理赔,和管理自己相关信息和查看己的理赔金额。 第3章数据库设计 3.1 需求分析 3.1.1系统数据流图 数据流程分析可以按照自顶向下、逐层分解、逐步细化的结构化分析方式进行,通过分层的数据流程图来实现。 (1)系统顶层数据流程设计 从下图3可以看出,该系统所涉及到的外部实体主要包括了理赔操作部门、理赔管理部门、客户服务部门,信息处理部门和财务部门,客户等组成。 先客户登录该系统并进行申请理赔,该系统从而从客户服务部门处获得理赔清单导入有关数据,系统调用有关数据向客户服务部门发出理赔预警报告。车险理赔理算管理信息系统收到理赔操作部门提出的理赔方案系统的提交核赔单。车险理赔理算管理信息系统收到信息处理部收集整理的决策信息然后导出理赔信息反馈清单。车险理赔理算管理信息系统收到理赔管理部门的信息及时进行立案处理并反馈任务提交单据。财务部门通过核算各种业务单据向系统提供收付款信息。后客户收到领款 (2)系统一层数据流程设计 为了能把车险理赔理算管理信息系统中有关理算信息、清单处理和理算核赔、立案决策的细节表示出来,在顶层图的基础上,自顶向下地进行分解,得到车险理赔理算管理信息系统的第一层数据流程图,如下图4所示。从第一层数据流程图中可以更为细致的看出,车险理赔结算管理的主要流程可以分为五个主要的过程:信息确认、清单导出、理算核赔、任务提交和立案处理。 当客户服务部门将保险单证发送到信息处理部门的时候,理算信息确认流程开始。信息处理部门要核对客户信息,并根据客户信息批准保险单证,信息核对结束后,交由理算人员及时导出理算清单。 导出理算清单时,理算人员要根据已批单证进行确认,之后要根据信息处理部的决策意见进行调整并将导出清单及时发送给理赔操作部门做相应的处理。 理赔操作部门收到来自于信息处理部门的保险清单时,进行理赔核算,并拟定详细的核赔方案交由决策人员审核。 任务提交管理是要对理赔操作部确定的核赔方案进一步审核,在审核无误的情况下,编制任务单据交由立案处理。 立案处理是将审核无误的任务单据,即结算完成的核赔单交给财务部门进行最终结算赔偿,同时财务部将结算通知单发送给理赔操作部。 3.1.2数据字典 1  数据项 编号 数据项名称 说明部分 类型 长度 1 保单号 保单的编号,具有唯一性 char 20 2 车辆牌号 所需投保的车辆牌号 char 20 3 车辆类型 所投保的车型 varchar 10 4 投保类型 所投保的类型选择如:车辆损失险,第三者责任保险等(建表时会列全) varchar 20 5 投保人 办理保险人名字 varchar 10 6 被保险人 被保险人人的名字 varchar 10 7 客户出生日期 办理保险人的出生日期 smalldatetime   8 保险缴纳时间 缴纳保险费用的时间,方便计算 datetime   9 联系电话 办理保险人所填号码,方便联系 char 20 10 客户住址 办理保险人所填住址,方便联系 varchar 80 11 投保日期 投保时的日期,方便计算金额 datetime   12 保额合计 所能获得保额 numeric (16,2) 13 保费合计 所需缴纳的保险费用 numeric (16,2) 14 案件号 报案是唯一编号 char 15 15 报案人 报案人姓名 varchar 10 16 报案人移动电话 报案人电话(方便联系) char 20 17 驾驶证号 驾驶证编号 char 20 18 驾驶人员 驾驶员姓名(所需填写信息) varchar 10 19 驾驶人年龄 驾驶人年龄(所需填写信息) int 18~60 20 驾驶人性别 驾驶人性别(所需填写信息枚举类型) char 2 21 驾驶人电话 驾驶人电话(便于联系) varchar 30 22 驾驶车型 驾驶人员所驾驶车型 varchar 10 23 出险地点 发生事故的地点 varchar 80 24 出险时间 发生事故的时间 datetime   25 出险原因 发生事故的原因 varchar 200 26 保单机构 保单所属机构 varchar 10 27 报案时间 报案时间 datetime   28 立案时间 立案时间 datetime   29 立案金额 立案金额(原则上) numeric (16,2) 30 理算时间 理算的时间 datetime   31 理算金额 理算的金额 numeric (16,2) 32 核赔时间 核赔的时间 datetime   34 结案时间 结案的时间 datetime   35 结案金额 结案时的金额 numeric (16,2) 36 理算费用 理算时的费用 numeric (10,2) 37 审核人 理算人名字 varchar 10 38 赔付次数 赔付的次数 int 0~10 39 申请类型 申请理赔的类型 varchar 20 40 是否追偿 是否追加赔偿 char 2 41 核算人 核赔人员姓名 varchar 10 42 核赔金额 核赔金额 numeric (16,2) 43 结案ID 结案时所产生ID char 20 44 报案号 报案时的编号 char 20 45 结案人 结案人员的姓名 varchar 10 46 结案机构 结案的机构 varchar 10 47 账号 登录时所必填的信息(方便验证) varchar 12 48 密码 登录时所必填的信息(方便验证) varchar 12 49 姓名 登录时用户姓名 varchar 10 50 类型 枚举类型(客户,管理人员) varchar 10 51 损坏程度 记录损坏的程度 varchar 10 52 损坏日期 记录损坏的日期 datetime             2  数据结构 编号 数据结构名 属性 1 用户 账号、密码、姓名、类型 2 保险单证 保单号、车辆牌号、投保人、被保险人、客户出生日期、保费缴纳时间、联系电话、客户住址、投保类型、保额合计、保费合计 3 赔案表 案件号、报案人、报案人移动电话驾驶证号、出险地点、出险时问、出险原因、保单机构、报案时间、立案时间、立案金额、理算时问、理算会额、核赔时间、结案时间、结案金额 4 驾驶车辆 车辆牌号、车辆类型 5 驾驶人员 驾驶证号、驾驶人员、驾驶人年龄、驾驶人性别、驾驶人电话、驾驶车型 6 理算清单 报案号、保单号、赔付次数、理算时间、理算费用、损坏程度、损坏日期、审核人 7 核赔单 报案号、保单号、申请类型、是否追偿、核赔金额、核赔时问、被保险人、核算人 8 结案表 结案ID、结案时间、结案人、结案机构 9 客户拜访信息 账号、密码、保单号、核算金额       3  数据流 编号 数据流名 输入 输出 1 理赔清单导出 客户服务部门 车辆理赔系统 2 理赔预警报告 车辆理赔系统 客户服务部门 3 领款通知 车辆理赔系统 客户 4 业务单据 车辆理赔系统 财务部门 5 提交核赔单 车辆理赔系统 理赔操作部 6 提交理赔方案 理赔操作部 车辆理赔系统 7 做出决策 信息采集部 车辆理赔系统 8 理赔信息反馈清单 车辆理赔系统 信息采集部 9 提交单据 车辆理赔系统 理赔管理部 10 立案处理 理赔管理部 车辆理赔系统 11 保险单证 客户服务部门 理算信息管理 12 保单信息确认 理算信息管理 信息处理部 13 决策信息 信息处理部 理赔清单导出管理 14 导出清单 理赔清单导出管理 理算核赔处理 15 核赔方案 理算核赔处理 理赔操作部 16 核赔方案结算 理赔操作部 任务提交管理 17 任务单据 任务提交管理 立案处理 18 核赔单 立案处理 财务部 19 结算通知 财务部 理算核赔处理 20 已批单证 理算信息管理 理赔清单导出管理 21 登录 客户登录信息 车辆理赔系统         4 数据存储 编号 数据存储名 输入数据流 输出数据流 说明 1 用户信息 登录   记录用户相关信息 2 保险单信息 保单信息确认 保险单证、理赔清单导出 记录保单相关信息 3 驾驶人员信息 保单信息确认 保险单证、理赔清单导出 所记录的信息在保单当中 4 驾驶车辆信息 保单信息确认 保险单证、理赔清单导出 所记录的信息在保单当中 5 理算清单信息 核赔方案结算、立案处理、业务单据、理赔预警报告 理赔清单导出、提交理赔方案、已批单证、导出清单、决策信息、提交单据、理赔信息反馈清单 记录清单相关信息 6 核赔单信息 任务单据 提交核赔单、核赔单 记录核赔单相关信息 7 赔案信息     记录出事时的相关信息信息 8 客服拜访信息 登录 领款通知 记录客户拜访时相关信息           5  处理过程 编号 处理过程 数据来源 数据去向 说明 1 车辆理赔系统 客户服务部门、理赔操作部、客户、财务部门、理赔管理部、信息采集部 客户服务部门、理赔操作部、客户、财务部门、理赔管理部、信息采集部 所有处理过程所必须经过的处理过程 2 理算信息管理 客户服务部 理赔操作部、信息处理部 主要负责一些理算信息 3 理赔清单导出管理 信息处理部 理赔操作部 导出清单 4 任务提交管理 理赔操作部 财务部门 提出可行方案 5 立案处理 理赔操作部 财务部门 对所给方案进行执行 6 理算核赔处理 信息处理部 理赔操作部 对清单进行核算           3.2 概念结构设计 在需求分析的基础上,用概念数据模型,此处采用E-R数据模型,表示数据及其相互间的联系。概念数据模型是与数据库管理系统(DBMS)无关、面向现实世界的数据模型。在概念设计阶段,主要是致力于模拟现实世界,可以不必纠缠于DBMS所规定的各种细节。根据需求分析,对系统进行概念设计,进行数据库概念设计,并画出E-R图如下图所示: 3.2.1局部E-R图 (1)用户 (2)保险单证 (3)客户拜访信息 (4)赔案过程 (5)结案 3.2.2全局E-R图 用户(账号、密码、姓名、类型) 保险单证(保单号、车辆牌号、投保人、被保险人、客户出生日期、保费缴纳时间、联系电话、客户住址、投保类型、保额合计、保费合计) 赔案表(案件号、报案人、报案人移动电话 驾驶证号、出险地点、出险时问、出险原因、保单机构、报案时间、立案时间、立案金额、理算时问、理算会额、核赔时间、结案时间、结案金额) 驾驶车辆(车辆牌号、车辆类型) 核赔单(报案号、保单号、申请类型、是否追偿、核赔金额、核赔时问、被保险人、核算人) 驾驶人员(驾驶证号、驾驶人员、驾驶人年龄、驾驶人性别、驾驶人电话、驾驶车型) 理算清单(报案号、赔付次数、理算时间、理算费用、损坏程度、损坏日期、审核人) 结案表(结案ID、结案时间、结案人、结案机构) 客户拜访信息(账号、密码、保单号、核算金额) 在合并总E-R图过程中,主要分两步进行: 第一步:合并。 解决各分E-R图之间的冲突,将各分E-R图合并起来生成初步E-R图。 各分E-R图之间的冲突主要有三类: 属性冲突: (1)属性域冲突。由于本系统较简单,所以并不存在这种冲突; (2)属性取值单位冲突。由于本系统较简单,不存在这类冲突; 命名冲突: (1) 同名异义:由于本系统较简单,所以不存在这类冲突; (2) 异名同义:由于本系统较小,所以不存在这类冲突; 结构冲突: (1) 同一对象在不同应用中具有不同的抽象:本系统在需求分析阶段原本存在这种冲突,考虑到后期的简化合并,我们在设计各个分E-R图就早先解决了这个问题,即将在任何一个分E-R图中作为实体出现的属性全部作为实体; (2) 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同:由于本系统较简单,所以并不存在这种冲突; 第二步:优化。 消除不必要的冗余,生成基本E-R图。由于本系统涵盖的内容比较多,存在部分冗余,但考虑到系统的效率,所以初步E-R图就是基本E-R图,不必再进行调整。 3.3逻辑结构设计 3.3.1关系模式及模式判定 E-R图转换关系模式原则: 一个实体就是一个关系模式,个个实体的属性就是个个关系的属性,实体的键就是关系的键。一个联系转化成一个关系模式,与该联系连接的各实体键及联系的属性均转化成该关系的属性:如果是1:1联系,则每个实体的键都是关系的候选键;如果是1:n,则n端所对应的键是关系的键;如果是n:m联系,则采用组合来作为关系的键。 用户(账号、密码、姓名、类型)  BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 保险单证(保单号、车辆牌号、投保人、被保险人、客户出生日期、保费缴纳时间、联系电话、客户住址、投保类型、保额合计、保费合计、账号、密码)  BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 赔案表(案件号、报案人、报案人移动电话 驾驶证号、出险地点、出险时问、出险原因、保单机构、报案时间、立案时间、立案金额、理算时问、理算会额、核赔时间、结案时间、结案金额、账号、密码、保单号) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 驾驶车辆(车辆牌号、车辆类型) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 核赔单(报案号、保单号、申请类型、是否追偿、核赔金额、核赔时问、被保险人、核算人) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 驾驶人员(驾驶证号、驾驶人员、驾驶人年龄、驾驶人性别、驾驶人电话、驾驶车型) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 理算清单(报案号、保单号、赔付次数、理算时间、理算费用、损坏程度、损坏日期、审核人) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 结案表(结案ID、报案号、保单号、案件号、结案时间、结案人、结案机构) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 客户拜访信息(账号、密码、保单号、核算金额) BCNF 所有属性均为不可分,且不存在非主属性对主键的部分函数依赖,且不存在属性间的传递,均可通过主键直接推出,且不存在主属性对主属性的部分函数依赖。 3.3.2 子模式的设计 (1)客户子系统用户子模式 客户(账号,密码,保单号,核赔金额) 因为客户对理赔信息其他情况不会过多关注,大部分关注保单号,核赔金额,所以客户建立以上关系。 (2)管理员系统用户子模式 管理员(账号,密码,保单号,案件号,报案号,核赔金额,保费合计) 因为客户对理赔信息其他情况不会过多关注,大部分关注以上属性,所以管理员建立以上关系。 3.4物理结构设计 3.4.1存取路径设计 该系统中个个联席比较密切,查询的时候都会关联不少,所以采用B树结构存储能更好的存储和查询,具体如下 ● 对以下经常在查询中出现的关系的码建立索引<说明:下加横线部分表示关系的码> 赔案表(案件号、报案人、报案人移动电话 驾驶证号、出险地点、出险时问、出险原因、保单机构、报案时间、立案时间、立案金额、理算时问、理算会额、核赔时间、结案时间、结案金额、账号、密码、保单号); 核赔单(报案号、保单号、申请类型、是否追偿、核赔金额、核赔时问、被保险人、核算人); 理算清单(报案号、保单号、赔付次数、理算时间、理算费用、损坏程度、损坏日期、审核人); ● 以下经常进行连接操作的关系的码建立索引: 保单号、报案号、案件号等 ● 由于下面几个关系模式的更新频率很高,所以没有定义索引: 用户(账号、密码、姓名、类型、案件号); 保险单证(保单号、车辆牌号、投保人、被保险人、客户出生日期、保费缴纳时间、联系电话、客户住址、投保类型、保额合计、保费合计); 驾驶人员(驾驶证号、驾驶人员、驾驶人年龄、驾驶人性别、驾驶人电话、驾驶车型); 结案表(结案ID、报案号、保单号、案件号、结案时间、结案人、结案机构); 客户拜访信息(账号、密码、保单号、核算金额); 驾驶车辆(车辆牌号、车辆类型); 3.4.2存储结构设计 (1) 确定数据库的存放位置 为了提高系统性能,现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。同时,考虑到本系统是多用户的,为了提高效率,数据库的备份的数据和日志文件将保存在磁带中。 ● 经常存取部分: 用户(账号、密码、姓名、类型、案件号); 保险单证(保单号、车辆牌号、投保人、被保险人、客户出生日期、保费缴纳时间、联系电话、客户住址、 投保类型、保额合计、保费合计); ● 存取频率较低的部分: 赔案表(案件号、报案人、报案人移动电话 驾驶证号、出险地点、出险时问、出险原因、保单机构、报案时间、立案时间、立案金额、理算时问、理算会额、核赔时间、结案时间、结案金额、账号、密码、保单号); 核赔单(报案号、保单号、申请类型、是否追偿、核赔金额、核赔时问、被保险人、核算人); 理算清单(报案号、保单号、赔付次数、理算时间、理算费用、损坏程度、损坏日期、审核人); (2)确定系统配置 车辆理赔系统需要的微机数量和规模都不必太大,但在系统设计时应考虑到车辆保险公司的发展需求,在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。 该系统选用了Windows7系统作为微机的操作系统,它能够有较好的使用界面并能够充分发挥出微机硬件的作用,比较适合酒店这样的机构;另外,选用了目前应用最多的SQL Server数据库。 由于涉及到企业的财务,数据的完整性和安全性显得尤其重要。系统中的数据一旦丢失,将需要很长时间进行恢复,有时甚至使信息系统不得不从系统初始化阶段重新开始运行。每天进行数据备份是保障系统安全的重要手段。数据备份需要严格按照事先制定的备份与故障恢复策略进行,并落实备份登记和检查措施。 具体的系统配置应当根据系统实际运行情况做进一步的调整。 3.4.3设计评价及说明 该设计对时间效率,空间效率上都有大大的提示,相比原始的车辆理赔系统而言,各个方面做出了较好的权衡,并且根据车辆理赔的一些实际出发,以时间效率和用户的实际需求为根本,得出的最后方案。 3.5数据库实施 3.5.1相应代码 (1)建数据库 createdatabaseVehicle_claim_settlement_system on (name=Vehicle_claim_settlement_system_Data, filename='E:\车辆理赔系统\Vehicle_claim_settlement_systemData.mdf', size= 100, maxsize= 500, filegrowth= 50) logon (name=Vehicle_claim_settlement_system_Log, filename='E:\车辆理赔系统\Vehicle_claim_settlement_systemData.ldf', size= 50, maxsize= 250, filegrowth= 50) (2)用户表的建立 createtableUsers (U_idvarchar(12)notnull, U_keyvarchar(12)notnull, U_namevarchar(10)notnull, U_typevarchar(10)constraintU_Checkcheck(U_typein('普通用户','客户服务部', '财务部','理赔操作部','理赔管理','信息处理部')), constraintU_primprimarykey(U_id,U_key)) (3)驾驶车辆表的建立 createtableCar (Car_nochar(20)constraintCar_primprimarykey, Car_typevarchar(10)notnull (4) 保险单证表的建立 createtableinsurance (IN_warrantychar(20)constraintinsurance_primprimarykey, Car_nochar(20), IN_namevarchar(10)notnull, IN_namedvarchar(10)notnullunique, IN_birthdaysmalldatetime, IN_timedatetime, IN_phonechar(20)notnull, IN_addressvarchar(80)notnull, IN_typechar(4)unique, IN_allcoveragenumeric(16,2)notnull, IN_allpremiumnumeric(16,2)notnull, foreignkey(Car_no)referencesCar(Car_no),constraintin_Checkcheck(IN_typein('A','B','D1','D2','G','F','L','M','M2'))) 其中(A—车辆损失险。B—第三者责任险。D1—车上人员险,D2—车上货物。 G—盗抢险。F—玻璃单独破损险。L—划痕险。 M—不计免赔率, M2—不计免赔额。) (5)驾驶人员表的建立 createtableDriver (Drive_nochar(20)primarykey, Drive_namevarchar(10)notnull, Drive_sexchar(2)check (Drive_sexin('男','女')) constraintDrive_defdefault'男', Drive_ageintconstraintDrive_Consnotnull constraintDriver_checkcheck(Drive_agebetween 18 and 66), Drive_phonechar(20)notnull, Drive_typevarchar(10)notnull) (6)赔案表的建立 createtableIndemnity (case_nochar(20)primarykey, reportervarchar(10)notnull, reporter_phonechar(20)notnull, Drive_nochar(20), danger_addressvarchar(80)notnull, danger_timedatetimenotnull, danger_reasonsvarchar(200), insurance_organizationschar(10)notnull, reporte_timedatetimenotnull, constraintIndemnity_Cons1check(reporte_time>danger_time), filing_timedatetimenotnullunique, constraintIndemnity_Cons2check(filing_time>reporte_time), filing_feenumeric(16,2)notnull, adjustment_timedatetimenotnullunique, constraintIndemnity_Cons3check(adjustment_time>filing_time), adjustment_feenumeric(16,2)notnull, claims_assessment_timedatetimenotnullunique, constraintIndemnity_Cons4check(claims_assessment_time>adjustment_time), settle_timedatetimenotnullunique, constraintIndemnity_Cons5check(settle_time>claims_assessment_time), settle_feenumeric(16,2)notnull, U_idvarchar(12), U_keyvarchar(12), IN_warrantyvarchar(30), foreignkey(Drive_no)referencesDriver(Drive_no), foreignkey(U_id,U_key)referencesUsers(U_id,U_key), foreignkey(IN_warranty)referencesInsurance(IN_warranty)) (7)理算清单表的建立 createtableClaims_assessment (report_nochar(20)primarykey, IN_warrantychar(20)referencesInsurance(IN_warranty), claims_assessment_degreeintcheck (claims_assessment_degreebetween 0 and 10), claims_assessment_costnumeric(16,2), claims_assessment_timedatetimereferencesIndemnity(claims_assessment_time), damaged_conditionvarchar(10), damaged_timedatetime, Claims_assessment_namevarchar(10)notnull) (8)核赔单 createtableAdjustment (report_nochar(20)primarykey referencesclaims_assessment(report_no), IN_warrantychar(20)referencesInsurance(IN_warranty), adjustment_costnumeric(16,2), adjustment_timedatetimereferencesIndemnity(adjustment_time), apply_typevarchar(20)referencesInsurance(IN_type), pursuing_of_recoverchar(2)check (pursuing_of_recoverin('是','否')) default'否', IN_namedvarchar(10)referencesInsurance(IN_named), adjustment_namevarchar(10)notnull) (9)结案表 createtablesettle (settle_idchar(20)primarykey, report_nochar(20)referencesclaims_assessment(report_no), IN_warrantychar(20)referencesInsurance(IN_warranty), case_nochar(20)referencesIndemnity(case_no), settle_namevarchar(10)notnull, settle_timedatetimereferencesIndemnity(settle_time), settle_organizationvarchar(10)notnull) (10)客户拜访信息 createtableUsers_Comeback (U_idvarchar(12), U_keyvarchar(12), IN_warrantychar(20)referencesInsurance(IN_warranty), adjustment_costnumeric(16,2)referencesAdjustment(adjustment_cost) primarykey(U_id,U_key), foreignkey(U_id,U_key)referencesUsers(U_id,U_key)) 3.5.2数据库、表截图 3.5.3存储过程和触发器 (1)插入用户时的存储过程 createprocedureinsertusers (@U_idvarchar(12), @U_keyvarchar(12), @U_namevarchar(10), @U_typevarchar(10) ) asinsertintoUsersvalues(@U_id,@U_key,@U_name,@U_type) (2)当发生事故时通过保单查看所得理赔金额 useVehicle_claim_settlement_system go createproceduresearch_fee (@IN_warrantyvarchar(30), @adjustment_costnumeric(16,2)output ) asselect@adjustment_cost=adjustment_cost fromAdjustment whereIN_warranty=@IN_warranty (3)删除该数据库里面的表触发器提示 useVehicle_claim_settlement_system go createtriggersafty ondatabase fordrop_table asprint'亲不具备删除的权限!' rollback 3.6 数据库运行与维护 定期维护数据库的安全性与完整性,按照设计阶段提供的安全规范和故障规范,相应的DBA要经常检查系统的安全,根据用户的实际需求授予用户不同的操作权限。另外,为了确保系统在发生故障时,能够及时恢复。数据备份至少每天一次,备份介质场外存放,并建立数据备份日志。每隔一定时间进行完全备份,当修改量不大时采用差异备份根据数据的保密要求和用途,确定使用人员的操作权限。数据库运行期间,数据库管理员应对数据库的运行日志及表空间的使用情况进行监控,以便及时发现数据库存在的问题。数据库管理员定时监控数据库告警日志文件,根据日志中发现的问题及时进行处理。数据库管理员要定时监控了解表空间、表空间的碎片及可用空间情况,决定是否要对碎片进行整理或为表空间增加数据文件。数据库管理员要定时对数据库的连接情况进行检查,查看与数据库建立的会话数目是否正常,并对一些连接进行相关处理。数据库管理员要及时对数据库数据文件,控制文件及日志文件进行备份。数据库管理员定时查看数据库中数据文件的状 态,根据实际情况决定如何进行处理。定期清理运维过程中所生成的生产数据库中的临时表,从应用系统角度来优化数据库,如建立并优化索引、优化存储过程、数据库表拆分等,提高应用系统运行速度。当数据库出现问题时采用回滚方式,可先回滚到完全备份时的状态再进行,恢复差异备份,也通过重复日志的方式对数据进行操作从而达到修复作用 (1)完整备份 backupdatabaseVehicle_claim_settlement_system todisk='E:车辆理赔系统\Vehicle_claim_settlement_system.bak' (2)差异备份 backupdatabaseVehicle_claim_settlement_system todisk='E:车辆理赔系统\Vehicle_claim_settlement_system1.bak' withdifferential (3)备份日志 备份日志前进行需完全备份,后在进行备份日志 backuplogVehicle_claim_settlement_system todisk='E:车辆理赔系统\Vehicle_claim_settlement_system2.bak' (4)完全备份还原 restoredatabaseVehicle_claim_settlement_system fromdisk='E:车辆理赔系统\Vehicle_claim_settlement_system.bak' (5)差异备份还原 restoredatabaseVehicle_claim_settlement_system fromdisk='E:车辆理赔系统\Vehicle_claim_settlement_system.bak' withreplace,norecovery 在完全备份的条件下,再进行以下恢复 restoredatabaseVehicle_claim_settlement_system fromdisk='E:车辆理赔系统\Vehicle_claim_settlement_system1.bak' withrecovery (6)日志还原 restoredatabaseVehicle_claim_settlement_system fromdisk='E:车辆理赔系统\Vehicle_claim_settlement_system.bak' withreplace,norecovery 先完全备份恢复,再进行如下日志恢复 restorelogVehicle_claim_settlement_system fromdisk='E:车辆理赔系统\Vehicle_claim_settlement_system2.bak' withrecovery 参考文献 按照下面的格式: [1] 陈志泊,数据库原理及应用教程.人名邮电出版社, 2014 [2] 王珊, 萨师煊数据库系统概论. 高等教育出版社, 2010. [3] 网上查阅百度文库
/
本文档为【车辆理赔系统】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。 本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。 网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。

历史搜索

    清空历史搜索