现在的信息系统越来越复杂，它们的数据库中的数据结构也越来越复杂，表和字段变多了，表间关系也越来越多。面对如此复杂的数据结构，各大报表工具各显神通，想尽一切办 法誓要从中获得数据。

首先考察数据结构的复杂性的特点。在这里以微软的演示数据库 nwind.mdb为例子进行分析，现在要出订单明细报表，则涉及到的数据结构如图所示
可以发现这5张表的数据组成了一个3层的树状结构。第一层是Customers的数据，第二层是Orders,Employees组成的数据，第三层是OrderDetails,Products组成的。其意思就是说 数据库中存在好几个客户，一个客户有多个订单，一个订单有多个货物。

面对这种比较复杂的数据，传统的报表工具由于采用两层的数据源模型，因此需要一次性获取数据，采用眉毛胡子一起抓的思想，这就导致可能需要编写复杂的SQL语句，例如对于 订单明细报表，SQL语句可以为"SELECT Customers.CompanyName, Customers.ContactName, Customers.Phone,
OrderDetails.*, Orders.OrderDate,
Products.ProductName, Employees.FirstName, Employees.LastName
FROM ((Orders 
INNER JOIN (OrderDetails 
INNER JOIN Products ON OrderDetails.ProductID = Products.ProductID) 
ON Orders.OrderID = OrderDetails.OrderID) 
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID) 
INNER JOIN Employees ON Orders.EmployeeID = Employees.EmployeeID"，如此复杂的SQL语句我是写不出，也不想写，个人认为复杂SQL语句坏处多多，尤其是JOIN 子语句，应尽量避免。SQL语句写出来后，在报表模板中还需要进行多次分组才能组织出报表样式。

若采用多层报表数据源模型，则采用了眉毛胡子分别抓的指导思想，处理起来从容不迫，此时获取数据的原理如图所示

其详细步骤为

1. 对于Customers节点，执行SQL语句"Select CompanyName , ContactName , CustomerID , Phone From Customers"获得客户列表 ，将查询所得的栏目分别分配到CompanyName,ContactName , 订单列表 , Phone 数据源子节点。
2. Customers节点遍历所有的查询所得的记录行时，每处理一行，都递归调用子节点处理数据的过程。对于订单列表 节点，它有子节点，因此其处理数据的过程是，首先执行SQL语句"Select Orders.OrderID , Orders.OrderDate , Orders.EmployeeID , Employees.EmployeeID , Employees.FirstName , Employees.LastName From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID= 当前处理的CustomerID栏目的值"，例如Customers节点处理CustomerID为“1234”的记录时，订单列 表执行的SQL语句为"Select ... From From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID=1234" , 也就时说订单列表节点出执行的SQL语句是根据当前节点的值而改变的。订单列表节点查询成功后，然后将查询所得的栏目分配到 OrderID , OrderData 等子节点，其中 栏目 Orders.OrderID分配给了 订单详细内容 子节点 。
3. 类似的，对于订单详细内容，执行的SQL语句为"Select OrderDetails.ProductID , OrderDetails.UnitPrice , OrderDetails.Discount , Products.ProductName , OrderDetails.Quantity ,( OrderDetails.UnitPrice * OrderDetails.Quantity * ( 1 - OrderDetails.Discount )) as TotalCount From  OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID = 当前处理的订单号"，查询所得的栏目分别分配到了它的子节点，其中 TotalCount 栏目分配到了总金额子节点。

执行的SQL语句依次可能为,此处字段列表用 ...表示

1. Select ... From Customers
2. Select ... From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID='1234'
3. Select ... From  OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID = 100
4. Select ... From  OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID = 101
5. Select ... From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID='5678'
6. Select ... From  OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID = 201
7. Select ... From  OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID = 202

如此看出，这种多层数据源的使用有利有弊。好处有

1. 处理过程符合一般的编程逻辑，便于对数据源结构的理解和设计。
2. 提供了充分的自由度，可以不依赖外部编程来处理大部分复杂的数据库结构。
3. 此过程中使用的SQL语句简单可靠，很容易理解，而且执行效率高。
4. 这种多层的数据源结构很大程度上就反映了数据库中的数据结构。数据源树状结构直接映射了数据库中各条记录组成的树状结构，只要了解数据结构就可以很自然的套这这 种结构来编制报表数据源。某种程度上可以进行数据源结构和数据结构的相互检查。

当然弊端还是有的，最大的就是大大增加了执行SQL语句的次数，影响报表执行效率。当数据源结构层数越多，执行的SQL语句个数将以指数方式增长，因此实际应用中数据源层数 必须有所限制，而且设计良好的数据库数据结构有助于控制数据源层数。

面对多层数据源的好处和弊端，这需要权衡，个人认为大部分情况下利大于弊，主要原因有

1. 随着计算机硬件和基础软件的发展，数据库查询速度越来越快，这可以一定程度上弥补SQL语句数量增加的影响。
2. 随着信息系统规模不断膨胀，复杂的数据结构也是越来越多，若采用传统模式获得报表数据，则程序中分布了很多复杂难懂的SQL语句，这非常不利于系统的开发和维护。相 对于一般的程序代码，SQL语句没有源代码控制，没有编写规范，注释和文档也很少，其含义也更抽象难懂，而且少数的数据库高手才能编写和维护复杂的SQL语句，因此使用大量 复杂SQL语句是不明智的。
3. 多层数据源结构符合一般的编程逻辑，也反映了数据库的数据结构，因此比较容易编制和理解，知道了解数据库结构就会理解多层数据源结构，可以让很多有基础的经过培 训的人来编制和维护数据源结构，因此可以让普通群众编制大部分报表数据源而不必惊动高手，降低报表编制成本。
4. 多层数据源结构提供了充分的自由度，可以处理大部分数据结构而无需编程，这就为开发报表模块而无需编程打下了坚实的基础。

多层数据源模型是本人刚刚提出来的，其思想还不成熟不完善，希望大家多多指点。

XDesigner 软件工作室 2006-8-31