支付平台数据库设计文档

支付平台数据库设计文档
支付平台数据库设计文档

电子商务平台一期数据库设计文档

版本号:1.00

二○一〇年十月

修改记录

目录

1前言 (8)

1.1命名规范 (8)

1.2说明 (8)

1.3术语清单 (8)

1.4数据库表清单 (9)

2基础平台核心数据库表结构(zmc) (10)

2.1账户 (10)

2.1.1客户子账户表SubAccount (10)

2.1.2子账户冻结/注销流水SubAccount_Oper (10)

2.1.3客户子账户资金变动流水表SubAccountSeq (11)

2.1.4客户子账户资金冻结流水表SubAccountFreezeSeq (12)

2.2交易 (13)

2.2.1

2.2.2提现交易流水WithDrawBILL (14)

2.2.3 支付交易流水PayBILL (15)

2.2.4批量代收付交易信息表(BatchInfo) (19)

2.2.5撤销交易流水UndoPayBILL (20)

2.2.6

2.2.7 (22)

2.2.8内部调账交易流水AdjustBiLL (23)

2.2.9外部系统交易通知SHOP_NOTIFY (24)

2.3会计帐务 (24)

2.3.1科目日记账表(SUBJECT_DAY) (24)

2.3.2试算平衡表(Balance_Check) (24)

2.3.3科目类型表(SUBJECTTYPE) (25)

2.3.4凭证类型表(PZTYPE) (25)

2.3.5凭证科目对应表(PZSUBJECT) (25)

2.3.6科目明细表(SUBJECT) (26)

2.3.7凭证明细表(PZ) (26)

2.4系统参数 (27)

2.4.1序列 (27)

2.5渠道 (27)

2.5.1渠道清算指令(Channel_Settle_Cmd) (27)

2.5.2渠道参数(Channel_Parm) (27)

2.5.3渠道返回码对照表(Channel_RtnCode) (28)

2.5.4渠道交易流水对照表(BILLNo_SN) (28)

2.5.5批量交易渠道批次表(Channel_Batch) (29)

2.5.6系统日志(Channel_Sys_Log) (30)

2.5.7渠道对帐表(Channel_Check) (31)

2.5.8渠道对帐不平明细表(Channel_CheckDetail) (31)

2.5.9同城超时等待表(TC_OVERTIME_WAIT) (33)

2.5.10同城批量撤销表(TC_BATCHCANCEL) (34)

2.5.11同城费项代码对应表(CHANNEL_FEECODE_CHG) (34)

2.5.12同城对帐指令表(TC_CHECK_CMD) (34)

2.5.13同城对账表(TC_CHECK) (35)

2.5.14同城对账明细表(TC_CHECK_DETAIL) (35)

2.5.15明细下载回应表(CHECK_DOWN) (36)

2.5.16明细下载回应清单(CHECK_DOWN_DETAIL) (36)

2.5.17交易查询查复表(Trans_Query) (37)

3系统管理数据库表结构 (38)

3.1系统维护 (38)

3.1.1服务监控主表(MONITORAPPGROUP ) (38)

3.1.2服务监控明细表(MONITORAPPDETAIL) (38)

3.1.3系统日志(Sys_Log) (39)

3.1.4平台功能描述表(PlatForm_Fun) (40)

3.1.5管理平台操作日志(Operate_Log) (40)

3.1.6通知公告栏(Public_Bulletin) (40)

3.1.7服务产品管理(Service_Product) (41)

3.1.8黑白名单表(BW_List) (41)

3.2权限 (41)

3.2.1登陆用户基本信息表(LOGIN_INFO) (41)

3.2.2角色信息表(ROLE_INFO) (42)

3.2.3登陆用户角色表(LOGIN_ROLE) (43)

3.2.4角色权限表(ROLE_PRIVILEGE) (43)

3.2.5权限信息表(PRIVILEGE) (43)

3.2.6权限资源表(PRIVILEGE_RESOURCE) (44)

3.3权限组 (44)

3.3.1权限组信息(LIMITGROUP) (44)

3.3.2权限分组表(LIMIT_GROUP_PRIVILEGE) (45)

3.4账户 (45)

3.4.1快付通结算账户余额表(BankAccount_Balance) (45)

3.4.2子账户类型表(SUBACCOUNT_TYPE) (46)

3.4.3子账户互转控制表(SUBACCOUNT_TRANSCTRL) (46)

3.4.4客户已验证银行账户表CustBankCard(管理平台) (46)

3.4.5客户子账户与银行账户绑定表(SubAccountBindCard) (47)

3.4.6账户与银行帐户绑定流水表kftbindact_bill(管理平台) (47)

3.4.7 账户验证流水AccountVerifyBILL(管理平台) (47)

3.4.8代付业务绑定的收款账户(PAY_BINDBANKACOUNT) (48)

3.5客户信息 (49)

3.5.1 客户信息表(CUST_INFO) (49)

3.5.2登录证书表(LOGIN_CERTIFICATE) (50)

3.5.3客户证件扫描件表(CustCert_Scan) (50)

3.5.4商户信息管理(管理员维护)(Merchant_Info) (51)

3.5.5客户级别管理(CUST_LEVEL) (51)

3.5.6客户开通业务列表(Cust_ServiceList) (52)

3.5.7商户开通业务列表(Merchant_SERVICE_List) (52)

3.5.8客户订阅通知表(Cust_AlarmType) (52)

3.5.9客户投诉建议(CUST_SERVICE) (52)

3.5.10登记注册类型(Register_T ype) (53)

3.5.11行业分类(Industry_Type) (53)

3.6协议 (53)

3.6.1协议范本(PROTOCOL_TEXT) (53)

3.6.2协议类型表(PROTOCOL_TYPE) (54)

3.6.3客户银行代收协议(CKB_Protocol) (54)

3.6.4快付通商户与平台外客户三方代收协议(NotKft_PROTOCOL)(走无协议代扣渠

道)54

3.6.5快付通商户与平台内客户三方代收协议(Kft_PROTOCOL) (55)

