尝试分析一下“金融行业的实体关系图”

时间：2024年08月23日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

微信：wei_wei10

音频地址：https://xima.tv/1_HZL8jc?_sonic=0

希望大家帮个忙！如果大家有工作机会，希望帮小蒋内推一下，小蒋希望遇到一个认真做事的团队，一起努力。需要简历可以加我微信。

大家好，欢迎来到小蒋聊技术，小蒋准备和大家一起聊聊技术的那些事。

今天小蒋准备和大家一起聊的这个技术就厉害了！那就是软件开发中的ER图。

引言

小蒋最近得到ER图，经过分析后得知，它是金融行业的一个ER图，小蒋今天将要和大家一起聊一聊这张ER图。这张图看起来像是个复杂的蜘蛛网，但别担心，小蒋将会陪大家一起把它一一捋顺，尝试理解一下它背后的业务逻辑和系统设计。

什么是ER图？

ER图，全称实体关系图（Entity-Relationship Diagram），是用来描述系统中数据结构的一种工具。它展示了数据表（实体）之间的关系，帮助我们理解数据的组织方式以及各个部分如何协同工作。简单来说，就是让复杂的系统一目了然，方便我们去理解和设计。

为什么ER图很重要？

ER图能够以直观、可视化的方式展示数据结构和各实体之间的关系。对于复杂的系统来说，ER图可以帮助团队成员快速理解系统的整体架构，看到每个数据实体（如表）的结构，以及这些实体是如何相互关联的。这种可视化有助于沟通和协作，特别是在项目团队较大或系统较为复杂的情况下。

另外，小蒋得知，这个ER图中的系统，属于证券行业，证券行业背后的业务通常都比较复杂。所以，大家要知道ER图不仅仅是技术工具，它还帮助团队明确业务需求。通过对ER图的分析，业务分析师和开发团队可以确认系统是否覆盖了所有必要的业务实体和关系。这有助于在项目早期阶段发现和解决潜在的业务需求问题，从而避免在后期进行代价高昂的返工。

总体概述

这张ER图以BOND表（Bond）为核心，围绕它展示了多个与债券交易相关的表。这些表反映了系统中不同的数据实体和它们之间的关系。小蒋会逐一分析每个表的业务含义，并给出相应的系统设计建议。

第一章：核心表BOND的深入分析

1.1 BOND表（Bond）的业务含义和设计

BOND表是整个图的核心部分，它代表了债券交易中的债券实体。在金融市场中，债券是一种投资工具，本质上是借给发行方（如政府或企业）的资金。债券持有者定期获得利息，并在到期时收回本金。

字段解释：

• TradeId：这是每个债券交易的唯一标识符，相当于债券的身份证号。
• 其他可能的字段（未在图中显示）可能包括债券的类型、发行日期、到期日期、票面利率等。

系统设计建议：

• 核心层设计：BOND表作为核心模块，应独立出来，负责管理所有与债券基本信息相关的操作。
• 垂直和水平扩展：考虑未来数据量的增加，可以将BOND表设计为垂直拆分（将不常用字段移到其他表）或水平分表（按时间或哈希值分表），以提高查询和写入性能。

1.2 BOND表的相关模块设计

BOND表连接了多个“亲戚”表，它们记录了债券的发行细节、面额、交易事件等信息。以下是一些主要关联表：

• ISSUE_DET表（Issue Details）：记录债券的发行细节，如发行金额、日期等。这是债券从“概念”到“实际存在”的过程。
• DENOM表（Denomination）：记录债券的面额信息，决定了投资者可以购买的最小单位。
• BONDEVENT表（Bond Event）：记录债券生命周期中的事件，如利息支付、到期等。
• BD_PTSETL表（Bond Partial Settlement）：记录债券交易的部分结算信息，用于管理复杂的结算过程。
• DLR_INFO表（Dealer Information）：记录债券交易中经纪商的信息，管理买卖双方之间的交易流程。

