银行信息系统架构中的数据产生

1.关注重点

首先关注数据产生环节，在此环节需要分析的重点如下：

1）通过业务流程模型导出数据分类模型，是关系到数据模型能否有效支撑业务流程运转的重点。

2）数据分类模型定义了应该有什么，数据标准定义了数据从业务和技术角度被具体约束内容。

3）数据分类模型在系统中落地的关键因素是主数据管理策略。

4）物理模型设计的效率影响到了数据产生的效率。

2.设计思路

（1）定义和描述业务模型 业务模型是战略能力实现和IT应用开发的桥梁，业务模型对业务进行了标准化的定义，并且应用结构化的模型语言描述了业务能力。

业务模型以银行现状业务流程、数据现状和当前产品实践为基础，以能力需求主题中未来需要支撑的业务需求为输入，形成了目标业务模型。目标业务模型形成的目标流程模型详细定义是IT实施业务系统的坚实基础。

业务模型中每个具体的业务包括了能力的落地实现元素，比如角色、授权信息、政策、业务规则、业务信息、业务参考文档和表单报表等内容。这些描述可以叫作业务基因（DNA），有这些业务基因组合构成了业务模型的描述信息，关于这些业务基因的定义如下：

角色：执行或审批任务的工作角色。

政策：适用于本流程的业务政策。

业务规则：执行任务的顺序、约束和限制。

变化因子：产生任务变化的因素，包括客户、产品和渠道等。

会计信息：任务执行中用到的财务规则。

业务文档和表单：任务执行过程中的文档和表单。

屏幕和报表：任务执行时涉及的屏幕和报表。

授权信息：任务执行时涉及的授权级别信息。

信息：任务执行过程中负责的信息。

能力需求：为了支持能力而实现了的需求。

（2）从业务模型到流程模型 基于业务模型，银行可以展开针对业务操作的流程模型的定义。流程模型是对业务按照操作环节的逐步分解的过程。流程模型的分解一方面指导系统的构建，另外一方面定义了操作过程中数据的产生，以及在不同的操作环节中数据的流转与引用。

流程模型的描述包括流程定义以及流程规则。

1）流程定义包括任务名称、定义描述、业务需求、相关的数据、输入、输出等。

2）流程规则包括相关实体、产品条件、流程步骤、业务规则、展示方式、涉及模板（凭证、表单、报表、登记簿、合同）、政策法规制度办法等。

依托现实或者目标业务模型中，从业务领域到细节的业务处理模型，可以逐步分解为具体的每个原子级别的业务流程模型。流程模型梳理的价值在于：准确描述每一个业务操作环节；便于IT实现；对共同流程或者公用流程进行提炼，便于业务操作组件化提炼，以及基于SOA架构下服务组件的开发和调用逻辑的形成；作为数据模型的输入，准确描述流程模型涉及的数据要素，直到数据分类以及分布。

（3）提炼数据分类模型 以流程模型为输入，形成了基于流程模型的数据概念分类模型的提炼。提炼过程是对业务流程模型涉及的主体、业务操作过程中的输入、输出信息进行归类整理的过程。

经过提炼形成了以下的信息分类：

1）被描述主体，以及主体相关属性。

2）对于事件以及相关其他领域信息的详细信息项定义。

3）主体与主体，主体是事件之间因为流程定义和流程规则形成的关系。

基于此信息分类把具备相似特征的信息进行分类整理，就形成了数据分类模型。这种有效地分类模型组织可以作为企业级数据模型。

3.成熟企业级数据模型

这种企业级分类模型的提炼，可以按照方法在每个银行的业务系统构建过程中进行提炼，也可以参考业内已经提炼后的成熟的模型体系进行直接的借鉴可参考，例如，IBM的IFW模型。直接引入成熟的企业级数据模型，进行自身业务流程模型到数据模型的映射工作。

目前，国内银行在新一代银行系统咨询项目中参考的企业级数据模型都是以IBM的IFW模型为模板，同时引入的多种新一代银行系统的设计的模型参考也都是以IFW模型为参考。在IFW模型中的FSDM就是企业级数据分类模型的详细定义，在此引入FSDM模型的主题定义，对企业级数据模型进行简单的介绍，FSDM模型把数据分为9个主题域，分别是：