3.6.6商户代理关系表(Merchant_ProxyRelation) (56)

3.6.7客户计费信息表(Cust_Fee_Rule) (56)

3.6.8企业代收付协议(PROTOCOL_PARTYP AYEE) (56)

3.6.9汇款充值协议(PROTOCOL_REMIT) (57)

3.6.10卡通协议(PROTOCOL_KFTCARD) (57)

3.7业务参数 (58)

3.7.1费用代码表(Fee_Code) (58)

3.7.2银行类型表(BANK_TYPE_INFO) (58)

3.7.3城市代码表(City_Code) (58)

3.7.4行名行号表(Bank_Code) (59)

3.7.5银行开通业务表(Bank_Service)(门户展示给客户用) (59)

3.8系统参数 (59)

3.8.1结算帐号配置表 (59)

3.8.2运行参数(RunParm) (60)

3.8.3系统参数(SYSP ARM) (61)

3.8.4定时计划定义表(TASKDEFINE) (61)

3.8.5定时计划执行表(TASKLIST) (62)

3.8.6后台定时服务表(TimerAppServer) (62)

3.8.7客户通知消息(Cust_AlarmMessage) (63)

3.9手续费管理 (64)

3.9.1商户服务种类表(收费标准接口)(Cust_Service_Type) (64)

3.9.2提现计费规则(DrawMoney_Rule) (64)

3.9.3计费方法(FEE_METHOD) (64)

3.9.4计费方法明细(FEE_METHOD_DETAIL) (65)

3.9.5定期手续费表(Regular_ServiceFee) (66)

3.9.6客户支付交易计分规则表(Cust_PointCalcRule) (66)

3.10限额管理 (67)

3.10.1客户使用额度控制表(Cust_UseAmountCtl) (67)

3.10.2交易额度(DEAL_AMOUNTCTRL) (67)

3.10.3大额资金代付交易额度(BigAmount_DFLimit) (68)

3.10.4监控额度配置表(Watch_Limit) (68)

数据库设计文档模板

图书管理系统 数据库设计文档 1152795 毕明瑜 1152737 钱鹏 1152736 徐云帆 1152667 吴辰 092796 蔡旭远 102995 冯智超 1252973 于航 1252859 尹巧 1253011 胡亦成 1252990 魏印文

目录 1.图书管理系统数据需求 (1) 1.1 图书管理系统功能数据需求 (2) 1.2 组织结构 (3) 2.概念设计 (4) 2.1 总体E-R图 (4) 2.2 图书管理系统模块E-R图 (5) 3.逻辑设计 (9) 3.1 表的设计 (9) 3.1.1user表 (10) 3.2 数据库关系图 (11) 附录A.图表索引 (13)

1. 图书管理系统数据需求 通过建立一个基于C/S系统的图书管理系统,使得图书管理工作系统化、规范化和自动化,从而提高了管理的效率,也方便了读者的借阅。应用C#编程,实现对数据库信息的管理。系统应用符合图书馆信息管理及处理的规定,满足图书管理员对图书及借阅信息进行管理的需求,并达到操作过程中的直观、方便、使用、安全等要求。系统用模块化程序设计的方法,既便于系统功能的组合和修改,又便于参与技术人员补充和维护。 数据字典: 数据流编号: D01 数据流名称:读者信息简述:读者信息 数据流来源:读者借阅后,管理员将读者信息输入计算机。 数据流去向:图书管理模块。读者信息将存入数据库(读者信息表)。数据项组成:读者姓名+学号+专业 数据流编号: D02 数据流名称:图书信息简述:图书信息 数据流来源:新书到馆后,管理员将图书信息输入计算机。 数据流去向:图书管理模块。读者信息将存入数据库(图书信息表)。 数据项组成:图书编码+图书类别+书名+作者+出版社+Price 单价+出版日期+购买数量 数据流编号: D03 数据流名称:读者情况简述:读者情况 数据流来源:图书被借阅后,计算机将读者信息返回给管理员。数据流去向:管理员。 数据项组成:已借图书+已借数量+续借次数 数据流编号: D04 数据流名称:图书情况简述:图书情况 数据流来源:图书被借阅后,计算机将图书信息返回给管理员。数据流去向:管理员。 数据项组成:书名+是否被借+已借次数

支付平台数据库设计文档 -之令狐文艳创作

数据库设计文档 版本号:1.00 二○一〇年十月 项目情况 修改记录 目录 1前言11 1.1命名规范11 1.2说明11 1.3术语清单11 1.4数据库表清单12 2基础平台核心数据库表结构(zmc)13 2.1账户13 2.1.1客户子账户表SubAccount13 2.1.2子账户冻结/注销流水SubAccount_Oper13

2.1.4客户子账户资金冻结流水表 SubAccountFreezeSeq15 2.2交易15 2.2.1充值交易流水RechargeBILL15 2.2.2提现交易流水WithDrawBILL16 2.2.3支付交易流水PayBILL17 2.2.4批量代收付交易信息表(BatchInfo)21 2.2.5撤销交易流水UndoPayBILL22 2.2.6退款交易流水RefundBill23 2.2.7汇款交易流水WaitingRechargeBILL24 2.2.8内部调账交易流水AdjustBiLL25 2.2.9外部系统交易通知SHOP_NOTIFY25 2.3会计帐务26 2.3.1科目日记账表(SUBJECT_DAY)26 2.3.2试算平衡表(Balance_Check)26 2.3.3科目类型表(SUBJECTTYPE)26 2.3.4凭证类型表(PZTYPE)26 2.3.5凭证科目对应表(PZSUBJECT)27 2.3.6科目明细表(SUBJECT)27 2.3.7凭证明细表(PZ)27 2.4系统参数28 2.4.1序列28 2.5渠道28