系统设计建议：

• 模块化设计：将与BOND表相关的业务拆分成独立的功能模块，如发行管理模块、面额管理模块、事件管理模块等。这有助于保持系统的灵活性和可扩展性。

第二章：债券发行与交易管理的深入探讨

2.1 ISSUE_DET表（Issue Details）的业务含义

ISSUE_DET表记录了债券的发行细节。这是债券被交易前的重要一步，涉及债券的基本信息确定，如发行金额、票面利率、发行日期等。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这笔发行属于哪一笔债券交易。
• 其他字段可能包括发行日期、发行金额等。

系统设计建议：

• 发行管理模块：设计一个独立的模块来处理债券的发行过程，包括审批、额度管理等。这样可以确保发行流程的规范性和可追溯性。

2.2 DENOM表（Denomination）的业务含义

DENOM表记录了债券的面额信息。面额决定了投资者购买债券的最小单位，是债券交易中一个关键的财务指标。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个面额信息属于哪一笔债券交易。
• Denomination：债券的面额值。

系统设计建议：

• 面额管理模块：设计一个灵活的面额管理系统，支持多种面额的债券发行和交易，并允许面额的拆分与合并，以适应不同的市场需求。

2.3 DLR_INFO表（Dealer Information）的业务含义

DLR_INFO表记录债券交易中的经纪商信息。经纪商在债券交易中扮演着中介角色，负责执行买卖指令。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个经纪商信息属于哪一笔债券交易。
• Dealer：经纪商的标识符或名称。

系统设计建议：

• 经纪商管理模块：设计一个专门的模块管理经纪商信息，包括权限管理和绩效评估，确保交易流程的高效和透明。

2.4 BONDEVENT表（Bond Event）的业务含义

BONDEVENT表记录了债券生命周期中的各种事件，如利息支付、到期等。这些事件对投资者和市场的管理至关重要。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个事件属于哪一笔债券交易。
• ADate：事件发生的日期。
• Type：事件类型，如利息支付、到期等。

系统设计建议：

• 事件管理模块：设计一个事件触发机制和通知系统，确保债券生命周期中的每个关键事件都能及时处理和通知相关方。

第三章：交易类型与配对逻辑的深入探讨

3.1 BOND_TR表（Bond Transaction）的业务含义

BOND_TR表管理债券交易的类型。债券交易类型可能非常多样化，比如直接购买、回购交易、交换交易等。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个交易类型属于哪一笔债券交易。
• TradeType：交易的类型。

系统设计建议：

• 交易类型管理模块：设计一个灵活的交易类型管理系统，能够轻松添加新类型，适应不断变化的市场需求。

3.2 TRSSIPAIR表（Transaction SSI Pair）的业务含义

TRSSIPAIR表管理债券交易的配对信息。这对于一些复杂的债券交易结构（如配对交易）非常重要。

字段解释：

• dmTrssipairId：配对交易的标识符。
• Security：与交易配对的债券标识符。

系统设计建议：

• 配对管理模块：设计一个动态配对算法模块，能够实时匹配交易对手，并处理配对失败的情况。

第四章：费用和竞标管理的深入探讨

4.1 SDACCRFEE表（Settlement Account Fee）的业务含义

SDACCRFEE表记录债券交易中的各类费用信息。费用管理是交易中的重要部分，涉及交易的成本计算。

字段解释：

• DealId：与交易相关的费用记录标识符。
• FeeType：费用类型，如手续费、管理费等。

系统设计建议：

• 费用管理模块：设计一个灵活的费用管理系统，支持不同类型费用的计算和分摊机制，确保费用处理的准确性。

4.2 SDCOMPBID表（Settlement Competitive Bid）的业务含义

SDCOMPBID表记录债券交易中的竞标信息。在某些债券发行过程中，会有多个竞标者，这个表记录了竞标结果和相关信息。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个竞标信息属于哪一笔债券交易。
• WinnerId：竞标的赢家。

