《数据库原理》信用卡管理系统Word格式.docx
《《数据库原理》信用卡管理系统Word格式.docx》由会员分享，可在线阅读，更多相关《《数据库原理》信用卡管理系统Word格式.docx（26页珍藏版）》请在冰豆网上搜索。
1.发错人
2.被陌生人领走
2.2.7记录跟踪模块
记录跟踪的具体信息（存钱取钱，在哪消费，消费记录和时间地址等），用来处理模块的依赖关系
1记录当前处理与下一个处理，在信用卡业务流程中，只有一个处理正常结束时，下一个处理才可以开始，不可以跨处理进行；
2一个模块有问题时根据原因自动或者手动发送到跟踪模块；
3跟踪模块会找出原因，处理问题，然后发送到相应的模
第3章数据库设计
3.1需求分析
图3.1.1整体的布局分析流程
图3.1.2审核成功能申请办理信用卡的数据流
图3.1.3审核过程数据流
图3.1.4客户申请开卡
编号
数据项名称
说明部分
1
申请者信息
整数类型；
有唯一性
2
申请人姓名
文本类型长度为10字符
3
申请人性别
枚举类型：
男、女
4
申请人年龄
整数类型18…100
5
办理日期
格式：
**/**
6
申请人地址
登记申请者的目前住址
7
证件类型
文本类型
8
证件号码
整数类型
9
申请人电话
10
信用分数
11
状态
是否审核成功
12
信用卡号
13
联系人住址
联系人现有住址
14
申请人出生日期
15
信用额度
合格，不合格
16
数据
17
消费时间
整数型
18
消费地点
19
存钱数
整型
20
取钱数
21
联系人电话
22
联系人与申请人关系
文本
23
申请人拥有的产品种类
24
申请人拥有的卡数
25
密码
整数
图3.1.5后台管理流程
3.1.1数据项
表3.1.1数据项表
3.1.2数据结构
表3.1.2数据结构
数据结构名
属性
申请者信息开卡
申请者编号、姓名、性别、年龄，出生日期，住址，身份证号
数据处理
数据录用，数据检查数据审阅
验证
验证，电话验证，数据验证
审核
信用度，信用额度高低，是否失信银行
成功办理
根据留取地址给申请人发卡
收取成功
跟踪管理使用记录
用户使用
对用户信息进行维护
3.1.3数据流
表3.1.3数据流
数据流名
输入
输出
信用卡申请者基本信息开卡
填写信息
基本的信息
审核过程
合格可以办理
不合格结束
数据处理信息
通过录入
不通过丢掉
电话验证
电话号
验证是否成功
用户信息监测
用户信用额度
是否合格
办卡成功
留取信息
发送信用卡
联系人信息
收卡人信息
用户消费
消费记录
消费金额时间地点等
3.1.4数据存储
表3.1.4数据存储
数据存储名
输入数据流
输出数据流
信用卡申请者信息
基本信息
信用卡办理成功
数据信息
各种数据
信用卡本人资料
审核信息
信用卡申请者资料
审核成功资料
所有申请者资料
办理成功的卡
联系人电话地点
成功办理的信用卡
成功申请着
跟踪数据
用户消费记录
金额时间地点
用户信息维护
用户个人信息
3.1.5.处理过程
表3.1.5.处理过程
处理过程名
收集申请者信息
终端
处理数据
把数据进行分类整理
申请者资料
进行一系列录用管理
电话验证成功
审阅
审核是否通过
办理成功
所有信息
发卡
收卡人成功收卡
使用记录
使用金额时间地点
用户消费情况
3.2概念结构设计
申请成功的E-R图
申请者（申请者姓名，性别，年龄，出生日期，身份证号，住址）
数据（数据录入，验证，审核，电话验证，数据验证，数据检查，审阅）
信用卡（申请人信息，信用卡使用记录）
图3.2.1审阅过程的E-R图
用户信息（姓名，性别，年龄，身份证号，住址）
信用审核（信用额度，信用）
图3.2.2发卡过程E-R图
联系人（电话，住址，姓名）
后台管理者（信用卡发放管理，信息记录，）
图3.2.3联系人E-R图
第一步：
合并
解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。
各分E-R图之间的冲突主要有三类：
1．属性冲突：
属性域冲突，即属性值的类型、取值范围或取值集合不同。
由于本系统较简单，所以并不存在这种冲突；
属性取值单位冲突。
由于本系统较简单，不存在这类冲突；
2．命名冲突：
同名异义：
由于本系统较简单，所以不存在这类冲突；
异名同义：
由于本系统较小，所以不存在这类冲突；
3．结构冲突：
同一对象在不同应用中具有不同的抽象：
本系统在需求分析阶段原本存在这种冲突，考虑到后期的简化合并，我们在设计各个分E-R图就早先解决了这个问题，即将在任何一个分E-R图中作为实体出现的属性全部作为实体；
同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同：
4．第二步：
修改和重构
5．消除不必要的冗余，生成基本E-R图。
6．由于本系统涵盖的内容比较少，基本不存在冗余的现象，所以初步E-R图就是基本E-R图，不必再进行调整。
下面给出E-R图。
7．总E-R图:
信用审核人（信用额度，信用）
\
图3.2.4总的E-R图
3.3逻辑结构设计
3.3.1实体所对应的关系模式
信用卡（卡号，信用卡使用记录）
联系人信息（姓名，性别，年龄，身份证号，住址）
后台管理者（管理开发信用卡，后期维护信息）
用户（消费记录，信息维护）
3.3.2联系所对应的关系模式
把申请开卡者与申请次数n:
m的开卡关系转化为相应的关系模式
开卡（申请人信息，申请开卡）
把开卡与信息审核进行n:
m的信息审核关系转化为相应的关系模式
审核（信息录入和一系列审核，与联系人的关系）
其他关系转换
申请者与联系人的n:
m关系进行合并
申请者与信用卡1:
1关系进行合并
申请者与信息数据1:
1的关系
申请者与电话1：
n的关系
后台管理者与联系人n:
m的关系
联系人与信用卡1：
信用卡与消费记录1：
后台管理者与管理消费记录n:
由于每个关系都符合传递函数依赖所以没有达到第三范式的，又由于每个个体都是单独的原子结构体所以都符合第一范式。
开卡过程与信息审核过程存在部分函数依赖关系所以是第二范式，信息审核与成功办理信用卡也是部分函数依赖关系所以也是第二范式。
客户的开卡信息与信息维护关系存在完全函数依赖所以是属于第一范式。
联系人与申请者的关系存在完全函数依赖所以属于第一范式。
信用卡与信用卡使用联系之间也是完全函数依赖属于第一范式。
后台管理者与信用卡发放之间的为部分函数依赖属于第二范式。
后台管理者与信息维护之间的关系为部分函数依赖属于第二范式。
3.3.3.用户子模式设计
开卡系统用户子模式
申请开卡者（申请者，姓名，性别，电话，住址，身份证号，申请卡类型，）
审核系统用户子模式
管理者（数据录入，验证，检查，审批，电话验证，）
发卡用户子模式
联系人（信用卡号，联系人姓名，电话住址，）
后期管理用户子模式
管理者（用户信息追踪调查，信用卡消费记录，信用卡用户信息维护）
3.4物理结构设计
经过分析可知，本信用卡管理系统中信息处理的特点如下：
开卡，和用户信息的维护，以及用户信用卡消费记录的跟踪不仅经常需要查询而且更新速度快列如信用卡记录的查询和跟踪记录。
开卡过程中要求审核的信息比较多，列如申请人的姓名，性别，年龄，住址，证件号等这些私人信息一般不共享。
后台管理者有一定的特殊职能：
列如汇总所有开卡人的信息，从所有信用卡的账户中调查信息。
针对这些问题设计如下
3.4.1确定数据库的存放位置
为了提高系统性能，现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。
同时，考虑到本系统是多用户的，为了提高效率，数据库的备份的数据和日志文件将保存在磁带中。
经常存取部分：
开卡人（姓名，性别，年龄，电话，住址，身份证号）
联系人（姓名，电话，住址）
用户（信用卡用的记录，数据地点，金额）
后台管理者（信用卡跟踪记录，信用卡的信息维护）
信用卡（卡号，消费记录）
存取频率较低的部分：
信用卡信息（信用卡人的信息，电话，录入验证审核等）
用户个人信息（用户的住址，电话，性别年龄等）
信用审核人（信用额度，和信用卡张数）
开卡数（总共开信用卡数，信用卡种类）
用户信用卡消费记录（消费的金额度，和消费信息）
3.4.2创建索引
createuniqueindexscion后台管理者（信用卡消费记录）
createuniqueindexlxron联系人（联系人电话）
createuniqueindexsqkkzxxon申请开卡者信息（申请者姓名,申请者身份证号）
createuniqueindexsjon数据（数据录入）
createuniqueindexxykon信用卡（信用卡卡号）
createuniqueindexxyshon信用审核（信用额度）
3.5数据库实施
3.5.1代码
createtable后台管理者1
（
信用卡发放数量numericnotnull,
信用卡种类char（20）notnull,
信用卡消费记录varchar（20）
constraintPc_okkprimarykey（信用卡发放数量,信用卡种类）
）
createtable申请开卡者信息1
Mpe_sIdintegernotnull,
sIdvarchar（254）notnull,
sNamevarchar（254）notnull,
sTelvarchar（254）null,
sTypeintegernull,
sAmountnumericnull,
ssexvarchar（254）null,
Mbi_sIdintegernull,
constraintPv_MCLIENTprimarykey（Mpe_sId）
createtable联系人
Mpe_slIdintegernotnull,
sIdvarchar（254）notnull,
splacevarchar（254）null,
Mbi_sIdintegernotnull,
constraintPK_lxrprimarykey（Mpe_slId）
createtable数据1
数据录入integernotnull,
审核数据varchar（254）notnull,
数据检查varchar（254）null,
数据验证varchar（254）null,
数据审查charnull,
电话验证varchar（254）null,
constraintPxK_lxrprimarykey（数据录入）
）
createtable信用卡1
（
kahaochar（20）notnull,
xnumintegernotnull,
sjlvarchar（254）null,
sjcxxvarchar（254）null,
stelvarchar（254）null,
constraintPxqK_lxrprimarykey（kahao）
createtable信用审核
slrintegernotnull,
sshvarchar（254）notnull,
sjcvarchar（254）notnull,
syzvarchar（254）notnull,
ssnintegernotnull,
stelvarchar（254）notnull,
constraintscprimarykey（slr）
3.5.2创建视图
createviewsub_联系人
asselect联系人姓名,联系人电话,联系人住址
from联系人
where联系人姓名='
佳佳'
图3.5.1创建视图
3.5.3修改视图
updatesub_联系人
set联系人住址='
湖北'
where（联系人姓名='
佳佳'
图3.5.2更改视图
图3.5.3创建表截图
图3.5.4系统表截图
图3.5.5信用卡表截图
图3.5.6开卡信息登记表截图
图3.5.7数据表截图
图3.5.8联系人表截图
图3.5.9信用卡发放表截图
图3.5.10信用卡信息表截图
图3.5.11申请人信息表截图
图3.5.12信用审核表截图
3.5.4存储过程
use信用卡管理系统
go
createprocedurejiaas
select*
from申请开卡者信息
where申请者姓名='
王五'
图3.5.13存储过程截图
createprocedureInsertRecord
@mimavarchar（20）,
@numint,
@deptNvarchar（12）,
As
insertinto信用卡values（@mima,@num,@dept）
createprocedurejiasong
@deptvarchar（12）,
select@num=信用卡号
from信用卡
where信用卡号=@num
3.5.5触发器的建立
当在信用卡表中删除某一个信用卡卡号时，在后台管理表中信用卡使用记录也会被删除。
createtriggerdel_信用卡on信用卡
afterdelete
as
deletefrom后台管理者
where后台管理者.信用卡消费记录
in（select信用卡消费记录fromdeleted）
图3.5.14建立信用卡触发器截图
创建一个触发器safety,精细化i修改和删除当前数据库中的任何表
createtriggersafety
ondatabase
fordrop_table,alter_table
asprint'
不能删除或修改数据库表！
'
rollback
go
图3.5.15修改信用卡触发器截图
3.5.6查看触发器
execsp_helptrigger'
信用卡'
go
图3.5.16查看信用卡触发器截图
3.5.7使触发器无效并验证
select*intotsfrom信用卡
droptablets
disabletriggersafrtyondatabase
droptablets
图3.5.17使信用卡触发器无效截图
3.6数据库运行与维护
在导入前，我们手中需要有数据库的备份文件。
一般情况下就是数据库的源文件，有2个，分别是mdf和ldf文件，也就是数据库的数据文件和日志文件。
可以直接把SQLServer暂停，然后用备份的源文件覆盖现在的初始源文件，然后启动SQLServer。
注意这种办法要先开通这个数据库，保持源文件名要一致，这样才能直接覆盖。
还有一种办法就是附加数据库，把mdf和ldf文件直接附加，系统会自动生成一个数据库。
下面是截图：
如果你的空间商一定要第一种备份文件才能还原，可以先通过这种附加方法把数据库生成，然后在企业管理器中导出备份文件即可。
注意上面的附加为：
项目要写准备还原的数据库名称。
用SQL网页管理器导入备份文件。
这种办法需要先安装一个web界面的SQLServer管理器，类似于管理MySQL的PHPmyadmin。
3.6.1数据库备份过程
连接到相应的
Microsoft
SQLServer数据库引擎
实例之后，在“对象资源管理器”中，单击服务器名称以展开服务器树。
展开“数据库”，选择用户数据库，或展开“系统数据库”，选择系统数据库。
右键单击数据库，指向
“任务”，再单击
“备份”。
将出现
“备份数据库”
对话框。
在“数据库”列表中，确认数据库名称。
或者从列表中选择其他数据库从“备份类型”下拉列表中，选择“完整”
Use信用卡管理系统
Go
Exetsp_addumpdevice’disk’,’puss’,c:
\backdev\backdevpub.bak’
3.6.2数据库还原过程分析
首先打开SQL2012，到登录界面，我们选择数据库引擎连接登陆sql服务器。
登陆成功后，在sql最左端的资源管理器中的数据库一项上面鼠标右键选择还原数据库。
打开数据库还原的界面，在源下面选择设备→...（浏览），然后点击添加，寻找到备份数据库的路径，点击确定。
当跳转到还原界面之后，由于我们的备份文件较大有7个多G，这时候我们就要修改还原的路径，在选择页选择文件，然后修改还原为路径到其他盘符。
点击确定，这时候我们就还原了一个数据库文件了。
图3.6.1还原数据库过程图
图3.6.2还原数据库过程的步骤图
第4章结束语
通过这学期的数据库学习，让我学到了很多东西，熟悉了sqlserver作表软件，也认识到了mysql功能的强大，也将平时所学到的书本上的知识运用到实践中，提高了我综合运用知识的能力。
对数据库的选择和对数据存储结构的设计，使各个实体之间的耦合度小，在此基础上实现数据的完整性，以及数据表间关系满足范式的要求，也提升了我多数据库的了解与运用能力。
对于本次的课设，我做的是信用卡管理系统，信用卡管理系统拥有了对信用卡及信用卡持卡人的信息管理的基本功能，并可以对信用卡的信息进行查询，对持卡人的信息查询。
系统还包括了后台管理者的信息管理与维护。
首先我做的是需求分析模型。
先分析出信用卡管理系统的涉众有客户、申请开卡人，后台管理者，联系人。
然后定义了系统边界。
通过分析系统边界找到了业务主角，进而确定了业务用例，业务用例包括了开卡着信息管理，后台统计对用户的信息管理
升级会员 