2.5.1渠道清算指令(Channel_Settle_Cmd)28 2.5.2渠道参数(Channel_Parm)29 2.5.3渠道返回码对照表(Channel_RtnCode)29 2.5.4渠道交易流水对照表(BILLNo_SN)29 2.5.5批量交易渠道批次表(Channel_Batch)31 2.5.6系统日志(Channel_Sys_Log)31 2.5.7渠道对帐表(Channel_Check)32 2.5.8渠道对帐不平明细表(Channel_CheckDetail)32 2.5.9同城超时等待表(TC_OVERTIME_WAIT)34 2.5.10同城批量撤销表(TC_BATCHCANCEL)34 2.5.11同城费项代码对应表(CHANNEL_FEECODE_CHG)35 2.5.12同城对帐指令表(TC_CHECK_CMD)35 2.5.13同城对账表(TC_CHECK)35 2.5.14同城对账明细表(TC_CHECK_DETAIL)36 2.5.15明细下载回应表(CHECK_DOWN)36 2.5.16明细下载回应清单(CHECK_DOWN_DETAIL)37 2.5.17交易查询查复表(Trans_Query)错误!未定义书签。 3系统管理数据库表结构38 3.1系统维护38 3.1.1服务监控主表(MONITORAPPGROUP )38 3.1.2服务监控明细表(MONITORAPPDETAIL)38 3.1.3系统日志(Sys_Log)38 3.1.4平台功能描述表(PlatForm_Fun)39

学生管理系统数据库设计文档范文

学生管理系统数据库设计文档

学生选课系统 数据库表结构设计(09软工第八组) 12月

目录 1.1. 管理员信息表.......................................... 错误!未定义书签。 1.2. 新闻信息表 (3) 1.3. 教学楼信息表 (3) 1.4. 专业信息表 (4) 1.5. 课程信息表 (4) 1.6. 选课时间信息表 (4) 1.7. 新闻类别信息表 (5) 1.8. 通知信息表 (5) 1.9. 教室信息表 (5) 1.10.学生专业信息表 5 1.11.学生信息表 错误!未定义书签。 1.1 2.学生课程信息表 错误!未定义书签。 1.13.教师课程信息表 错误!未定义书签。 1.14.教师信息表

7 1.15.教师所在院系信息表 (7) 1.16.学院信息表 7 2.1. 各个表之间的关系 (8) 1.1. 管理员信息表 create table Admin ( AdminId (PK,bigint, not null) /*管理员ID号*/ AdminKey (nvarchar(50),not null) /*管理员密码 */ AdminPhone (nvarchar(50), null) /*管理员电话号码 */ AdminAge (int,null) /*管理员年龄 */ AdminEmail (nvarchar(50), null) /*管理员邮箱 */ AdminName (nvarchar(50), null) /*管理员名字 */ ) 索引: 对AdminId唯一索引

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。 同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。 例如,存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以 sp_开头,扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

电话计费管理系统数据库设计

课程设计 题目:电话计费系统 系别: 专业: 姓名: 学号: 指导老师: 河南城建学院 2012年12 月8日

电话计费管理系统 一、需求分析 1)背景 随着电信运营领域垄断因素的逐步消除,以及中国加入WTO后所面临的开放的电信市场,我国电信领域的竞争日益激烈。电信市场的竞争逐步从简单的价格战转向高层次的服务竞争,运营商把提高服务能力作为核心竞争力。 计费系统作为业务运营支撑系统的基础,其准确性和有效性至关重要,计费系统的错误将直接影响结算、账务及客户管理系统的处理结果。由于我国电信用户的基数很大,计费系统任何微小的偏差所造成的损失都是巨大的。该系统信息来源主要有管理员添加,方便网站管理员的查询和管理。该系统的任务是方便,灵活的管理用户的各项信息。 2)总体描述 对电信部门电话计费业务进行调查,设计的系统要求: ●能够记录通话信息,如来电号码、去电号码、通话时长、通话费用,查 询费用帐单等信息具体对各种数据文件装入和修改数据的功能。 ●能在用户交费同时打印发票。 ●能用关系数据库理论建立几个数据库文件来存储用户信息,收费员信息 和收费信息等资料。 ●能够为用户提供查询各种记录的功能 3)功能需求 3.1查询模块

月花费查询:客户可对每月的话费进行查询(每项记录包括通话 费、新业务费、费用合计、实缴费用合计等信息)。 帐户余额查询:客户可查询话费单上的余额。 用户资料查询:客户可以查阅个人资料。 电信业务查询:客户可以实时了解电信部门的各项活动。 3.2计费模块 缴费信息:管理员可根据用户所缴的话费进行计费,并反馈给用 户,用户在交费的同时可打印发票。 3.3基本信息更新模块 月话费管理:管理员可对每月的话费记录进行逐条添加、更新和 删除。 客户受理结果:管理员可对每月的话费记录进行逐条添加、更新 和删除。 4)数据流程图

学生成绩管理系统数据库设计文档 - (全)

“学生成绩管理”数据库设计文档 0、前言(一些必要的说明。) 0.1 数据库说明 数据库名:PXSCJ 逻辑名称:学生成绩数据库 数据文件:PXSCJ.mdf 日志文件:PXSCJ_Log 登录名:admin,密码:123456 0.2表命名说明 Cjb:成绩表,保存选课信息 Cxb:查询表,记录boolean值对应信息,1代表男,0代表女。Kcb:课程表。 Tjb:统计表,统计成绩段分布。 Xsb:学生表。 Yhb:用户表,保存系统用户信息。 Jsb: 教师表。 Skb:授课表,记录授课信息。 0.3 系统功能模块图

1、需求分析阶段 说明:学生成绩管理系统需要实现以下功能:一个学生可以选修多门课程,一门课程可以由多个学生选修,学生选修一门课会有一个成绩。一个教师可以教授多个班级,一个教师也可以教授多门课程,一个班级有多个学生,一门课程也可以由多个老师来上,一个老师给一个班级上一门课有确定的时间和地点。不同的用户根据身份不同拥有不同的权限。 (1)数据流图 老师----成绩管理,学生信息管理,权限管理---学生成绩管理系统—成绩查询--学生(要求:用visio实现第一层数据流图,第二层数据流图,第三层数据流图)p121 第一层数据流图 第二层数据流图 第三层数据流图(略) (2)数据字典 (每个实体的详细说明)

