法誓要从中获得数据。
首先考察数据结构的复杂性的特点。在这里以微软的演示数据库
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语句写出来后，在报表模板中还需要进行多次分组才能组织出报表样式。
若采用多层报表数据源模型，则采用了眉毛胡子分别抓的指导思想，处理起来从容不迫，此时获取数据的原理如图所示
其详细步骤为
- 对于Customers节点，执行SQL语句"Select CompanyName , ContactName , CustomerID , Phone From Customers"获得客户列表
，将查询所得的栏目分别分配到CompanyName,ContactName
, 订单列表 , Phone
数据源子节点。 - 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分配给了 订单详细内容
子节点 。 - 类似的，对于订单详细内容，执行的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语句依次可能为,此处字段列表用 ...表示
- Select ... From Customers
- Select ... From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID='1234'
- Select ... From OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID =
100 - Select ... From OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID =
101 - Select ... From Orders , Employees where orders.employeeid = Employees.EmployeeID and orders.CustomerID='5678'
- Select ... From OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID =
201 - Select ... From OrderDetails , Products where OrderDetails.ProductID = Products.ProductID And OrderDetails.OrderID =
202
如此看出，这种多层数据源的使用有利有弊。好处有
- 处理过程符合一般的编程逻辑，便于对数据源结构的理解和设计。
- 提供了充分的自由度，可以不依赖外部编程来处理大部分复杂的数据库结构。
- 此过程中使用的SQL语句简单可靠，很容易理解，而且执行效率高。
- 这种多层的数据源结构很大程度上就反映了数据库中的数据结构。数据源树状结构直接映射了数据库中各条记录组成的树状结构，只要了解数据结构就可以很自然的套这这
种结构来编制报表数据源。某种程度上可以进行数据源结构和数据结构的相互检查。
当然弊端还是有的，最大的就是大大增加了执行SQL语句的次数，影响报表执行效率。当数据源结构层数越多，执行的SQL语句个数将以指数方式增长，因此实际应用中数据源层数
必须有所限制，而且设计良好的数据库数据结构有助于控制数据源层数。
面对多层数据源的好处和弊端，这需要权衡，个人认为大部分情况下利大于弊，主要原因有
- 随着计算机硬件和基础软件的发展，数据库查询速度越来越快，这可以一定程度上弥补SQL语句数量增加的影响。
- 随着信息系统规模不断膨胀，复杂的数据结构也是越来越多，若采用传统模式获得报表数据，则程序中分布了很多复杂难懂的SQL语句，这非常不利于系统的开发和维护。相
对于一般的程序代码，SQL语句没有源代码控制，没有编写规范，注释和文档也很少，其含义也更抽象难懂，而且少数的数据库高手才能编写和维护复杂的SQL语句，因此使用大量
复杂SQL语句是不明智的。 - 多层数据源结构符合一般的编程逻辑，也反映了数据库的数据结构，因此比较容易编制和理解，知道了解数据库结构就会理解多层数据源结构，可以让很多有基础的经过培
训的人来编制和维护数据源结构，因此可以让普通群众编制大部分报表数据源而不必惊动高手，降低报表编制成本。 - 多层数据源结构提供了充分的自由度，可以处理大部分数据结构而无需编程，这就为开发报表模块而无需编程打下了坚实的基础。
多层数据源模型是本人刚刚提出来的，其思想还不成熟不完善，希望大家多多指点。
XDesigner 软件工作室 2006-8-31