最廣泛報表資料來源模型

    俗話說，海納百川，有容乃大。這個道理應用到資訊技術的典型就是互連網技術，互連網由於根本的技術原因而支援廣泛的自由，可以容納所有的資訊，因此在短短的幾十年的時間內其容納的資訊量越來越接近於全人類掌握的資訊總量。

    對於特定的軟體，尤其是通用軟體，也是符合這種原理，例如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