2、概念设计阶段 (1)分ER图 (两个分ER图,1)学生和课程,2)教师,课程,班级)

(2) 总ER 图 (由分ER 图画出总ER 图) 3、 逻辑设计阶段 (1) 表关系图 (看是否可以画出) (2) 表结构图 Xsb 结构

系统数据库设计模板

版本信息记录 日期版本说明作者审核批准

目录 1引言 (3) 1.1编写目的 (3) 1.2背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2概述 (4) 2.1数据库环境 (4) 2.2命名规则 (4) 2.3使用它的程序 (4) 3物理设计 (4) 3.1标识符 (4) 3.2物理文件 (5) 3.3表空间设计 (5) 3.3.1表空间1 (5) 3.3.2表空间2 (5) 4结构设计 (5) 4.1实体关系 (5) 4.2实体说明 (6) 4.3实体设计 (6) 4.3.1数据表1 (6) 4.3.2数据表2 (7) 4.4序列实体 (7) 4.4.1序列1 (8) 4.4.2序列2 (8) 4.5视图实体 (8) 4.5.1视图1 (8) 4.5.2视图2 (8) 4.6存储过程实体 (8) 4.6.1存储过程1 (8) 4.6.2存储过程2 (8) 5安全设计 (9) 6备注 (9)

1引言 1.1编写目的 [说明编写这份系统数据库设计文档的目的,指出预期的读者。] 注:正文字体为宋体小四号,全文统一。 1.2背景 a.[待开发数据库的名称和使用此数据库的软件系统的名称;] b.[列出本项目的任务提出者、开发者、用户。] 1.3定义 [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 表1.1术语定义表 1.4参考资料 [列出有关的参考资料。] A.本项目经核准的计划任务书或合同或相关批文; B.属于本项目的其他已发表的文件; C.本文件中各处引用的文件资料,包括所要用到的软件开发标准; 列出这些文件的标题、文件编号、发表日期和出版单位,说明能够取得这些文件的来源。

网店信息及销售管理系统数据库设计文档

数据库设计文档目录 1. 引言 1.1 编写目的 1.3 定义 1.4 参考资料 2. 外部设计 2.1目标 .................................................. .5 2.2标识符和状态 .......................................... .5 2.3约定 .................................................. .5 2.4运行环境 .............................................. .5 2.5专门指导 .............................................. .6 3. 数据流图 .......................................... 6 4. 数据词典 .............................................. 10 5. 功能概述 5.1系统功能概述 .......................................... .11 5.2系统功能模块 ............................................. .13 6. 结构设计 6.1概念结构设计 ............................................. .16 6.2逻辑结构设计 ............................................. .17 6.2.1表的结构 .......................................... ..17 6.2.2 表的关系图 ........................................ .22 7. .................................................................................................................... 其 1.2 背景 (4) .4 .4 .4

模板-项目管理-设计-数据库设计说明书

项目管理体系文件数据库设计说明书 编撰人: 审核人: 审核日期: 保密级别: 文档版本: XXXXXXXXXXXXXXXXXXXXXXXX公司

版本历史

目录 1.引言 (2) 1.1.编写目的 (2) 1.2.背景 (2) 1.3.术语 (2) 1.4.参考资料 (2) 2.总模型图及对象列表 (2) 2.1.总模型图 (2) 2.2.对象列表 (3) 2.2.1.表列表 (3) 2.2.2.视图列表 (3) 2.2.3.存储过程列表 (3) 2.2.4.触发器列表 (4) 3.表信息 (4) 3.1.表的中文名称+物理表名 (5) 3.2.表的中文名称+物理表名 (5) 4.视图信息 (6) 4.1.视图中文名称+物理名称 (6) 4.2.视图中文名称+物理名称 (6) 5.存储过程信息 (6) 5.1.存储过程1 (6) 5.2.存储过程2 (7) 6.触发器信息 (7) 6.1.触发器名称1 (7)

1.引言 1.1.编写目的 {说明编写数据库设计说明书的目的,指出预期的读者。} 1.2.背景 {描述系统产生的背景,包括: a、需开发的软件系统的名称,和英文缩写(可选),项目编号(可选); b、列出此项目的任务提出者、开发者 c、软件系统应用范围、用户。} 1.3.术语 {列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。} 1.4.参考资料 {本节列出用得着的参考资料,如: 属于本项目的其他已发表的文件; 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位。} 2.总模型图及对象列表 2.1. 总模型图 {给出系统数据库模型图。通过模型图,能够反应库表之间存在的各种关系。}

数据库设计文档

学院 ~ 数据库课程设计报告$ ( ) 电子技术系 ! 专业班级 学生姓名 指导教师 . 实习地点

# / 数据库设计文档 一、系统需求分析报告(数据流图、数据词典和功能分析) 系统应具有售票、查询、管理和维护等功能,系统管理员可以进行对车次的更改、票价的变动及调度功能,票价的修改可以通过修改运价来进行,车次调度可通过对发车时刻表的修改来进行,维护功能即可对表进行修改。 1、功能需求 经过分析后确定系统应具备以下功能: — (1)、售票功能 ①销售车票 ②预订车票 ③退票 (2)、查询功能 ①— ②车次查询 ③时刻表查询 ④售票情况查询 (3)、调度功能 ①运价修改 ②~ ③车辆修改 ④终点站修改 ⑤车次修改 (4)、维护功能 ①车票表修改 ②— ③预订车票表修改 ④退票表修改

⑤密码修改 (5)、统计功能 ①售票统计 ②¥ ③报表打印 2、数据流图 使用结构化分析方法,确定系统的数据主要是运价、车次、终点站名、发车时间和车票,对数据的操作主要有运价修改、车次修改、终点站修改、发车时间修改、售票及打印,可以确定系统的处理逻辑和流程,得到如下所示的系统数据流图。 ) 3、数据字典: 经过分析可以得到以下数据流条目: 车次表=车辆编号+车型+座位数 终点站名表=站名+里程 运价表=车型+运价 { 发车时刻表=车次+车辆编号+站名+发车时间+检票口

已售车票表=票号+乘车日期+车次+站名+发车时间+票价+全半价+工号+退票否 预订车票表=预订号+乘车日期+车次+站名+发车时间+车型+票价+客户名称+订票数量退票表=票号+退票时间+票价+应退款 售票员编号=工号+姓名 ) 车辆编号=6{数字}6 车次=4{字符}5 车型=1{字符}8 座位数=2{数字}2 检票口=1{数字}2 ` 站名=1{字符}10 里程=1{数字}5 运价=1{数字}6 发车时间={时间} 乘车日期={日期} , 票号=7{数字}7 票价=1{数字}5 全半价=2{字符}2 退票否={T|F} 预订号=4{数字}4 % 客户名称=6{字符}20 订票数量=1{数字}2 退票时间={日期时间} 应退款=1{数字}5 工号=3{字符}3 》 姓名=4{字符}8 二、数据逻辑结构设计(E-R图、关系模式和数据库结构) 1、E—R图

订货管理系统数据库设计

订货管理系统数据库设计 1.需求分析 1.1背景 商业企业中,货物销售时,订购是关键的环节。它直接关系到企业的销售业绩,而在一个企业中,销售是关系到企业生存的关键。随着时代的发展,货物订购仅靠人力手工完成已经无法满足企业发展的需要。而对商业企业来说,只有订货量越多的时候,才可能产生更多的利润。使用订货管理系统来协助销售部门管理订单成为提高部门效率成为必须。 1.2客户需求 (1)订货系统可以帮助销售部门得到正确的订货。正确的订货有以下好处: 1.保证销售; 2.保证毛利; 3.保证顾客满意; 4.维护企业形象; (2)相对于系统订货方式,手工订货常常产生错误的订货,这些订货信息给企业带来了损失: 1.缺货,损失销售,损失利润; 2.库存积压,资产资金周转慢,占据有效的仓库容量; 3.增加员工的劳动量,增加盘点难度; 4.库存维持成本增加,损耗增加; (3)企业要求开发的订货管理系统能够达到一定的标准,让订货行为变得准确可靠,并且系统能提供给部门提供相应的信息服务,为销售计划提供参考: 1.准确的系统(ETP)库存与实际库存一致; 2.库存均为有效可销售库存(耗损品除外); 3.计算订货,送货周期和订货数量(经济批量订货法); 4.设立科学,浮动的最低库存;

5.考虑现有库存和在途送货量; 6.考虑促销和价格竞争因素; 7.考虑节日因素; 8.考虑商品成本因素; 9.考虑市场期货因素; (4)很多的因素决定了订货的种类,数量,时间和密度,正确的订货能够有效的帮助企业赢利.并且好的订货系统能够监控订货的合理性. 1.好的订货管理系统=好的销售+好的利润+好的顾客效益! 2.订货是销售部门主管义不容辞的责任! 1.3功能需求 系统应该主要完成三种订购方式的处理工作,这三种方式分别是电话订购,网上订购和当面订购。以下对这三种订购方式进行分析。 (1)电话订购时由销售部门相关人员对电话内容进行记录,得到客户要订购的货物的详细情况,这些情况应该覆盖货物订单的内容,货物订单的内容由相关人员进行填写,并填进系统数据库,系统通知发货部门可以发货,并给发货部门一张订货合同,其内容包括发送的货物,发货的地点,收货人,时间,无人认领的处理方法等订货时的约定信息等内容,在收货人取得货物,交付货款后需要在订货合同上签字确认。

毕业设计管理系统数据库设计文档

访问统计 数据库设计文档 编写: 编写日期: 审核日期: 批准日期:

变更记录 签字确认

目录 1.1预期的读者 (4) 1.2数据库 (4) 1.2.1数据库类型及版本 (4) 1.2.2数据库命名规范 (4) 1.3目的和作用 (5) 2数据库设计 (5) 2.1物理结构设计 (5) 2.2数据库表结构设计 (5) 2.2.1访问统计......................................................................... 错误!未定义书签。

引言 预期的读者 1)项目经理 2)客户项目经理 3)系统开发人员 4)系统测试人员 数据库 数据库类型及版本 数据库类型:MySQL 版本:5.5.15 数据库命名规范 1、数据库表 根据表所属的子系统/模块,命名方式为: 数据库表名 = 子系统_模块 2、表字段 概念模型中,每个数据库中为每个表定义唯一的缩写 字段名为多个单词的组合时,第一个单词首字母小写,其他单词的首字母大写; 字段名为多个单词的组合时,若单词过长,截取3-5个字母 3、索引 索引名 = Idx + _ + 表缩写 + 相关字段/索引含义 4、关联 关联指数据库表之间的外键关系 关联名 = rl + _ + 主表 + 从表 (首字母大写) 5、存储过程

存储过程名 = proc + _ + 存储过程含义(首字母大写) 目的和作用 将数据分析的结果进一步整理,形成最终的计算机模型,以便开发人员建立物理数据库。 数据库设计 物理结构设计 数据库表结构设计 毕业设计管理系统 用户表(user)

数据库设计文档

— 学院 数据库课程设计报告> < 电子技术系 ~ 专业班级 学生姓名 指导教师 实习地点 (

: 数据库设计文档 一、系统需求分析报告(数据流图、数据词典和功能分析) 系统应具有售票、查询、管理和维护等功能,系统管理员可以进行对车次的更改、票价的变动及调度功能,票价的修改可以通过修改运价来进行,车次调度可通过对发车时刻表的修改来进行,维护功能即可对表进行修改。 1、功能需求 经过分析后确定系统应具备以下功能: (1)、售票功能 ①销售车票 ②预订车票 ③' ④退票 (2)、查询功能 ①车次查询 ②时刻表查询 ③售票情况查询 (3)、调度功能 ①运价修改 ②车辆修改 ③( ④终点站修改 ⑤车次修改 (4)、维护功能 ①车票表修改 ②预订车票表修改 ③退票表修改 ④密码修改 (5)、统计功能 ①、 ②售票统计

③报表打印 2、数据流图 使用结构化分析方法,确定系统的数据主要是运价、车次、终点站名、发车时间和车票,对数据的操作主要有运价修改、车次修改、终点站修改、发车时间修改、售票及打印,可以确定系统的处理逻辑和流程,得到如下所示的系统数据流图。 、 3、数据字典: 经过分析可以得到以下数据流条目: 车次表=车辆编号+车型+座位数 终点站名表=站名+里程 运价表=车型+运价 发车时刻表=车次+车辆编号+站名+发车时间+检票口 已售车票表=票号+乘车日期+车次+站名+发车时间+票价+全半价+工号+退票否) 预订车票表=预订号+乘车日期+车次+站名+发车时间+车型+票价+客户名称+订票数量退票表=票号+退票时间+票价+应退款 售票员编号=工号+姓名

车辆编号=6{数字}6 车次=4{字符}5 车型=1{字符}8 座位数=2{数字}2 检票口=1{数字}2 ¥ 站名=1{字符}10 里程=1{数字}5 运价=1{数字}6 发车时间={时间} 乘车日期={日期} 票号=7{数字}7 票价=1{数字}5 全半价=2{字符}2 ( 退票否={T|F} 预订号=4{数字}4 客户名称=6{字符}20 订票数量=1{数字}2 退票时间={日期时间} 应退款=1{数字}5 工号=3{字符}3 姓名=4{字符}8 二、! 三、数据逻辑结构设计(E-R图、关系模式和数据库结构) 1、E—R图 》

数据库技术设计文档要求(计应)

数据库技术设计要求和报告规范 一、设计要求 1、4人一组,设有组长一人,每人都要有明确分工,按每人的分工完成情况评分。 2、自选题目,通过设计掌握数据库的设计的每个步骤,提交各步骤所需图表和文档。 3、独立完成设计,如有抄袭,成绩按零分计算。 4、设计步骤: (1)需求分析:根据自己的选题,进行分析并书写相关的文字说明。 (2)概念结构设计:绘制所选题目详细的E-R图。 (3)逻辑结构设计:将E-R图转换成等价的关系模式;按需求对关系模式进行规范化。 (4)物理结构设计:选定实施环境,存取方法等。 (5)数据实施和维护:用DBMS建立数据库结构,加载数据。 5、报告内容参考 第1章系统分析 1.1开发背景 1.2需求分析 第2章系统功能设计 2.1 功能设计 2.2 系统功能模块 第3章数据库设计 3.1数据库需求分析 3.2数据库概念结构设计 3.3数据库逻辑结构设计 3.4数据库物理结构设计 3.5 数据库实施 包括每个表的创建、视图的创建、索引的建立、函数、存储过程、触发器的创建。至少应包括表的创建,包括主键、外键和各种约束。 二、课程设计报告规范 1、说明书(论文)基本格式 报告打印时正文采用5号宋体,A4纸,页边距均为20mm,行间距采用18磅。 2、说明书(论文)结构及要求 ⑴封面(样例见附件) 包括:题目、系别、班级、完成日期及指导教师、学生姓名等项。 ⑵目录 要求层次清晰,给出标题及页次。 打印时各章题序及标题用小4号黑体, 其余用小4号宋体。

⑶正文 正文应按照目录所确定的顺序依次撰写,要求计算准确,论述清楚、简练、通顺,插图清晰整洁。文中图、标及公式应规范地绘制和书写。

支付平台数据库设计文档

内部资料 注意保密 电子商务平台一期数据库设计文档版本号:1.00 二○一〇年十月项目情况 修改记录

目录 1 前言 8 1.1 命名规范 8 1.2 说明 8 1.3 术语清单 8 1.4 数据库表清单 9 2 基础平台核心数据库表结构(zmc) 10 2.1 账户 10 2.1.1 客户子账户表SubAccount 10 2.1.2 子账户冻结/注销流水SubAccount_Oper 10 2.1.3 客户子账户资金变动流水表SubAccountSeq 11 2.1.4 客户子账户资金冻结流水表SubAccountFreezeSeq 12 2.2 交易 13 2.2.1 充值交易流水RechargeBILL 13 2.2.2 提现交易流水WithDrawBILL 14 2.2.3 支付交易流水PayBILL 15

2.2.4 批量代收付交易信息表(BatchInfo) 19 2.2.5 撤销交易流水UndoPayBILL 20 2.2.6 退款交易流水RefundBill 21 2.2.7 汇款交易流水WaitingRechargeBILL 22 2.2.8 内部调账交易流水AdjustBiLL 23 2.2.9 外部系统交易通知SHOP_NOTIFY 24 2.3 会计帐务 24 2.3.1 科目日记账表(SUBJECT_DAY) 24 2.3.2 试算平衡表(Balance_Check) 24 2.3.3 科目类型表(SUBJECTTYPE) 25 2.3.4 凭证类型表(PZTYPE) 25 2.3.5 凭证科目对应表(PZSUBJECT) 25 2.3.6 科目明细表(SUBJECT) 26 2.3.7 凭证明细表(PZ) 26 2.4 系统参数 27 2.4.1 序列 27 2.5 渠道 27

新闻管理系统数据库设计说明书

新闻管理系统数据库设计说明书 目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2外部设计 (2) 2.1标志符和状态 (2) 2.2使用它的程序 (2) 2.3约定 (2) 2.4专门指导 (5) 2.5支持软件 (5) 3结构设计 (5) 3.1概念结构设计 (5) 3.2逻辑结构设计 (11) 3.3物理结构设计 (11) 4运用设计 (15) 4.1数据字典设计 (15) 4.2安全保密设计 (16)

1引言 1.1编写目的 本文档为新闻管理系统的数据库设计报告,为新闻管理系统的设计主要依据,主要针对新闻管理系统的概要设计和详细设计人员,作为项目验收的主要依据。 1.2背景 (1)待开发的软件系统名称:新闻管理系统 (2)本项目的任务提出者:team小分队 (3)开发者:team小分队 (4)用户:社会各阶级人群,主要人群大学生 1.3定义 (1)可靠性(Reliable),软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。 (2)安全性(Secure),软件系统所承担的交易的商业价值非常高,系统的安全性非常重要。(3)可伸缩性(SCAlable),软件必须能够在用户的使用率、用户的数目增长很快的情况下,保持合理的性能。只有这样,才能适应用户市场拓张的可能。 (4)可定制化(CuSTomizable),同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。 (5)可扩展性(Extensible),在新技术出现的时候,一个软件系统应当导入新技术,从而对现有系统进行功能和性能的拓展。 (6)可维护性(MAIntainable),软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有的系统中去。一个易于维护的系统可以有效地降低技术支持的花费。 (7)客户体验(Customer Experience),软件系统必须易于使用。 (8)市场时机(Time to Market),软件用户要面临同业竞争,软件提供商也要面临同业竞争,以最快的速度争夺市场先机非常重要。 1.4参考资料 《软件工程》

软件数据库设计报告模板

软件数据库设计报告模板

软件数据库设计报告文档模板 1. 引言4 1.1编写目的 (4) 1.2项目来源 (5) 1.3文档约定 (5) 1.4预期读者和阅读建议 (5) 1.5参考资料 (6) 2. 数据库命名规则7 3. 数据库设计说明7 3.1数据库逻辑设计 (7) 3.2数据库物理设计 (8) 3.3数据库分布 (8) 3.4基表设计 (10) 3.5视图设计 (13) 3.6索引设计 (15) 3.7完整性约束 (17) 3.8授权设计 (18) 3.9触发器设计 (19) 3.10存储过程设计 (20) 3.11数据复制设计 (21) 4. 词汇表24 5. 历史数据处理25

1. 引言 引言是对这份数据库设计说明书的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份数据库设计说明书是为哪份软件产品编写的,开发这个软件产品意义、作用以及最终要达到的意图。通过这份数据库设计说明书

详尽准确地描述了该软件产品的数据库结构。如果这份数据库设计说明书只与整个系统的某一部分有关系,那么只定义数据库设计说明书中说明的那个部分或子系统。 1.2 项目来源 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括: ●任务提出者; ●软件开发者; ●产品使用者。 1.3 文档约定 描述编写文档时所采用的各种排版约定。排版约定应该包括: ●命名方法; ●提示方式; ●通配符号: ●等等。 1.4 预期读者和阅读建议 列举本数据库设计说明书所针对的各种不

数据库设计文档(样例)

XXXXX系统-X班X组 第I页共15页XXXX系统 数据库设计说明书

文档信息: 文档名称“传输网管数据统一自动备份系统”概要设计说明书 描述该文档描述传输网络统一自动备份系统的详细功能定义。所有设计人 员、开发人员、测试人员以及其他团队成员都应该以该文档作为产品 的功能定义,并衍生出其他文档。 负责人谢亚龙张亚宾 状态 1.1版 文档变更历史: 时间版本号修改人章节描述 2008-11-7 1.0 所有章节创建初稿 2008-12-19 1.1 部分改动对数据中部分做了修改 文档路径: 审核结果: 审核人审核时间意见签名档备注

目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (5) 1.3定义 (5) 1.4参考资料 (6) 2数据库物理模型 (7) 2.1整体设计 (7) 2.2角色与权限管理 (7) 2.3消息管理 (9) 2.4用户信息 (10) 2.5分站信息表 (12) 2.6备份计划 (13) 2.7备份文件 (14)

1引言 随着时代的进步,计算机技术飞速发展,电子信息技术在各行各业起着越来越重要的作用。其中,应用最广泛的就是数据库技术。对一个企业来说,数据的安全关系着整个企业的发展,如何更加安全的保护这些数据,是当今的一个研究热点。 为了保护数据安全和提高数据的持续可用性,企业要从RAID保护、冗余结构、数据备份、故障预警等多方面考虑。对于关键业务应用,如电信计费系统、银行营业系统等,则要采用异地数据备份的保护措施。应该说,异地自动备份是数据安全性和业务连续性的最高保护级别。数据存放在一个地方总存在风险,况且人为的逻辑错误也有可能破坏数据,因而,可以采用高性能、完善的备份系统,将数据拷贝下来,存放到价廉的存储介质上,这是数据安全的基本保证。企业最常使用的备份介质包括:磁盘、光盘塔和磁带库等。同时,在系统或应用出现故障时,为了保证本地业务的不中断运行,主机集群是一个较好的方案。 现在,随着企业对数据可用性认识的加深,关键业务不允许出现哪怕是1%的灾难威胁,因而,异地数据备份已成为数据可用性解决方案的重要组成部分。异地容灾系统提供一个远程的应用备份现场,能有效地防止因本地毁灭性灾难(地震、火灾、水灾等)引起的数据丢失,预防场地问题带来的数据不可用性。这些场地问题包括:电力中断、电信中断、自然灾难和场地迁移等。作为企业的关键业务,任何原因造成的业务中断都将影响其经济收入,降低市场分额,丢失客户,甚至造成企业破产。数据自动统一备份系统将这种“场地”故障造成的数据不可用性减到最小。当灾难发生时,自动备份系统能保证企业数据的安全和业务的连续性。 为了避免这种情况的发生,传输网管自动统一备份这么一个系统就显得及其重要,及时对重要数据的备份能把企业的损失将到最小,这也是我们这个项目的最终目标。 1.1编写目的 本文档的编制是为了让用户和软件开发者双方对该开发软件的初始规定有一个共同的理解,定义所要开发的“传输网管数据统一自动备份系统”(以下简称系统)的开发目标,包括对功能的规定和性能的要求,指出预期的系统用户、系统的运行环境以及对用户操作的约定,使之成为整个项目中软件产品开发设计与实现的根据,也是软件产品的测试和验收的

软件数据库设计模板

软件数据库设计报告 ?目录 1. 引言 (2) 1.1编写目的 (2) 1.2项目来源 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5参考资料 (2) 2. 数据库命名规则 (3) 3. 数据库设计说明 (3) 3.1数据库逻辑设计 (3) 3.2数据库物理设计 (3) 3.3数据库分布 (3) 3.4基表设计 (3) 3.5视图设计 (4) 3.6索引设计 (4) 3.7完整性约束 (4) 3.8授权设计 (4) 3.9触发器设计 (4) 3.10存储过程设计 (4) 3.11数据复制设计 (5) 4. 词汇表 (5) 5. 历史数据处理 (5)

1. 引言 引言是对这份数据库设计说明书的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。 编写目的 说明这份数据库设计说明书是为哪份软件产品编写的,开发这个软件产品意义、作用以及最终要达到的意图。 项目来源: 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括 ●任务提出者; ●软件开发者; ●产品使用者。 文档约定 描述编写文档时所采用的各种排版约定。排版约定应该包括: ●命名方法; ●提示方式; ●通配符号: ●等等。 预期读者和阅读建议 列举本数据库设计说明书所针对的各种不同的预期读者,并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。 ●开发人员; ●项目经理; ●测试人员; ●文档编写人员。 参考资料 列举编写需求规格说明书时所用到的参考文献及资料

● 2. 数据库命名规则 完整并且清楚的说明本数据库的命名规则 3. 数据库设计说明 数据库逻辑设计 在此处,应给出逻辑设计的完整的E-R图。 数据库物理设计 在此处应给出完整的数据库物理结构E-R图。开发者应根据逻辑设计的结果,进行数据库的物理设计,并对表结构进行规范化处理(第一范式,第二范式,第三范式)。 数据库分布 基表设计

数据库设计文档

数据库设计文档

1 文档介绍 1.1编写目的 作为软件设计文档的重要组成部分,本文档主要对该软件后台数据库的概念模型设计和物理模型设计作出了统一的规定,同时确定了每个表的数据字典结构。它是开发人员,测试人员编码及测试的重要参考依据。 1.2适用范围 本概要设计文档提供给系统设计开发人员,包括详细设计人员和项目组成员,不得提供给公司外人员。 1.3 读者对象 本文档的主要读者包括: 1. 本系统的设计人员:包括模块设计人员 2. 本系统的系统开发人员:包括数据库开发、编码人员 3. 本系统的测试人员 1.4 参考文献 主要为人资信息管理系统.ppt、人资信息管理系统需求分析与概要设计。 2 数据库环境说明 数据库采用Micrsoft SQL Server数据库管理系统建立并维护。数据库设计过程中采用Micrsoft公司的Visio创建进销存数据库的ER图,并生成数据库脚本文件“数据库设计.DDL”。其中SQL Server的登录模式为混和身份验证,超级用户的用户名均为sa,密码为:123456,SQL Server服务器的端口号:1433。

3 数据库的命名规则 符合3个范式: 主键外键关系、表间关系、表中字段是不可再分的属性。 表的表示:描述单一信息,功能简单实用、命名规范合理。 字段的类型,长度。 数据库的命名:采用全部大写形式。 如:人资管理系统,数据库名称为RSHGL(人事管理)。 数据库表命名:所有表以RSH_开头,后面跟中文拼音缩写,采用全部大写形式。 如:职工基本信息表数据库名称为RSH_ZHGJBXX 4逻辑设计 本系统的数据库按照面向对象的思想,设计对应实体类,由实体类生成对应的数据库表,数据表中的关系,反应了对象间的关系 5数据库的实施 本系统基于SQL Server 2008 R2,数据库的名称为:DB_OA,由SendMessage、ReadMessage、Role、RolePrivilege、Privilege、User、RecordBackUp、Plan、Company共10个数据表组成。如表所示 表数据库表的功能说明 序号表功能说明 1SendMessage发送消息数据表 2ReadMessage阅读消息数据表 3Role角色数据表 4RolePrivilege角色-权限数据表

支付平台数据库设计文档

电子商务平台一期数据库设计文档 版本号:1.00 二○一〇年十月

修改记录

目录 1前言 (8) 1.1命名规范 (8) 1.2说明 (8) 1.3术语清单 (8) 1.4数据库表清单 (9) 2基础平台核心数据库表结构(zmc) (10) 2.1账户 (10) 2.1.1客户子账户表SubAccount (10) 2.1.2子账户冻结/注销流水SubAccount_Oper (10) 2.1.3客户子账户资金变动流水表SubAccountSeq (11) 2.1.4客户子账户资金冻结流水表SubAccountFreezeSeq (12) 2.2交易 (13) 2.2.1 (13) 2.2.2提现交易流水WithDrawBILL (14) 2.2.3 支付交易流水PayBILL (15) 2.2.4批量代收付交易信息表(BatchInfo) (19) 2.2.5撤销交易流水UndoPayBILL (20) 2.2.621 2.2.722 2.2.8内部调账交易流水AdjustBiLL (23) 2.2.9外部系统交易通知SHOP_NOTIFY (24) 2.3会计帐务 (24) 2.3.1科目日记账表(SUBJECT_DAY) (24) 2.3.2试算平衡表(Balance_Check) (24) 2.3.3科目类型表(SUBJECTTYPE) (25) 2.3.4凭证类型表(PZTYPE) (25) 2.3.5凭证科目对应表(PZSUBJECT) (25) 2.3.6科目明细表(SUBJECT) (26) 2.3.7凭证明细表(PZ) (26) 2.4系统参数 (27) 2.4.1序列 (27) 2.5渠道 (27) 2.5.1渠道清算指令(Channel_Settle_Cmd) (27) 2.5.2渠道参数(Channel_Parm) (27) 2.5.3渠道返回码对照表(Channel_RtnCode) (28) 2.5.4渠道交易流水对照表(BILLNo_SN) (28) 2.5.5批量交易渠道批次表(Channel_Batch) (29) 2.5.6系统日志(Channel_Sys_Log) (30) 2.5.7渠道对帐表(Channel_Check) (31) 2.5.8渠道对帐不平明细表(Channel_CheckDetail) (31)

相关文档
最新文档