PUREXML助力税务应用 

    每次新技术的出现都会推动行业应用发生大的发展，PUREXML技术的成熟将在很多行业应用领域实现根本性的改变，对软件系统的随需应变及业务价值提升方面产生深远影响。税务行业典型场景有前端数据采集及纳税人档案。

表单驱动型数据采集应用 

    行业应用一个重要的功能组成就是根据业务表单采集数据，在税务行业，诸如开业登记、申报等都属于这种类型的应用。如何实现面向业务的灵活性是我们考虑的首要问题，在业务表单发生变化的时候如何做到快速应变，能够以客户为主体实现软件系统的维护呢？这需要有技术的保障来支持这种灵活性。 

    我们通过分析一个场景来说明这个问题。2006年上旬，国税总局对税务登记表进行调整，原税务登记表包括六类登记表，分别适用于内资企业、外商投资企业、企业分支机构、外国企业、个体经营、其他单位，调整后，税务登记表分为三类：单位纳税人，个体工商户、个人独资、个人合伙企业，临时税务登记纳税人。此次调整，新增了临时税务登记表，同时，将原有的适用于内资企业、外商投资企业、企业分支机构、外国企业、其他单位的登记表合成一份登记表，此次换证工作将税务登记表由原来的6种变为3种，税务登记证件由原来的4种变为2种，税务登记表所涉及的新增加项目归并后有52项，减少项目归并后有51项 。这种业务表单的表单的改变通常引发软件系统大规模的修改，另外，一个更为严重的问题，是修改前的信息难于在修改后的系统中进行处理。为什么会出现这种情况呢，让我们深入分析一下现有系统的实现方式，相信会得到一个满意的答案。 




    目前软件系统的实现方式如上图：

 展示层 

    通过对XML的DOM解析进行动态数据的展示。表单变化必然导致展示及解析代码的修改。修改过程通常经过硬编码来实现，这样带来的一个问题是维护周期及成本很高，以技术人员为主，客户难于参与其中，难于做到面向业务的灵活性。另外，修改后的程序难于适应修改前的业务表单数据。

 业务逻辑层 

    该层的针对经过SAX解析形成的JAVA对象进行业务逻辑操作，表单的数据项变化必然导致硬编码的修改，通过补丁的方式更新到生产系统上，涉及一整套的测试发布流程，且对生长系统的是否正常运行产生挑战，需要专业技术人员大力参与。

 数据层 

    数据库设计采用严格的关系表，表单的变化必然导致关系表模型的重构，如果涉及重构的表是核心表，对系统的影响面非常大，系统中所有设计该表的代码都要进行修改，风险是很高的。究其根源，大部分修改都是因为数据模型欠缺灵活性所致，所以，如何具备灵活的数据架构是保证面向业务灵活性的关键点。 

    综上，数据模型灵活性的缺失是导致大部分维护工作量的元凶，技术人员陷入了修改泥潭，业务人员仍然在抱怨应对业务变化太差。一个永远也解不开的恶性循环。我想是到了我们应该仔细考虑一下这种问题该如何解决的时候了，这个问题不能有效解决，何谈业务流程改造等目标呢？ 

    假设我们在数据层进行大胆创新，变换设计思路，将传统设计中纯关系表转换为关系表和XML有机结合，会带来什么效果呢？ 

    首先，我们看一下根源所在：
 关系模型

– 严格的数据及关系定义
– 高性能的索引机制
– 缺乏数据模型上的灵活性
– 适合固定的结构化数据
 XML

– 层次型的结构
– 具备自描述能力，易于理解
– 数据模式的灵活性
– 适合结构化、半结构化和非结构化数据 

    面对数据日益复杂的要求，纯关系数据库受到了灵活性的挑战。在我们明确的关系模型和XML的区别以后，我们认为，我们发现了数据模型灵活性缺失的根源，接下来要考虑如何解决。
 
    关系和XML的有机结合是唯一的选择。设计原则如下：

 封装原则：将变化的数据封装到XML数据包中，通过灵活的匹配SCHEMA和XSLT应对变化的数据。

 抽取原则：将不变的数据，如纳税人识别号、纳税人名称、纳税人所属税务机关、登记日期等，这些数据是纳税人的标识属性、管理属性及时间属性，不管表单将来如何变化，这些属性是必然存在的，我们可以将这些属性作为关系列进行设计。
如果按照这两点进行设计的数据库，将是一个关系型和XML混合的数据模型，XML自身固有的层次结构及灵活扩展能力使的数据模型层具备了一定的灵活性支持。由此带来的价值怎样呢？如下图： 

    数据模型的改进给我们带来了前所未有的灵活性。变化的内容被封装在XML内部，通过SCHEMA和XSLT的灵活映射来面对变化。不变的内容以关系型数据存在，好处如下：

 数据模型简化，以前类似电路板的复杂关系表不见了，代之而来的是清晰的关系和XML的混合模型，管理上也相对简化

 维护的主体不在是技术人员为主，客户重新夺回了控制权

 维护量大大降低，只需要调整SCHEMA及XSLT，硬编码大大降低，能够快速适应业务变化，实现新旧版本的统一对待。

 从泥潭中解脱出来，能够投入到业务流程改进当中，有效提升业务价值 

    有一个问题相信很多人会提出，用了这种体系机构的数据模型在支持查询统计方面是否存在性能问题，毕竟，我们的前端采集系统70％的功能实际上是查询，尤其很多是在交易过程中的查询。我想在这个问题上我们应该注意两点：

 数据是分职责的，前端采集系统的数据模型除了承担采集交易内查询外，不应该承担大量的查询统计，如果数据职责不能有效划分，系统最终还是会负载过载，而跟采用关系和XML混合无关。

 XML技术已经成熟，不在局限在存成大文本的时代了，而是以直接存储成层次结构。另外，PUREXML技术中通过基于XML节点的索引技术将查询性能提升了几个数据级，只要设计合理性能不在是瓶颈。 


    综上，XML数据模型的采用在承担前端数据采集的系统中提供了很大的灵活性，附之以良好的应用层展示层设计，业务系统将能够提供业务随需应变。

    数据模型从纯关系模型到关系和XML混合的数据模型演化后，客户重新夺回了控制权，成为维护的主体，避免了在业务发生变化时大量修改硬编码的情况。