系统设计建议：

• 竞标管理模块：设计一个自动化竞标系统，管理竞标的各个阶段，并对竞标历史进行分析，优化竞标策略。

第五章：信用事件的高级管理与监控

5.1 CREDEVTS表（Credit Events）的业务含义

CREDEVTS表记录债券交易中的信用事件。信用事件指的是可能影响债券价值的风险因素，如违约、评级变化等。

字段解释：

• TradeId：关联BOND表中的TradeId，表示这个信用事件属于哪一笔债券交易。
• CredEvList：信用事件的详细信息。

系统设计建议：

• 信用事件管理模块：设计一个实时监控系统，自动记录和处理信用事件，帮助投资者及时应对风险。

5.2 CRDEVT表（Credit Event）的业务含义

CRDEVT表是CREDEVTS表的扩展，记录更详细的信用事件信息。

字段解释：

• Name：信用事件的名称或类型。
• TradeId：关联BOND表中的TradeId，表示这个信用事件属于哪一笔债券交易。

系统设计建议：

• 风险分析模块：设计一个系统分析信用事件的影响，并生成风险报告，帮助投资者做出更明智的决策。

第六章：国产化替代技术选型

随着国家对信息技术安全和自主可控的要求日益提高，金融系统中的国产化替代成为了重要的战略方向。在这个背景下，我们不得不考虑如何使用国产技来实现系统中的关键组件。

6.1 数据库选型

替代方案：国产数据库是金融系统国产化替代的核心部分。推荐以下几种主流的国产数据库：

• 达梦数据库（DM）：性能稳定，支持多种数据类型，广泛应用于金融、电力、能源等行业。相比于国外的Oracle和MySQL，达梦数据库在性能和安全性上具备明显优势，尤其是在国产操作系统上的兼容性极强。
• 人大金仓（Kingbase）：与PostgreSQL高度兼容，提供了丰富的功能和工具，适合复杂业务系统。它在国内市场中表现出色，尤其是在政府和金融行业的使用场景中表现优异。
• OceanBase：蚂蚁集团推出的分布式数据库，支持高并发、海量数据处理，适合大规模分布式系统。与MySQL的替代相比，OceanBase能够在大数据处理和高可用性方面提供更好的支持。

第七章：系统整体架构的进一步优化与思考

7.1 服务化与微服务架构

在现代复杂的金融交易系统中，单体架构往往难以应对不断变化的需求。因此，建议采用服务化或微服务架构，将不同的业务功能模块独立为服务。

替代方案：

• 服务独立性：每个服务独立部署，具备自己的数据库和业务逻辑，互不干扰，提高系统的灵活性和可扩展性。
• 服务间通信：通过HTTP/REST、gRPC等协议进行服务间的轻量级通信，采用消息队列处理异步操作。使用国产的RabbitMQ替代方案如RocketMQ，能够提供高效的消息传递和任务调度。
• 服务治理与监控：引入服务网格和分布式追踪工具，确保服务的高可用性和问题的快速定位。使用国产的SkyWalking进行分布式链路追踪，帮助快速定位和解决系统中的性能瓶颈和故障。

7.2 数据库设计优化

替代方案：考虑到大数据量和高并发需求，数据库设计需要进一步优化。

• 分布式数据库：采用分布式数据库如OceanBase或国产分布式SQL数据库，能够有效处理大规模的交易数据，并提供高可用性。相比国外的Cassandra、HBase等，国产分布式数据库在本土化支持和与国产操作系统兼容性方面更具优势。
• 缓存与热数据管理：引入缓存机制， Redis分布式缓存系统，减少数据库的读写压力，提高数据访问速度。
• 数据库优化与索引：合理设计索引结构并定期优化数据库，确保高效的查询性能。可以使用人大金仓或达梦数据库提供的优化工具，进行数据库的自动调优和索引管理。

结语

今天先分享这么多，期待在“小蒋聊技术”中再次与大家见面，咱们下次再聊！