（1）相关方 当事人代表与银行有联络或与银行有利害关系，以及银行希望保留其信息的所有相关参与者，其中也包括银行本身。

（2）位置 位置是银行希望保存的地理位置信息，代表可找到某人某物之处，信息所在位置或界定的区域。

（3）产品 产品是银行及其关联的当事人提供给市场，能满足客户（包括内部客户）的某种需求，银行可从中赚取各种实际或潜在收益的货物（有形）与服务（无形）。

（4）合约 合约是两个或两个以上当事人之间潜在或实际的约定。合约正式提供并确认与合约目的相关的规则和义务。

（5）分类 对一个或多个数据概念的分类描述，用于对其他8类数据概念的分类描述。比如公用的如语言分类信息以及账务信息等。

（6）资源项 资源项是银行拥有、管理、使用的，或银行关心的其他当事人拥有的，有形或无形的有价值的东西。

（7）事件 事件是银行为业务目标的实现或业务的执行而希望保留的将发生或已发生的事情。

（8）条件 银行业务运作的特定或必要的条件、要求，比如利率、汇率、期限、额度等。

（9）业务方针 银行希望以何种方式在何种环境里执行业务。比如理财产品的策略（保值或者营利），银行的财务计划，政策（比如信用风险的内部评级法、标准法）等。

以上数据分类模型基本覆盖了银行业务发生所产生的基本数据信息（不包括衍生数据信息定义）。该分类模型可以作为业务系统模型构建过程中的指导和范本，保证在业务系统的数据产生完整性，这就是企业级数据分类模型的价值。因为其推演的过程是从业务定义、流程模型到数据模型的梳理。因此，系统建设过程中参考数据分类模型，基本确保了哪些业务数据应该被记录。

4.数据分类模型和数据标准的关系

数据分类模型告诉我们应该有什么数据被产生。这些产生的数据在技术和业务上的定义叫作数据标准定义，数据标准是在规定范围内达成的共识，即业务标准是大家针对数据的业务含义和业务约束达成的共识，技术标准是对数据的技术处理规范达成的共识。

通常商业银行对数据标准的分类定义也是按照数据分类模型的主题划分进行定义的。

（1）业务数据标准定义，通常解决以下问题：

1）数据分类模型的主题定义阐述：如什么是客户、什么是产品、什么是渠道等。

2）数据在某个主题域中的分类问题：如客户分为对公、对私、同业等。

3）主数据识别要素定义，以及主数据编码合理性定义。

4）主数据属性信息项梳理，以及每个信息项的具体业务含义定义。(www.xing528.com)

5）参考数据取值以及编码定义。

（2）技术数据标准，通常定义以下内容：

1）数据的类型。

2）数据的长度。

3）数据的格式。

4）数据的正则化表达规范。

5）数据的值域分布（有业务成分）。

通过数据标准规范化了数据被记录的格式，减少了大家针对数据理解的歧义，进一步规范化了数据的产生。虽然数据标准化属于数据管控的范畴，但是对数据产生环节有重要的影响，特别是对下面要探讨的主数据管理策略有直接的影响。因此在此只是进行简单的阐述。

另外从数据管控角度看，数据标准不是不变的，数据标准也有生命周期，随着时代的变化和业务的创新，大家的共识可以建立在一个新的客观环境中。因此，需要有针对定义好的标准的定期更新和维护机制，这就需要有数据的标准的管理办法来保障。

5.主数据管理与数据分布

数据分类模型决定了业务发生过程的应该记录什么的问题，数据标准决定了数据应该长什么样子，接下来需要探讨的问题就是在产生环节合理的数据分布。

谈到数据分布策略，最重要的就是主数据管理策略。因此，有必要在此把数据的基本分类方法进行一个简单的描述，讲清楚什么是“主数据”。

按照对数据规范化的了解，数据分为主数据、参考数据、事件数据、关系数据等几种主要类型。

