支付平台数据库设计文档 -之令狐文艳创作
大数据下移动支付的运营
大数据是一个术语，就是一大堆你无法处理的数据，他们的关系非常复杂，有结构化的，半结构化的，也有非结构化的，而且这部分还是占大多数。
在一个迅速变得更加智能的世界里，人们每天都会产生大量的信息并上传到互联网。
这些数据通常可以为企业提供令人难以置信的数据趋势等方面的信息。
数据现在以多种形式出现，从网站cookies到社交媒体帖子，这意味着处理这些信息并不容易。
现代世界中数据的非结构性导致越来越先进的分析程序的出现，试图理解这些巨量的数据。
大体而言，大数据是指这些数据集，这些数据集太大，不能再通过传统的分析方法进行处理。
大数据分析的目标是产生洞察力，转化为有形的商业利益，这些可能与实时事件甚至未来趋势有关。
容量（Volume）：数据的大小决定所考虑的数据的价值和潜在的信息种类（Variety）：数据类型的多样性速度（Velocity）：指获得数据的速度可变性（Variability）：妨碍了处理和有效地管理数据的过程真实性（Veracity）：数据的质量复杂性（Complexity）：数据量巨大，来源多渠道价值（value）：合理运用大数据，以低成本创造高价值（二）大数据分析的好处1.能更加全面的看待问题在今天更精简的大数据分析产品之前，回答诸如“谁是我最好的10个客户”这样看起来很简单的问题可能需要长达60天才能被业务团队分析。
即使在找出正确的标准之后，实际编制和分析数据也是一个耗时的过程。
问题变得越来越复杂，负担就越来越大。
例如，在“谁是最差顾客”这个问题上，试图弄清楚判断这10个最差客户的标准是困难的。
之后，实际收集和分析数据可能是一个非常密集的过程。
在实际的商业世界中，几乎不可能及时地以相关的方式来回答。
大数据最重要的好处之一就是能够更方便地提出问题和回答问题。
回答复杂问题的整个过程可以从几个星期，几个星期缩短到几天甚至几个小时或几分钟。
2.数据更加准确当您将大数据并入业务决策的问答过程中时，您不仅可以更全面地查看答案，还可以获得更准确的视图。
登录注册支付接入平台需求文档N
需求概况：一、服务端PC后台1、PC后台参考如下，后台查如下运营数据的，包括注册，登陆人数，时间，充值人数、留存等。
2、PC后台需要从客户端中抓数据信息，比如IP，区域、手机号等。
3、各渠道的支付统计。
二、安卓客户端1、客户端注册等SDK，有客户端注册，登陆，修改密码，注册账号，进入游戏，一鍵注册，要做一个自己的SDK，同时360、91等各渠道有自身的SDK。
在我们开发者接入时，我们要求打包集成一个统一的支付标准接口，在开发者接入时只需要接入一次SDK，就能完成所有的渠道方SDK的接入，只要打包一次就能完成其中一个渠道的登录注册和支付功能。
2、客户端支付SDK，包括支付宝、易宝、银联一鍵支付等要做一个自己的SDK，同时应用开发者需要接入渠道方的SDK，包括百度、360、91等，在我们开发者接入时，我们要求打包集成一个统一的支付标准接口，在开发者接入时只需要接入一次SDK，就能完成所有的渠道方SDK的接入，只要打包一次就能完成其中一个渠道的登录注册和支付功能。
如下为具体接入接口逻辑：游戏接入平台需求规格说明书拟制日期批准日期版权所有侵权必究目录1简介 (1)1.1目的 (1)1.2范围 (1)1.3定义 (1)2总体概述 (1)2.1系统角色描述 (2)2.2系统描述 (2)2.3系统功能 (2)3具体需求 (3)3.1功能需求 (3)3.1.1游戏管理 (3)3.1.2注册信息查询 (3)3.1.3充值信息查询 (3)3.1.4运营数据查询 (3)3.2用户接口需求 (4)3.2.1注册接口 (4)3.2.2登录接口 (4)3.2.3密码修改接口 (5)3.2.4充值接口 (5)3.2.5充值回调接口 (6)3.3外部接口需求 (6)3.4界面需求 (6)3.5性能需求 (6)4总体设计约束 (6)4.1标准符合性 (6)4.2硬件约束 (6)4.3技术限制 (6)5软件质量特性 (7)5.1可靠性 (7)5.2易用性 (7)1简介1.1目的游戏接入平台是一个运营平台，为不同的手机游戏客户端提供注册、登录、充值接口，同时为推广渠道提供不同的通道，并统计推广渠道的游戏运营数据。
总体设计方案怎么写
总体设计方案怎么写总体设计方案1. 引言1.1.编写目的本文档为支付平台总体概要设计说明。
概要设计说明书编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
本文档读者以开发人员为主，其他项目相关人员也可参考。
1.2.定义参考《词汇表》。
1.3.参考资料技术方面主要参考资料： 1) Spring资料 2) iBatis资料 3) Hessian资料 4) W3C XML相关规范2. 总体设计遵循的技术标准⏹本系统软件基于J2EE规范进行开发；⏹本系统软件采用Spring架构及iBatis数据库操作框架。
⏹证书应用采用符合CSP规范的证书应用体系；⏹基于PKI的安全认证和加密规范系列：PKCS＃1v2、PKCS＃7v1.5、SSL3.0/TLS1.0；⏹交易报文采用W3C XML规范、以及相关的XML Schema、XML Signatureand Encryption规范；⏹采用HAP2.0作为应用开发技术平台；⏹ 采用HADP2.0作为项目开发流程规范；⏹ Web客户支持Microsoft IE6.0及以上版本、FireFox3.0及以上版本；⏹ 通联基金支付系统与支付网关系统通讯采用Hessian技术；⏹ JAVA SUN JDK 1.4.2、J2EE1.3。
2.1.子系统设计本章节的主要定义子系统、子系统标识符、子系统的功能、以及子系统之间的关系。
2.1.1. 子系统说明2.1.2. 子系统关系说明⏹ APP层使用数据库1存储数据；⏹支付交互控制子系统把交易结果通知内容存放在数据库2中；⏹ 通知服务器从数据库2中提取交易结果通知内容并转发；⏹ 银行接口系统使用数据库3记录银行交易流水；⏹ APP层通过文件服务器与银行接口系统交换文件。
2.2.软件层次架构设计2.2.1. 软件层次架构设计图2.2.2. 软件层次架构说明系统的总体设计分为四个层次：用户界面层、处理控制层、业务逻辑层、DAO层。
mongodb数据库设计案例
mongodb数据库设计案例MongoDB数据库设计案例1. 酒店预订系统描述：设计一个酒店预订系统，包括酒店信息、房间类型、价格、预订记录等。
用户可以根据日期和地点搜索可用酒店并进行预订。
数据模型：使用集合存储酒店信息、房间类型和价格信息，使用另一个集合存储用户的预订记录，包括用户ID、酒店ID、房间类型和日期等字段。
2. 电子商务平台描述：设计一个电子商务平台，包括商品分类、商品信息、用户信息、订单信息等。
用户可以浏览商品、下订单并进行支付。
数据模型：使用集合存储商品分类信息、商品信息、用户信息和订单信息，使用嵌套文档存储订单中的商品信息。
3. 社交媒体平台描述：设计一个社交媒体平台，包括用户信息、帖子、评论等。
用户可以发布帖子、评论和点赞。
数据模型：使用集合存储用户信息、帖子信息和评论信息，使用嵌套文档存储帖子中的评论信息。
4. 新闻发布系统描述：设计一个新闻发布系统，包括新闻分类、新闻信息、作者信息等。
用户可以浏览新闻、发布评论和点赞。
数据模型：使用集合存储新闻分类信息、新闻信息和作者信息，使用嵌套文档存储新闻中的评论信息。
5. 在线教育平台描述：设计一个在线教育平台，包括课程分类、课程信息、学生信息等。
学生可以浏览课程、选课和提交作业。
数据模型：使用集合存储课程分类信息、课程信息和学生信息，使用嵌套文档存储课程中的作业信息。
6. 论坛系统描述：设计一个论坛系统，包括论坛分类、帖子、评论等。
用户可以发布帖子、评论和关注其他用户。
数据模型：使用集合存储论坛分类信息、帖子信息和用户信息，使用嵌套文档存储帖子中的评论信息。
7. 音乐播放器描述：设计一个音乐播放器，包括歌曲分类、歌曲信息、用户信息等。
用户可以浏览歌曲、创建播放列表和收藏歌曲。
数据模型：使用集合存储歌曲分类信息、歌曲信息和用户信息，使用数组存储用户的播放列表和收藏列表。
8. 个人日程管理系统描述：设计一个个人日程管理系统，包括日程分类、日程信息、提醒设置等。
二代支付系统总体技术方案
1.引言1.1.目的文档的目的是说明第二代支付系统的总体设计方案，分别对系统的物理结构、逻辑结构以及应用部署加以阐述，为下一步的系统概要设计及详细设计提供指导。
1.2.背景与目标支付系统是社会支付体系的核心和枢纽，也是经济金融运行的重要基础设施。
人民银行组织建设的第一代支付系统（主要包括大额支付系统、小额支付系统和全国支票影像交换系统三个应用系统），对加快社会资金周转、提高支付清算效率、畅通货币政策传导、促进国民经济健康平稳发展发挥着重要作用。
随着我国社会经济的快速发展，金融改革继续深入，金融市场日益完善，支付方式也不断创新，对支付清算服务提出了许多新的、更高的要求。
为此，人民银行决定立足第一代支付系统的成功经验，按照“继承发展、集中统一、安全高效、节约成本、平滑过渡”的原则，建设适应新兴电子支付发展的、面向参与者管理需要的、功能更完善、架构更合理、技术更先进、管理更简便的第二代支付系统。
2009年12月2日，中国人民银行副行长苏宁在第二代支付系统暨中央银行会计核算数据集中系统建设电视电话会议上做了《加快第二代支付系统和中央银行会计核算数据集中系统建设，进一步提高金融服务水平》的讲话，提出必须加快第二代支付系统的建设，第二代支付系统的建设提上正式日程。
我行第二代支付系统的建设既是对人民银行工作部署的认真落实，也是我行提升经营管理水平的必由之路。
第二代支付系统建成后，将取代第一代支付系统成为国内各商业银行办理跨行支付业务的核心和主要的渠道。
我行作为支付业务量最大的商业银行之一，建设行内系统有助于构建适用全国的中国现代化支付网络，是人民银行总体项目建设规划的一个重要组成部分，同时对于我行提高支付结算服务水平、拓展中间业务渠道、保持同业竞争力和防范支付结算风险具有十分重要的意义。
1.3.预期读者第二代支付系统的设计人员、开发人员、维护人员。
1.4.术语表第二代支付系统：第二代支付系统由人民银行牵头组织建设，各参与者开发行内系统及接口实现对接。
某电商平台概要设计说明书
某电商平台概要设计说明书概要设计说明书是对某电商平台的整体架构和设计进行详细描述和阐述的文档。
本文档将从以下几个方面介绍该电商平台的概要设计。
1. 介绍某电商平台是一个在线购物平台，旨在为用户提供一个便捷、安全和快速的购物体验。
平台包含商品浏览、搜索、购买、支付和物流跟踪等功能，同时还提供用户管理、商户管理和后台管理等功能。
2. 架构设计某电商平台采用分层架构，包括前端展示层、应用服务层、数据访问层和基础设施层。
2.1 前端展示层前端展示层负责呈现给用户的界面，通过HTML、CSS和JavaScript等技术实现。
前端展示层使用响应式设计，以适应不同设备和屏幕尺寸。
2.2 应用服务层应用服务层负责处理前端请求，包括用户登录、商品搜索、商品推荐和订单处理等功能模块。
该层采用面向服务的架构，每个功能模块都作为一个独立的服务。
服务之间通过RESTful API进行通信。
2.3 数据访问层数据访问层负责与数据库进行交互，负责数据的存储和读取。
平台使用关系型数据库管理商品信息、用户信息和订单信息等。
2.4 基础设施层基础设施层包括服务器、网络和安全等基础设施资源。
平台采用云服务器和负载均衡技术，以提供高可用性和可扩展性。
同时，平台还采用SSL/TLS协议进行数据传输的加密，确保用户的数据安全。
3. 功能模块某电商平台包含以下功能模块：3.1 用户管理用户管理模块包括用户注册、用户登录、个人资料管理和地址管理等功能。
用户可以在该模块中完成个人信息的录入和修改，以及查看订单历史。
3.2 商户管理商户管理模块包括商户注册、商户登录、商品管理和订单管理等功能。
商户可以在该模块中发布商品、更新商品信息，并处理用户的订单。
3.3 商品浏览商品浏览模块允许用户浏览平台上的商品，可以按照不同的分类和标签进行筛选和搜索。
用户可以查看商品的详细信息、价格和评价等。
3.4 商品搜索商品搜索模块允许用户根据关键字进行商品搜索。
平台提供高效的搜索引擎技术，以快速搜寻和匹配用户的搜索请求。
智慧迎新缴费系统设计方案
智慧迎新缴费系统设计方案智慧迎新缴费系统设计方案一、项目背景为了提高高校迎新工作的效率和便利性，我们决定设计和开发一套智慧迎新缴费系统。
该系统将整合高校的学生信息、费用信息、在线缴费功能和信息查询功能，旨在为新生提供便捷的迎新服务，并减轻学校工作人员的负担。
二、系统功能模块设计1. 学生信息管理模块：该模块用于管理学生的个人信息，包括姓名、性别、年龄、联系方式等。
学生信息可以通过系统导入或手动录入。
学生信息可以按照姓名、学院、专业等进行检索和筛选。
2. 费用信息管理模块：该模块用于管理学生的费用信息，包括学费、宿舍费、教材费等。
学生的费用信息可以通过系统导入或手动录入，也可以和学校的财务系统进行对接，实现自动更新。
学生可以在系统中查询自己的费用信息，并查看应缴费用和已缴费用的情况。
3. 在线缴费模块：该模块用于学生在线缴纳各类费用。
学生可以在系统中选择要缴纳的费用类型，填写相关信息，然后选择支付方式进行缴费。
系统支持多种支付方式，包括银行卡支付、支付宝、微信等。
系统会生成缴费凭证，并将缴费情况同步到财务系统中。
4. 信息查询模块：该模块用于学生查询迎新相关的信息。
学生可以查询入学须知、迎新日程、导师信息等。
系统会根据学生的个人信息自动推送相关信息，提醒学生注意事项。
5. 数据统计模块：该模块用于对学生信息和费用信息进行统计分析。
学校工作人员可以查看缴费情况，统计未缴费学生的人数和金额，及时与学生沟通催缴。
三、系统架构设计1. 前端设计：前端设计采用响应式布局，适配不同设备的屏幕尺寸。
通过HTML、CSS和JavaScript实现系统的用户界面和交互逻辑。
采用现代化的前端框架，如Vue.js或React，提供良好的用户体验。
2. 后端架构：后端采用分层架构，分为表现层、业务逻辑层和数据访问层。
表现层负责接收和响应前端的请求，将请求转发给业务逻辑层。
业务逻辑层负责处理具体的业务逻辑，如学生信息管理、费用信息管理等。
支付宝整体架构
交 易到 代
易
账扣
信 用 支 付
企 管业 理账
户
微 支 付
个
消
管人 积 红 转 费
理账 分 包 账 信
户
贷
收银台
收费
基础核心 登录服务
安全服务
资金处理平台
客户信息平台
核
支
账
核
付
务
算
清
会
中
会商会会 员户员员 信信等信
心 管 控
算
计
心
息息级用
内
部
系
统
（
商
业
结 算
智 能
风 控
）
第29页/共64页
二代系统建设局部效果示意
支付宝 资金流
物流公司 收款过渡户
2. 转账 买家账户
3. 转账 卖家账户
1. 充值
4. 转账 交易分润 中间账户
5. 转账
淘宝 收入账户
6. 转账
物流公司 收入账户
7. 转账
支付宝 收入账户
第45页/共64页
可伸缩: 关注容量、性能与资源使用
数据库
服务使用者
服务
服务吞吐量 伸缩公式 伸缩上限 单资源吞吐量上限 响应时间
收费系统 产品账系统
消息 系统
异步交易事件处理
风险核查 资损核查
第25页/共64页
思考: 平衡稳与快
业务增长与创新
快
业务线解放
兄 弟
航 旅
传 统
虚 拟
B 2 C
网 站
会 员
生 活 助 手
金 融 合 作
安 全
内 部 系 统
稳
安全、稳定、可伸缩
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库设计文档版本号：1.00二○一〇年十月项目情况修改记录目录1前言111.1命名规范111.2说明111.3术语清单111.4数据库表清单122基础平台核心数据库表结构(zmc)132.1账户132.1.1客户子账户表SubAccount132.1.2子账户冻结/注销流水SubAccount_Oper132.1.4客户子账户资金冻结流水表SubAccountFreezeSeq152.2交易152.2.1充值交易流水RechargeBILL152.2.2提现交易流水WithDrawBILL162.2.3支付交易流水PayBILL172.2.4批量代收付交易信息表（BatchInfo）212.2.5撤销交易流水UndoPayBILL222.2.6退款交易流水RefundBill232.2.7汇款交易流水WaitingRechargeBILL242.2.8内部调账交易流水AdjustBiLL252.2.9外部系统交易通知SHOP_NOTIFY252.3会计帐务262.3.1科目日记账表(SUBJECT_DAY)262.3.2试算平衡表（Balance_Check）262.3.3科目类型表(SUBJECTTYPE)262.3.4凭证类型表(PZTYPE)262.3.5凭证科目对应表(PZSUBJECT)272.3.6科目明细表(SUBJECT)272.3.7凭证明细表(PZ)272.4系统参数282.4.1序列282.5渠道282.5.1渠道清算指令（Channel_Settle_Cmd）282.5.2渠道参数（Channel_Parm）292.5.3渠道返回码对照表（Channel_RtnCode）292.5.4渠道交易流水对照表(BILLNo_SN)292.5.5批量交易渠道批次表(Channel_Batch)312.5.6系统日志(Channel_Sys_Log)312.5.7渠道对帐表(Channel_Check)322.5.8渠道对帐不平明细表(Channel_CheckDetail)322.5.9同城超时等待表(TC_OVERTIME_WAIT)342.5.10同城批量撤销表(TC_BATCHCANCEL)342.5.11同城费项代码对应表(CHANNEL_FEECODE_CHG)352.5.12同城对帐指令表(TC_CHECK_CMD)352.5.13同城对账表(TC_CHECK)352.5.14同城对账明细表(TC_CHECK_DETAIL)362.5.15明细下载回应表(CHECK_DOWN)362.5.16明细下载回应清单(CHECK_DOWN_DETAIL)372.5.17交易查询查复表(Trans_Query)错误!未定义书签。
3系统管理数据库表结构383.1系统维护383.1.1服务监控主表（MONITORAPPGROUP ）383.1.2服务监控明细表（MONITORAPPDETAIL）383.1.3系统日志(Sys_Log)383.1.4平台功能描述表（PlatForm_Fun）393.1.5管理平台操作日志(Operate_Log)393.1.6通知公告栏(Public_Bulletin)403.1.7服务产品管理(Service_Product)403.1.8黑白名单表(BW_List)403.2权限403.2.1登陆用户基本信息表(LOGIN_INFO)413.2.2角色信息表（ROLE_INFO）423.2.3登陆用户角色表（LOGIN_ROLE）423.2.4角色权限表（ROLE_PRIVILEGE）423.2.5权限信息表（PRIVILEGE）423.2.6权限资源表（PRIVILEGE_RESOURCE）433.3权限组433.3.1权限组信息（LIMITGROUP）433.3.2权限分组表（LIMIT_GROUP_PRIVILEGE）443.4账户443.4.1快付通结算账户余额表(BankAccount_Balance)443.4.2子账户类型表(SUBACCOUNT_TYPE)443.4.3子账户互转控制表(SUBACCOUNT_TRANSCTRL)453.4.4客户已验证银行账户表CustBankCard（管理平台）453.4.5客户子账户与银行账户绑定表(SubAccountBindCard)453.4.6账户与银行帐户绑定流水表kftbindact_bill（管理平台）463.4.7账户验证流水AccountVerifyBILL（管理平台）463.4.8代付业务绑定的收款账户(PAY_BINDBANKACOUNT)473.5客户信息473.5.1客户信息表(CUST_INFO)473.5.2登录证书表（LOGIN_CERTIFICATE）493.5.3客户证件扫描件表（CustCert_Scan）493.5.4商户信息管理 (管理员维护)（Merchant_Info）493.5.5客户级别管理（CUST_LEVEL）503.5.6客户开通业务列表(Cust_ServiceList)503.5.7商户开通业务列表（Merchant_SERVICE_List）503.5.8客户订阅通知表(Cust_AlarmType)503.5.9客户投诉建议(CUST_SERVICE)513.5.10登记注册类型（Register_Type）513.5.11行业分类（Industry_Type）513.6协议513.6.1协议范本(PROTOCOL_TEXT)513.6.2协议类型表(PROTOCOL_TYPE)523.6.3客户银行代收协议（CKB_Protocol）523.6.4快付通商户与平台外客户三方代收协议（NotKft_PROTOCOL）（走无协议代扣渠道）523.6.5快付通商户与平台内客户三方代收协议（Kft_PROTOCOL）533.6.6商户代理关系表(Merchant_ProxyRelation)543.6.7客户计费信息表(Cust_Fee_Rule)543.6.8企业代收付协议(PROTOCOL_PARTYPAYEE)543.6.9汇款充值协议(PROTOCOL_REMIT)543.6.10卡通协议（PROTOCOL_KFTCARD）553.7业务参数553.7.1费用代码表(Fee_Code)553.7.2银行类型表(BANK_TYPE_INFO)563.7.3城市代码表(City_Code)563.7.4行名行号表(Bank_Code)563.7.5银行开通业务表(Bank_Service)（门户展示给客户用）563.8系统参数573.8.1结算帐号配置表573.8.2运行参数(RunParm)573.8.3系统参数（SYSPARM）583.8.4定时计划定义表（TASKDEFINE）593.8.5定时计划执行表（TASKLIST）593.8.6后台定时服务表（TimerAppServer）593.8.7客户通知消息（Cust_AlarmMessage）603.9手续费管理603.9.1商户服务种类表（收费标准接口）(Cust_Service_Type)613.9.2提现计费规则（DrawMoney_Rule）613.9.3计费方法（FEE_METHOD）613.9.4计费方法明细（FEE_METHOD_DETAIL）623.9.5定期手续费表(Regular_ServiceFee)623.9.6客户支付交易计分规则表（Cust_PointCalcRule）633.10限额管理633.10.1客户使用额度控制表(Cust_UseAmountCtl)633.10.2交易额度（DEAL_AMOUNTCTRL）643.10.3大额资金代付交易额度（BigAmount_DFLimit）643.10.4监控额度配置表（Watch_Limit）653.10.5黑名单配置(B_Watch)653.10.6白名单配置(W_Watch)653.11支付管理653.11.1渠道类型(Channel_Type)653.11.2渠道管理（PAY_CHANNEL）663.11.3渠道账户对照表（Channel_Bank_Account）663.11.4账户验证渠道表(Account_CheckRoute)673.11.5协议签订渠道表(Protocol_SignRoute)673.11.6支付路由表（PAY_ROUTE）673.11.7调拨指令表(FlitCommand)683.12报表683.12.1分渠道交易统计报表(PAY_CHANNEL_DEALREPORT)683.12.2商户交易统计报表(CUST_DEALREPORT)693.12.3结算户支出报表（BALANCEACT_PAYOUT_REPORT）693.12.4从快付通结算户入监管户报表（MONITERACT_PAYIN_REPORT）693.12.5监管户出账报表(MONITERACT_PAYOUT_REPORT)703.12.6基金交易日报表（FUND_DAY_REPORT）703.12.7当日大额提现交易监控(Day_BigAmount_Watch)713.12.8累计提现交易监控(Total_Amount_Watch)713.12.9信用卡交易监控(Credit_Amount_Watch)713.12.10对公转对私交易监控(Trans_Amount_Watch)713.12.11两客户互转监控(Trade_Amount_Watch)723.13门户网站业务表723.13.1收款请求交易表（Web_RequestMoney）723.13.2门户个人登录信息表(USER_LOGIN_INFO)723.13.3门户用户操作日志(USER_OPERATE_Log)733.13.4密码问题(PWD_QUESTION)734基金业务数据库表结构744.1.1批量指令表（batch_inst）744.1.2开户信息表（openAccount_info）744.1.3充提交易对帐（deposit_withdraw_check）764.1.4批次对照表（Batch_File_Map）764.1.5申购类交易信息表（buyFund_Info）774.1.6撤销交易表（abolish）784.1.7赎回类交易表（redeem_info）794.1.8对账结果表（Check_Account）804.2基金基础数据804.2.1基金信息表（fund_info）804.2.2基金公司（InstCorp_info）814.2.3基金平台各连接节点开通业务表（Fund_Limit）814.2.4客户已开通基金公司账户表（Cust_Inst_Map）814.2.5基金代销对照表(inst_agent_map)824.2.6基金业务平台系统参数表（Fund_Sys_Parm）82 5系统基础参数835.1地区代码835.2银行种类代码835.3渠道编码835.4子帐户类型845.5卡类型定义845.6渠道自定义交易类型841前言1.1 命名规范1）数据库表名命名规范2）所有数据库表的名字用有意义的英文或英文缩写来表示，如:系统参数表的名字为SYSPARM.3）字段命名规范4）所有字段的名字用有意义的英文或英文缩写来表示，如:字段”用户代码”的名字为USERCODE.1.2 说明1）所有金额的单位为“元”2）所有的日期格式为YYYYMMDD(月份或天不够2位的前面补零)，所有的时间格式为HHMMSS，所有年月字段为YYYYMM(月份不够2位的前面补零).3）币种字段目前全部固定为RMB4）关键字用“PK”表示5）对于表中标明为自动产生的字段，表示该字段不需要人工录入，而是在追加时自动产生该字段的值1.3 术语清单交易类型代码做如下细化：网银充值：(充值)卡通充值：（实时协议代扣+有支付协议）实时提现：（实时代付）批提现：（批量代付）协议实时代扣（有支付协议）协议实时代扣（无支付协议）实时代付协议批量代扣（有支付协议）协议批量代扣（无支付协议）批量代付网银支付卡通支付（卡通充值+平台内支付）1.4 数据库表清单数据库表结构分为四个部分，第一部分为基础平台数据库表结构，第二部分为门户网站数据库表结构，第三部分为基金平台数据库表结构。