学习札记：DSB抽数解析-由T24的XML型数据到DSB的SDM关系模型

学习笔记：DSB抽数解析-由T24的XML型数据到DSB的SDM关系模型

一：前序：

DSB直接抽数、解析T24核心系统后台数据，形成SDM层核心基础数据，再提供以各下游系统数据接口及DSB自身诸多报表需求。T24后台以XML保存数据的特色决定上述ETL过程在第一阶段就不同于寻常的关系型数据抽取，并且在形成SDM的解析过程也具有一定的典型性：这是一种典型的非关系型数据模型到关系型数据模型的转换。本笔记即是在对这种典型处理的兴趣驱使下，与大家共同探索以下几部分内容

1：以T24为代表的XML数据存储形式

2：基于T24的XML源数据的数据抽取策略

3：基于T24的XML源数据的数据解析策略

4：基于T24的XML源数据的SDM层数据模型

反复考虑了下，从哪里入手。XML原理？T24 jBASE平台？NO！这个笔记不是用来讨论什么XML的灵活性如何提高系统弹性以支持业务扩展的（虽然这个是个好的话题），也不是用来介绍T24的数据库产品（这个根本不熟也讨论不下去）,更不想去做什么核心系统的介绍与比较，有兴趣的自己去百度，

比如这篇：http://www.itpub.net/thread-499272-1-1.html

再比如这篇：http://www.itpub.net/thread-1460783-2-1.html

这个笔记只是纯粹的，纯粹的借T24与DSB了解下一种XML格式到关系型数据模型的转化的ETL过程。所以我们得先从了解一下我们的数据源：T24的后端数据存储及其XML实质结构，再讨论DSB如何对此数据进行抽取、解析，最终形成什么样的SDM关系型数据模型。

==================================================================

二：以T24为代表的XML数据存储形式

2.1：初识T24的数据：保存在关系型数据库里的XML文件

如果仅是看T24的后端数据库，可能会误以为T24和一般系统一样是关系类数据结构。T24有自己的源端数据库，也支持采用其他类数据库，如我们采用的就是oracle。但T24的前端应用并不直接与后台数据库直接打交道，这中间还隔着一层jbase平台的。比如下边查数据时也会用到jbase的一些命令，讨论jbase的话就又离题了，了解不多，不多做讨论，我们还是继续看数据。

既然后端采用了oracle存储数据，T24的数据表现首先也是一种基于关系表的关系结构。只是这种关系结构较为简单：每张表只有两个字段：

第一个字段是Char类型字段，用以保存主键，

第二个字段是Clob类型字段，用以保存XML数据

T24便是以这样的形式，将XML结构数据保存在关系型数据库里。

以T24的一张表ECB余额表为出发点，从前台看下数据：

我们以三个层次去解析这个界面上的数据

层次一，表级：

说明：这是一张T24的关键表，业务上也称为余额表。

表名即EB.CONTRACT.BALANCES

后边我们会了解到，这其实是一种逻辑表名

（可以理解成外模式，或简单的说，是视图）

层次二，记录级：

业务上的理解，一笔交易，或一个流水为一个记录，如上余额表里，一个有效的合约(contract)会保存一个记录

数据上的理解，在关系型数据库里，一个表一行值为一条记录，由主键字段和其他相关字段组成

所以上图中，“LD1400200002”即确定了业务的合约号，也是数据上的主键值，唯一确定了一条记录。

层次三：字段级：

业务上，各种字段定义了该交易/合约的各种属性。

数据上，字段是组成记录的各元素，字段具有字段类型、格式定义等。。

如上图，左边为字段名（视图显示）、右边为字段实际值

我们对照T24的后端数据库，看看数据是如何存储的：

上文在层次一有提到，界面上的展现的表名，可以理解成是一个“逻辑表名”，后端数据库是实际的“物理表”，这里需要有一个从逻辑表名到物理表名的转换，T24的这种转换，便是基于jbase平台实现的：

jstat是一个jbase的平台工具，可以用来查询逻辑表名对应的物理表名，如上图，逻辑表名是“ FBNK.EB.CONTRACT.BALANCES”，这里的前缀fbnk，是T24的一种机制，解释略过，查出的物理表名为：FBNK_EB_C008

获取到了物理表名我们便可以后端数据库里查询表结构和实际数据了：

从表结构和实际数据里可以看到，表里每条记录只有二个字段，

字段一是记录主键，

字段二是类似CLOB的一种集成。

上方界面上看到的字段级的信息，直接以XML的格式，存储在后端对应表的第二个字段里。表现如下：

进一步的，这里要以看出来，这里是以一种XML形式保存的数据，一条记录就是一个“ROW”，这里看不到具体的字段名，记录里的每个字段值，统一的“C+数字”形式做标识。一个字段可以出现多次，也可以不出现。

出现多次，这便是T24的多值子值(multivalue/subvalue)的情况

多值允许一个记录（一个主键里）里有某个字段或某几个字段的组合出现多次。

子值允许一个多值字段或多值组合里，出现第二层的多值，相当于一种多值嵌套。

虽然XML具有灵活的扩展性，幸好，T24不允许出现超过二层的嵌套。即只会出现

1：单字段多值-子值

2：组合字段多值-子值

不会出现如

3:多值-子值-子值

的情况。

2.2：基于T24的XML源数据的数据抽取策略

抽取策略，或称为采集方案，考虑的包括采集时点、采集模式、采集对象等

采集时点，目前出于以下几点考虑（可能需要补充）：

1：保证数据稳定性

2：不影响核心跑批性能

3：满足业务对基础信息的要求

采用镜象的方式进行采集。在核心跑批前和跑批后二个时点生成数据库镜象，供DSB抽取

