俗话说，海纳百川，有容乃大。这个道理应用到信息技术的典型就是互联网技术，互联网由于根本的技术原因而支持广泛的自由，可以容纳所有的信息，因此在短短的几十年的时间内其容纳的信息量越来越接近于全人类掌握的信息总量。
对于特定的软件，尤其是通用软件，也是符合这种原理，例如Office软件，其最初就是字处理器，用来处理简单的文字文档。但现在是越来越复杂和强大，已经不再限于处理文字文档了，而已经成为一种开发平台了。
通用报表软件也是如此的，原先的报表工具，它的数据源是基于单条的简单的SQL语句查询的，报表样式也是比较简单的列表清单模式，随着其不断发展，后来开始能使用多条SQL语句查询数据，能够跨数据库进行查询了，但从本质上还是基于SQL查询的，数据只能来源于比较底层的数据库。其他的数据来源，比如XML文件，EXCEL文档，甚至程序运行时产生的内部对象等等，这些数据都是可以应用到报表中，但是由于传统的报表数据源模型而被忽略掉了。
最近有些报表工具也尝试利用这些数据，搞数据桥，使用报表工具插件等等，但需要不少编程量，而且总体上还没突破传统的基于SQL查询的报表数据源模型。
在此我提出最广泛报表数据源模型。这个名称有点吓人，但个人觉得，提出新技术新观点，无论是好是坏，都是值得报以希望的，都是能搅动逐渐僵化的思想，若不提出新观点新技术，则必然老化僵硬。因此我不怕提出新的荒谬的不合常理的观点，对于反对声，我心中就说：走着瞧。
最广泛报表数据源模型的宗旨就是一切皆是报表数据。此处的一切只所有的数据，关系型数据库里面的，XML里面的，Excel里面的，文件系统中的，甚至程序运行时产生的一些对象等等。
最广泛报表数据源模型若局限到关系型数据库则和传统的基于SQL查询的报表数据源模型无区别，但随着时代的发展，传统的基于SQL查询的报表数据源模型暴露了一些问题，首先是安全问题。
现在的信息系统都讲究多层结构，代码一般分为3层结构，数据库处理层，业务逻辑层，数据显示层（用户界面层）。这种多层结构虽然复杂点，但程序比较灵活，而且容易控制数据的安全。于是大家都则日火朝天的构造三层或多层结构的系统，但到了报表这块傻眼了，根据传统的报表模型，此时程序结构只有一层，报表工具直接连接数据库访问数据，将查询所得的数据直接注入到报表模板中后输出报表。于是在多层结构的程序中嵌入一个单层的报表模块。这很显然的带来了维护和安全方面的问题。
一些报表工具能从DataSet里面获得数据，其实在我看来，DataSet就是一个底层数据库，只是它是原始数据库在应用程序内部的一个映射，对于它也是有管理和安全的要求，也算作系统底层。如果恶意代码不去直接连接数据库，而是访问和修改了DataSet，最后程序底层很可能无条件的自动保存DataSet到数据库中，这和直接访问和修改数据库没有什么本质区别，只是时间上有些延迟了而已，此时恶意代码绕过了一些安全措施而访问的数据库。因此个人认为DataSet也可能成为系统的安全漏洞，因此程序员们不但要看好Connection，还要看好DataSet。
而且报表工具直接访问数据库造成了报表生成问题。大家可以发现，输出的报表和系统用户界面的输出是有些类似的，但数据库里保存的数据却和显示的样式相差很大，系统用户界面需要的数据是源自数据库中的原始数据，经过数据库处理层和业务逻辑层进行了大量的处理而生成的。处理过程有时可能是简单的拷贝，有时则是很复杂的逻辑运算。而报表工具的数据直接来自数据库，这种结构造成完全依赖报表工具模拟数据库处理层和业务逻辑层的处理过程。报表工具是一个公司生产的，但数据库处理层和业务逻辑层却是千千万万的公司生产的，势单力薄的报表厂商是根本无法满足千千万万的其他公司产生的那怕是十分之一的功能要求，所谓的零编程的报表工具是不可能存在的。所有的这些造成报表模板编制复杂麻烦，有时需要编写扩展程序。因此个人认为报表应当属于三层结构的数据显示层，在纯粹的三层结构中，报表不应当直接连接数据库或DataSet，而是应当从业务逻辑层获得数据。
业务逻辑层如何向数据显示层的报表模块提供数据呢？首先那自然是所谓的用编程来实现动态报表，但动态报表开发麻烦，代码量多，而且需要频繁的调试报表样式，没有利用报表工具所特有的专业的报表组织输出功能，报表工具最重要的报表模板的功能没有利用而成为摆设。
于是我们很自然的想到了XML技术，XML技术的宗旨就是方便的交换数据，因此若报表工具能直接从XML文档获得数据然自然是非常好的消息。业务逻辑层使用基于XML的序列化将一个个业务逻辑对象输出为XML文档，或者自定义的输出特定格式的XML文档，报表工具接受这些XML文档，套上预先定义的XML处理规范从这些XML文档中获得报表数据，然后填充到报表模板中生成报表输出。这种操作虽然有点麻烦，但确实符合的三层结构的思想，不访问底层数据，报表数据依赖于业务逻辑层，这就维持了三层结构的严谨性和灵活性，而且报表引擎不用再不自量力的模拟业务逻辑层的处理过程了。
如果报表工具和应用系统使用了相同的框架，例如都是.NET程序或都是JAVA程序，则通过XML文档的方式有些低效和难用，此时可以业务逻辑层中的包含数据的对象就直接发送到报表工具，而报表工具接受这些对象提取数据，然后填充到报表模板中生成报表输出了。可以设想，应用系统有一种对象类型，它的公开字段或属性可用于报表，将若干个这种类型的对象放在一个List中发往报表工具，这时报表工具能将简单的遍历对象列表来获得报表数据,这种情况比较简单。但有时应用系统的对象组成对象树，比如一个公司包含若干个部门对象，部门对象包含若干个员工对象，而员工对象就包含的报表数据。对于这种对象树则不能简单的线性遍历，而得采用递归遍历了。
但是可以断言，这个世界上简单系统数量是占大多数的。很多系统不是三层或多层结构，因此报表工具也就要直接连接数据库来获得报表数据。
综合上述，获得报表数据至少有3种方式，直接连接数据库进行SQL查询获得报表数据，接受XML文档获得报表数据，接受应用系统生成的对象来获得报表数据。这三种方式相互间是截然不同的，SQL查询是获得一个二维表格，而XML则是层数不定的树状结构，而对象则可能组成对象树。而传统的报表数据源模型是基于SQL查询的，只能是二维表格，而树状结构是不可能压入到二维表格的。因此在传统的报表数据源模型下是这三者不可能统一的。
在此，我提出最广泛的报表数据源模型，在这个模型理想目标是融入所有类型的数据源，包括基于SQL查询的二维表格结构和基于XML和对象的树状结构，网状结构或其他类型的结构的数据源。
大家知道XML和HTML都源自SGML，SGML是个试图包容所有数据的标记语言，HTML是简单显示数据标记语言，而XML则是介于两者之间，XML用20％的内容实现了SGML的80％的功能。
类似的，由于本人思维能力有限，在此只考虑最广泛报表数据源模型的一个简化版本，也就是仅仅包括二维表格和树状结构，其他的结构暂不考虑。一个包含二维表格和树状结的报表数据源模型是能处理至少80％的需求。因此我们的目标就是找个数据结构，它既包容二维表格又包容树状结构。
大家考察一下二维表格结构，它也可表述为树状结构，只是这个树状结构只有两层。第一层节点就是表或查询，第二层节点就是字段，其实现在一些报表工具显示报表数据源时就是采用两层的树状结构视图来显示的。
由此我们就很想当然的用树状结构包容二维表格和树状结构了。如此也是很自然的出现了笔者推出的树状报表数据源结构了。树状报表数据源结构既能处理SQL查询的二维表格，也能处理XML的树状结构，两层的树状报表数据源就等价于传统的基于SQL查询的报表数据源结构了。
树状报表数据源结构带来的一个挑战就是如何切换不同的数据来源，比如数据开始来自SQL查询，但马上要切换到XML文档和对象树，这时报表引擎内部必须进行平稳的过渡，使得报表数据源能同时接受不同结构的数据。
笔者曾经写过一篇《XML-报表数据的新大陆》中曾经设想，报表工具能在应用系统提供的若干个XML文档中跳跃着获得报表数据，这种跳跃能力就是平滑的处理不同结构数据的能力。就像一个池塘中飘着一些荷叶，一些荷叶写着关系型数据库，一些荷叶写着XML，我们的报表工具就像青蛙一样在这些荷叶中来回跳跃。
随着一些软件巨头的数据库直接支持XML文档，此时SQL查询和XML文档就融和在一起，此时就更需要这种跳跃能力了。
上面提到当报表工具和应用系统使用相同的平台，则应用系统可以发送对象到报表工具让其提取数据。我们目前用的是关系型数据库，但现在可以想象，我们未来可能会使用面向对象的数据库，这种面向对象的数据的查询结果可能就直接是一个个对象了。其实有一种名叫Cach'e的面向对象的数据库系统已经投入应用，它的制造商是InterSystems( http://www.intersystems.com )，想必知道的人不多吧。对于面向对象的数据库，我们的报表工具就必须具备从对象获得报表数据的能力了。
此外还其他格式的数据源了，比如CSV，Excel文件，它们和SQL查询是兼容。HTML文档，它兼容于XML文档。总之所有以二维表格或树状结构表现的数据都可以包容到树状报表数据源模型中。
笔者正在开发和完善XReport报表工具，其中就实现了树状报表数据源模型。首先是实现树状报表数据源的抽象模型，然后在这个抽象模型上挂靠针对不同格式的数据来源的适配器，目前笔者已经实现了针对SQL查询，CSV文件和XML的三种数据适配器，所有支持的外部数据经过对应的适配器后进入到报表数据源内部，而报表数据源内部可以任意在这些数据间来回切换。由于目前只实现了三中数据适配器，因此只能在 SQL查询，CSV和XML三者之间来回跳跃。
在未来，笔者将会完善发展树状报表数据源，并增加对象数据适配器的种类，预计可以从对象树中获得报表数据。
最广泛报表数据源模型是笔者刚刚提出来的，可能有错误的观点，有些想法可能不切实际，希望认真阅读过本文的人给予指正。
XDesigner软件工作室 袁永福( http://www.xdesigner.cn ) 2006-9-27