（1）主数据（Masterdata）　指系统间共享数据（例如，客户、、账户和组织部门相关数据）。与记录业务活动，波动较大的交易数据相比，主数据（也称基准数据）一旦产生被记录之后，相对稳定，变化比较缓慢。

（2）事件数据（Transactiondata） 主要用于记录业务活动的数据，和主数据相比，一旦被记录之后不会再发生变化。

（3）参考数据（Referencedata） 指用于描主数据或者事件数据中某些信息项的取值内容的数据，也就是通常所说的业务代码表。

（4）关系数据（Relationshipdata） 用来记录主数据与主数据之间、主数据与事件数据、事件数据与事件数据之间关系的数据。牵扯到主数据的关系型数据会随着主数据自身的变化也缓慢地发生变化。从这种特性来说和主数据特性非常接近。

事件数据基本依赖于产生它的原始业务系统，事件数据在那里产生，就首先在那里进行记录和存储，后续会被搬迁，但是不存在变化。

参考数据按照其数据特征，会跟随主数据、事件数据进行存储。参考数据应该同样被记录变更历史，而且一般不会出现主键复用的问题。所以，在数据分布策略上不作太多的阐述。

关系数据同样是用来分析主数据的，主数据的存储分布策略某种意义上说决定了关系数据的存储策略。因此在所有数据分布策略中最重要的是主数据分布策略。

主数据又可以区分为主识别信息和主属性信息。从主数据产生、被引用的角度，将系统区分为主数据管理系统和从属管理系统。

1）主数据管理系统的定义：产生、记录主数据的主识别信息和主属性信息，被作为标准发布和被引用的系统。

2）从属数据管理系统的定义：可以引用主数据的主识别信息和主属性信息，在自己的系统中形成镜像或副本，同时进行补充信息的录入和管理的系统。

谈到主数据管理系统和从属数据管理系统，就涉及哪些识别信息和属性信息应该在主数据管理系统中被定义和维护，哪些可以在从属数据管理系统中进行定义和维护，哪些信息应该强制要求从属数据管理系统和主数据系统保持一致性，哪些信息允许存在差异性。

这种基于数据分类定义、数据标准约束、数据分布策略的三个策略保证了数据在原始产生过程中的唯一性和一致性。提升了企业整体的数据质量水平。同时也理清了数据引用的逻辑关系，便于程序开发人员的理解和系统开发的实现。

6.数据产生环节数据处理效率的考虑

上述解决了数据在产生环节应该有什么、应该是什么样子以及应该如何合理分布的问题。那么，在数据产生环节还应该关注的就是数据产生、访问、变更的效率问题。

数据处理的效率既和模型设计相关，也和采用的技术平台相关。在讨论数据架构的时候，只从数据架构可以影响的角度来谈。从数据的角度谈数据处理的效率，更多应该从数据的分类处理需求特征来看对架构和技术的要求。

从数据产生环节，按照不同的数据分类，以及不同分类数据的数据处理逻辑进行详细的需求分解，形成了数据在产生环节的数据操作类型，以及这些操作类型具体的技术处理要求：

1）主数据的创建：通常都是逐条记录的insert操作。采用有业务规则的主数据编码是必需的，也可以采用系统自动增加的顺序编码作为一些系统处理的辅助手段。要求响应效率高，而且必须有事务完整性保证。随着多渠道业务的开展，支持来自于多渠道的主数据创建的通用服务调用是必备功能。

2）主数据的修改：对于主数据属性的修改，同样需要保证效率、事务完整性、多渠道调用。同时更应该考虑属性的业务分类，属性的更新频率等采用分表设计的理念。这样提高服务封装能力和系统设计的通用性。

3）主数据的删除：在大部分主数据系统中，不建议对主数据采用物理删除的策略。这样无论是对于前台操作系统还是后台统计分析都会产生不可估量的影响。建议采用逻辑删除或者禁用的方式进行处理。另外对于逻辑删除的主数据编码，不能进行编码的复用，否则会引发数据不一致性。

4）主数据访问：依赖主索引，按照B树方式的检索，以及采用适度的内存驻留和页面交换技术，仍然是保证主数据访问效率的基本机制。这种内存驻留和页面交换技术本身也是主流OLTP型关系型数据库提升效率研究的重点课题。