采集模型，根据抽取与解析的前后关系可以有三种模型

1：抽数前解析

2：边抽数边解析

3：抽数后解析

从系统间偶合性、ETl并行等方面考虑，目前基本上采用模式三

采集对象仍然从表-记录-字段三级考虑

1：抽哪些表，根据业务需求判断，不讨论

3：抽哪些记录，即全量抽取还是增量抽取

2：抽哪些字段，由于T24是二个字段的，所以不挑字段，基本是二个字段都抽出来

因此采集对象主要还是考虑全量与拉量的抽取策略。除了极个别的主键ID上的几个字符可以判断增量（不一定准确）外，在进一步解析第二个字段前无法从字段去区分记录的时间属性。只能根据表自身的增全量属性及表间关联关系来决定是采用增量抽取还是全量抽取。比如T24的三张entry分录表，表本身是个大全量，但T24同时提供了一个增量表，如STMT.ENTRY的当天增量便保存在ACCT.ENT.TODAY表。

因此，DSB在全量抽取了ACC.ENT.TODAY这张表后，借由这张表解析，提取STMT.ENTRY的增量主键列表，进而采用增量的方式去抽取STMT.ENTRY表。

因而：目前DSB的抽数策略大致如下：

1：对于小表，直接采用全量抽取的方式。

2：对于大表，优先考虑采用增量的方式抽取。例如是三张ENTRY表，这种方式依赖于其他关联表的抽取与解析。

3：大表又没有增量表的，目前前是采用全量方式。

3：基于T24的XML源数据的数据解析策略

解析面临的最大问题，是如何把T24的结构化数据转化成关系模型，这就需要充分了解T24的XMl数据结构。

T24的结构化数据主要有二类：XMLTYPE和BLOG，前者是完整的XML格式存储字段信息，后者是字节码，各字段按分隔符存放，有点类似关系型数据的字段按分隔符拼接在一起。所以下边考虑的，还是主要是XML格式的解析。

上文提到T24的后端第二字段保存的是“压缩”后的XML形式数据，这种数据的灵活性表现如下

1：可跳跃性

跳跃性是指，T24的记录中的值，可以只保存有数值的字段，没数值的字段甚至不需要保存空值。在列表里直接勿视掉。

2：单字段多值

一个字段重复出现多次，每次的值可以一样也可以不一样

3：组合多值

多字段形成多值组合。

4：多值与子值

多值组合里又可以有某个子段有第二层次的多值。

这些都是T24利用XML灵活性支持的特性，却不是关系型数据库的特性，关系型数据库要求同表的所有记录的字段一致性，并且关系数据库范式一就明确不支持字段多值。

因此解析第一步：DSB首先要去T24的“元数据”表里获取T24每张表的完整字段列表。数据库里总有些“元数据”性质的表，存放着关于数据的数据。T24系统标准表的表结构存放在名为“f_standard_selection”的表中。该表第一个字段为表名，第二个字段是XML字段存放着表的完整列属性

通地解析ss表(具体解析方法略过)，可以获取到表字段的：字段名、字段顺序、单值多值、组合范围、是否子值等属性。转化成如下SCHEMA信息。

在确定了表字段较完整信息后，就可以进行数据解析了，基于XML的格式性质，基本的思想是采用二个步骤进行解析：

1：“正则”表达式去解析各字段

2：根据字段的单值与多值及是否分组，结合SDM模型进行存放。。

4：基于T24的XML源数据的SDM层数据模型

SDM的数据模型主要考虑二点：模型设计与数据存储策略

模型设计：

上节提到，在正则解析完各字段后，要根据字段的单值与多值情况进行存放。SDM是帖近源系统数据的操作型数据模型。表设计基本上大致按照T24来源的表结构去定义表名、字段名等。对于多值，一般的考虑便是做成子表去存放。因此，SDM模型一般包括以下几个表：

4.1：主表

表名：与T24的物理表名一一对应，可补充后缀“_S”以强调

用途：存放的是非多值的单值字段。

主键：以源表的的ID为主键，统一主健字段名叫：“ROW_ID”

其他字段：与T24源字段一致即可。

特点：记录数与T24记录数基本一致。

如下：

4.22：非组合多值子表

表名：T24物理表名+“_M”，

用途：存放用于存放所有 非组合的多值字段

主键：以源表的的ID为主键，统一主健字段名叫：“ROW_ID”

其他字段：由于非组合多值

COL_NUM:保存字段序号

MUL_NUM:保存存多值（第一层多值）的顺序号。

SUB_NUM:保存子值(第二层多值）的顺序号

T_VALUE:保存值

特点：形式相当于做了列转行处理，一个列的多值转换成了多行记录。

如下示例

4.3：组合字段多值子表

表名：T24物理表名+“_首字段字段名”，

用途：存放用于存放所有 非组合的多值字段

主键：以源表的的ID为主键，统一主健字段名叫：“ROW_ID”

其他字段：由于非组合多值

MUL_NUM:保存存多值（第一层多值）的顺序号。

SUB_NUM:保存子值(第二层多值）的顺序号

其他字段:组合多值的各个字段依次组成该表的其他字段

特点：形式相当于做了列转行处理，区别于单字段多值是，每个条记录的有各字段都有具体值。

数据存储策略，考虑并实现以下几种情况。

总结：

以上，了解了T24如何把XML数据保存在后端关系型数据库里，DSB以何种策略去抽数，关注多值字段如何解析，最终形成DSB基础数据模型。了解基础数据模型，不仅进行DSB接口作业开发的基础，而通过了解基础数据模型的形成过程，更有助于在进行接口需求分析时，将业务需求较完整正确的转化为数据加工逻辑。