5）参考数据访问：因为参考数据量比较小，不妨采用适度冗余存储的策略，保证参考数据访问的效率。而且之前也提到了，基于参考数据和主数据相同的特性，建议不要采用物理删除的方式，即使逻辑删除也要保证不要出现主键复用的情况。保证编码和具体业务含义对应的唯一性。

6）事件数据创建：对于不可变更的事件类信息，采用按照流水序号自增存储的策略。事件信息因为不存在删除和更新的问题，可以采用列存储的技术。

7）关系数据增加和修改：关系型数据的增加和主数据的操作方法类似，关系型数据被修改和删除的频率都比较低。其操作方法可以等同于主数据的操作方法类型。

8）生产系统的批量处理：生产系统日终的批量处理，涉及整表的批量扫描、更新作业处理。可以是仿照OLAP型的大规模数据关联操作，也可以是依托于外部程序的逐步逻辑处理。对内存技术的使用，可以加速批量处理的时间，减少日终作业导致业务中断的操作时间。

9）生产型统计分析：类OLAP的，在生产类系统中的全表扫描和多表关联操作。但是处理的数据量比纯粹的OLAP系统小。不建议在生产系统中附加太多统计分析类的功能。定位是满足单一系统当日的基本统计报表为主的应用。而且这种统计报表以支持运营管理为主。而企业其他的决策报表应该纳入管理分析领域的统一报表平台来支撑。

10）实时决策与运营支撑：在此作业处理过程中，如果采用SOA架构的内存规则引擎策略，则主要是基于消息总线的内存处理技术，和数据架构关系不大。如果是采用准实时小批量抽取和动态数据仓库的统计分析技术相结合的策略，则对于生产系统来说，更多考察的小批量数据实时性导出的能力。

11）支持后台数据获取的批量数据导出：将生产系统数据以批量的方式导出，支持后台管理分析系统的数据整合和数据统计分析应用。所以大批量的数据导出能力，以及可以识别增量的数据导出能力是此作业类型的关键。

从当前技术趋势看，具备OLTP优势的关系型数据库模式仍然是主流技术。随着我们在这些作业中越来越多地看到混合OLAP型的作业处理特征。因此，需要看当前OLTP型技术如何逐步借鉴和融合原来适合OLAP型的技术特征。包括OLTP技术对分布式计算的采用、对内存计算、列式存储、流式计算得采纳都是重要发展趋势。

在大型商业银行的数据架构中，随着业务系统的发展，原来由一个大核心系统承担的功能逐步都剥离到不同的系统中。因此，在数据产生环节的数据架构设计，也在被这种逐步的剥离所影响。其中最重要的两个特征如下：

1）流程处理系统和核心帐务处理的剥离：比如说大多数银行都在构建全流程的信贷管理系统，针对信贷管理构建独立的流程管理系统，但是把后续的放款、收款、利息计算等账务处理的能力仍然停留在核心中。这种剥离一方面是发生原因和结果从数据记录上的剥离，另外一方面也是一个完整的交易事务被切断式的剥离。这种剥离能够缓解核心系统的压力，同时他又增加了系统之间的耦合性，以及系统之间处理的一致性保障的需求。

2）业务系统的分析性批量处理逐步剥离到管理分析性系统：以前由业务系统自身的一些统计分析，都逐步由专业的管理分析型系统支撑。这种剥离需要界定在业务系统的批量处理中，应该承担哪些作业，哪些作业不应该承担，简单原则如下：

①满足本系统业务流程完整性的批量处理，应该由该生产型系统承担。

②支持其他耦合业务系统流程完整性的操作处理，应该由该生产型系统承担。

③满足单一业务日终统计的简单报表作业，可以由生产系统承担。

④满足历史趋势分析和跨系统整合性分析的需求，不应该由生产系统的批量作业承担。

依托于这种剥离，生产系统应该尽量保证的是增量数据可识别，可以批量导出数据的效率。以便于保证管理分析系统的数据处理时效性。

在数据架构中，经过以上四个步骤的考虑，数据就有序而且合理的产生了。数据产生之后就进入了数据的流转环节。