摘要 I 摘要 隨著互聯網的廣泛應用，信息管理系統的應用也越來越普及。在信息管理系統中使用頻率最高的是報表部分。為了提升信息管理系統中報表需求的 響應速度，同時規范 整合平臺 內部各種業務子系統中的報表功能，就急需一個報表子系統來統一提供報表相應的功能接口。 本文將柔性報表理論和思想應用于基于 報表定制過程中，歸納總結了其中的難點和存在問題， 針對 其中的難點和以往基于 表工具的不足，提出一種新型的報表定制模式和流程，并利用基于 系結構、 術對其進行了實現。 首先，針對目前基于 報表定制的靜態性和對需求變化適應性差的問題，將柔性理論應用于基于 報表定制過程中，使其可以由用戶通過界面交互進行制作 拋棄了以往由開發人員編碼制作的方式，提高了報表系統的靈活性和適應性。 其次，規劃了一種基于 柔性報表制作模式和流程。通過數據源獲取報表核心數據，通過數據整理獲得報表最終的應用數據，通過數據 渲染 對報表的展示樣式進行 規范 。解決 了報表數據定制和樣式定制等關鍵問題，實現了報表 子系統中 各部件的分離和整合。 最后，在 現一整套關于報表各部件的設置界面和展示界面，實現了關于柔性報表的預期設想，完整并統一了目標平臺上業務子系統中的報表功能。 關鍵字 ： 柔性報表子系統，數據源，數據整理，數據渲染 I In is In to of of it a to of a ML of s to in it in s to by by in s it a s by by s by of It in a s in in EB it s on of 錄 錄 第一章 緒論 . 1 第一節 論文工作的背景 . 1 第二節 論文工作的總述 . 4 表子系統的規劃和設計 . 4 表子系統的編碼和測試 . 5 表子系統的運行和擴 展 . 5 表子系統的總結和展望 . 5 第三節 論文工作的主要成果 . 6 第四節 論文組成和各部分內容 . 6 第二章 系統需求分析 . 8 第一節 系統概述 . 8 第二節 系統業務總體描述 . 8 第三節 系統各主要業務和流程描述 . 10 第四節 系統功能要求描述 . 11 統參與者 . 12 統功能需求 . 13 第五節 系統性能要求描述 . 16 表展示的響應速度 . 16 表展示的瀏覽通用性 . 16 表子系統提供的數據精度 . 16 表子系統細部調整的易用性 . 16 表子系統報表需求響應速度 . 17 第三章 系統總體設計 . 18 目錄 一節 系統環境平臺 . 18 網性 . 18 全性 . 18 性能 . 18 第二節 系統開發技術和工具 . 19 作系統 . 20 務器 . 20 發語言 . 20 據庫 . 21 第三節 系統業務功能結構 . 21 表數據源 . 22 表數據渲染 . 24 表數據整理 . 25 第四節 系統主體業務流程 . 26 第四章 系統數據庫設計 . 28 第一節 數據庫整體設計 . 28 第二節 報表基礎信息數據表 . 29 第三節 報表數據源信息數據表 . 30 第四節 報表數據整理信息數據表 . 35 第五節 報表表格展示信息數據表 . 38 第六節 報表設置信息數據表 . 41 第五章 系統詳細設計與實現 . 42 第一節 報表數據源部分 . 42 表數據源的輸出結構 . 42 據源的內部機制函數 . 42 據源的內部 機制 . 43 目錄 V 合數據源的內部機制 . 45 傳數據源的內部機制 . 47 第二節 報表數據整理部分 . 47 表邏輯行的數據整理 . 48 表邏輯列的數據整理 . 49 表的數據引用 . 50 表整體的數據整理 . 51 第三節 報表數據渲染部分 . 52 第四節 報表設置部分 . 52 第五節 系統實現 . 55 表展示頁面 . 55 表設置頁面 . 55 第六章 系統中關鍵問題和技術 . 62 第一節 報表子系統開發流程 . 62 表子系統的整體流程和思路 . 63 戶與報表的 應用模式 . 64 放用戶參與報表設計 . 64 第二節 報表數據源之間數據約束傳遞機制 . 65 第三節 報表 據源中的邏輯長句維護 . 67 第四節 報表數據整理的混合模式 . 69 第五節 報表數據公式整理批量應用 . 70 第六節 報表數據整理過程中的邏輯 約束 . 71 第七節 報表數據組合排序機制 . 72 第八節 報表文件生成器的原理和應用 . 73 第九節 報表數據渲染多樣化 . 75 第七章 總結和展望 . 77 目錄 一節 總結 . 77 第二節 存在問題和解決思路 . 77 第三節 未來發展和進一步措施 . 78 參考文獻 . 79 第一章 緒論 1 第一章 緒論 在互聯網以及各種信息系統被廣泛應用的今天， 軟件即是服務（ as a 線信息系統的服務 提供商、開發者和維護者們（以下均簡稱為“開發者”）面臨著一個嚴峻的挑戰，那就是用戶在應用系統的同時，會根據自身不同的工作特點和流程特色，提出局部乃至全局的定制化需求，即使 經 根據用戶群的行業差異、總體流程差異進行版本區分，也很難避免定制化的需求的產生。 而這對于開發者們來說，某種程度上是具有顛覆性的。這種定制化需求，不僅會破壞即有系統的整體性，使開發者們不得不在有可能的 任意 地方增加分支或邏輯，用以調整程序的流程或算法；更重要的是上述的變更對于系統的穩定性和可維護性沒有任何正面的意義，反而使代碼變 得 復雜 ，結構變得 臃腫，流程和算法的分支趨于混亂乃至整體邏輯 產生 矛盾，被定制部分功能的算法重用性和唯一性也不可避免的喪失殆盡，這些都為系統的最終崩潰提供了不可忽視的內因。 而系統的各種組件中，上述問題在報表部分的體現尤為明顯。因為任何業務部分的定制變化，最終結果需要反映到報表統計結果上， 這種業務變更引發的定制都不可能是常態的、經常性的。 而 且 報表部分自身的定制更是多種多樣 ，報表數據匯總 的 側重 點 、 報表數據渲染 展示 的 重點等 ，這些都 是會根據 統用戶的理念或著眼點的變更而進行定制修改的。 所以， 統的開 發者們，需要一整套強壯的 表程序或子系統（以下簡稱“報表子系統”），用以應對日趨嚴峻的定制需求 ，盡可能的簡化或者避免定制化需求的開發工作 。 第一節 論文工作的背景 報表作為信息系統中不可或缺的組成部分，在上述這些被定制的毒害中是首當其沖的。不僅要滿足業務部分定制功能在報表部分的數據體現，更有甚者，針對報表的數據范圍、數據匯總、顯示樣式、顯示范圍等都可能存在精細化的第一章 緒論 2 定制要求。這就 使得系統中應用可重用的純粹的過程化處理的報表程序不堪重負，開發者更是不堪其擾。 下面是幾個 銷存業務子系統（以下簡稱為“進銷存子系統”）中的現役報表例子，通過定制化的前后對比，就不難看出報表定制工作的瑣碎和繁復了。 例子 1： 進銷存子系統提供了產品庫存情況表，用以展示產品的賬面庫存量以及可用庫存量等庫存信息，其結構如 表 示。 表 產品庫存情況表結構 產品 倉庫 庫存量 可用庫存量 可口可樂 南開庫 1000 850 百事可樂 南開庫 800 750 續例子 1： 由于某用戶的需求，作為“基礎數據”的產品，需增加一個名為“規格”的描述屬性，將產品進行進一步的細分，并且該屬性需要在報表中進行體現，即以產品庫存情況表為例，其結構需要變更為如表 示。 表 產品庫存情況表變更后結構 產品 品 規格 倉庫 庫存量 可用庫存量 1501 可口可樂 1250開庫 550 500 1502 可口可樂 2000開庫 450 350 1601 百事可樂 1250開庫 800 750 續例子 1： 由此而引發的報表修正工作量將是恐怖的，因為新屬性“規格”的出現，顛覆了所有涉及“基礎數據”產品的報表的“列信息”設置和“數據獲取”。又因為新屬性“規格”并非大多數用戶的“基礎數據”產品的必要屬性，所以無法將該屬性增加到公共的報表之中，也就是出現了上面說到的“定制”情況，而且是為該用戶定制幾乎所有涉及“基礎數據”產品的報表。 例子 2： 進銷存子系統提供了經銷商信息表，用以展示“基礎數據”經銷商的相關數據，其結構如表 示。 表 經銷商信息表結構 經銷商 聯系人 電話 計交易額 精工超市 張三 23132568 30,000 續例子 2： 由于某用戶的需求，所有經銷商在“經銷商信息表”中需分表顯示，要求存在三張“經銷商信息表”分別對應“大 客戶 ”、“一般 客戶 ”和“小第一章 緒論 3 客戶”，用以對應 不同業務員的瀏覽權限。其中“大 客戶 ”的定義為累計交易額達到或超過 200 萬元；“一般 客戶 ”的定義為累計交易額達到或超過 10 萬元且未達到 200 萬元；“小 客戶 ”的定義為累計交易額未達到 10 萬元。 由此又帶來了報表的定制需求。雖然所需的工作不算復雜，但是由于“累計交易額”這種非常規的數據范圍設置，使得其中相對固定的邊界值“ 10 萬”以及“ 200 萬”只能存在于過程化的處理中，而無法也不應該存在于實時交互的查詢條件中。又因為這種固定邊界值的多樣性和可變性，造成進銷存子系統中可能存在大量的同類報表，使得報表的可維護性降低。 例子 3： 進銷存子系統提供產品銷售情況統計表，用以展示一定時期內產品的成本、銷售以及利潤情況，其結構如表 示。 報表中“毛利”列的計算邏輯為既定邏輯。此處未給出計算結果意為宏觀上存在著 不同的計算邏輯，無法統一計算。 表 產品銷售情況統計表結構 產品 成本單價 銷售單價 銷售量 銷售總成本 銷售總價 實結總價 毛利 餅干 ￥ 00 ￥ ? 續例子 3： 由于進銷存子系統提供的默認成本計算方法為“移動加權平均法”，即產品的成本會根據進貨和銷售情況產生波動，所以造成表 的“成本總價”并非是用戶想象中的單純的“ 成本總價 成本單價銷售量”。 另外，表 “毛利”的計算，在用戶中其實也存在差異。有些用戶應用“毛利銷售總價成本總價”；有些用戶應用“毛利實結總價成本總價”；甚至有些用戶應用“毛利稅后總價成本總價”，需要再增加“稅后總價”一列 以“銷售總價”為基礎，應用固定比率稅率（通常為 17%）進行計算。這些對于報表數據內在邏輯的多樣性理解和要求，對于重用的報表流程來說，影響很大。 上面三個例子所提到的報表，在進銷存子系統中 都 是屬于常用和基礎的，這樣都會存在如此之多的定制 情況和可能，就更不必 說個性化較強的 全定制 報表了。 在系統的日常運行維護中，類 似的需求有很多，也就耗費了開發者大量的時間和精力，同時使系統本身變得日益臃腫、龐大 單就報表部分而言，情況更加明顯。基于此，規劃開發一個用以應對多變的需求，靈活強壯，易于使用便于操作的報表子系統，已經是當務之急。 第一章 緒論 4 第二節 論文工作的總述 由于上述所需的報表子系統要求在不同 務子系統中的可通用性強，以及進銷存子系統的業務需求和報表需求更為典型和多樣，所以報表子系統的規劃和開發將以進銷存子系統為目標環境進行。開發完成后，再逐步將 統中其他的業務子系統的報表功能轉交至報表子系統進行。 論文的主要工作源于報表子系統的規劃、實現和運維等各生命周期的過程。也忠實的記錄了在各個生命周期里報表子系統的狀態，期間 有 典型 或非典型 的經驗和教訓，以及由種種原因產生的驚喜和無奈。 具體工作的整體流程循規蹈矩，其中的細節部分不乏亮點。 表子系統的規劃和設計 對于報表子系統的規劃，一直伴隨著業務子系統的規劃、開發和運行。最初的純粹過程型的報表，無法很好的應對功能的擴展和需求的驟增，所以將報表數據與顯示樣式分離的方案被正式提出。 考慮到大量的數據定制和流程定制，為了報表數據部分的代碼可重用，所以將報表數據部分進 一步細分成為數據源和數據整理 兩大模塊 。將數據獲取部分的功能獨立成為數據源 模塊 ，再將其中 對于進銷存子系統可重用的數據獲取部分獨立成為 基礎 數據源子模塊 。 將所有的數據定制和流程定制規劃到數據整理 模塊 中 ，完成從原始數據到最終展示數據轉變的功能 。在明確約定模塊間接口結構后，進一步在各模塊內部進行更具針對性的局部設計。 同時 考慮到報表的柔性需求， 報表子系統還規劃了與報表業務相配套的圖形界面，提供給開發者甚至有權限的用戶，對報表各部分進行設置和細部調整。 在報表子系統規劃和設計期間同時參考了大量的同類系統。 其中包括 清華大學曹軍威 、 范玉順 和 吳澄 的 新一代 用集成平臺系統體系結構 1； 南京航空航天大學方敘生 和 沈平 的 柔性化 統的設計與開發 2； 王元珍 和 汪皓的 達夢智能報表工具 3； 萬琳 和 陳傳波 的 智能報表 系統 4； 此外還包括一些國 內外 的研究成果 5 詳細的設計將在后面的章節進行說明。 第一章 緒論 5 表子系統的編碼和測試 具體到報表子系統的編碼開發環節同樣存在著細致的流程設計和算法設置，更存在與進銷存子系統對接時出現的業務情況和業務需求。 報表中金額精度的控制問題；報表中計算公式 的失控復雜度最優問題； 報表子系統和進銷存子系統之間 的 權責劃分 問題 ，以及后續出現的相互妥協。這些都是開發者需要謹慎考慮的。 至于報表子系統的測試，主要分為 三 個部分。 一是在完成報表子系統各部分模塊原型之后的原型測試；二是在報表子系統各部分模塊逐步擴展開發完成時相應的功能測試；三是針對完整的報表子系統的綜合測試，其中包括了報表子系統與進銷存子系統之間的整合測試。 表子系統的運行和擴展 計劃總是跟不上變化，也就是說哪怕再完美的設計，依然會隨著時間的推移而產生瑕疵，甚至顛覆性的需求變更。這是一個不爭的事實，甚至是慣例。報表子系統同樣面臨 著這樣的命運，在經過了運行平穩期之后，設計時不可預期的情況或需求仍然會出現，對于程序的調整和擴展是不可避免的。 對于邏輯簡單的問題可以通過對報表進行簡單 的 維護或調整 加以 解決；對于一些性能上的問題可以對算法和數據結構進行進一步的 重構和 優化 14對于復雜邏輯的報表需求，在無法通過調整 報表來 滿足時，就只能對報表子系統的功能進行擴充和完整。 上述的若干種情況在報表子系統上線運行維護的過程中都遇到過典型的需求。 表子系統的總結和展望 報表子系統通過了平穩期的運行和各種需求的洗禮，筆者也不斷地總結著該 子 系統 的優點和不足，在不斷的積累中等待著質變產生的契機。 報表顯示樣式的多樣化是未來發展的必然；數據源和報表顯示的徹底分割將是未來發展的方向；報表子系統之于業務子系統可以承擔更多的工作，為業務子系統的開發和維護提供了強有力的支持。 第一章 緒論 6 第三節 論文工作的主要成果 報表子系統的最終建立、平穩過度和運行，圓滿的完成了既定的任務目標。 期間，為解決報表生成器生成文件問題 ， 開發 了 基于 件系統） 相關函數 16的文件生成器文件基礎操作函數類 。其間針對 服務器用戶和其他用戶 對于文件 讀寫 權限進行了 區別 限制。 為解決報表頁面計算公式反復調用問題 ， 開發 了 批量計算公式插件，取代了原先的簡單的計算公式運算模式。通過 的 法，首先對計算公式進行初始化解析優化重組，生成一個臨時的可應用函數，在一張報表中反復使用同一個計算公式時，就可以應用統一的函數調用，完成運算。這個批量計算公式插件在大規模同類運算請求中將發揮顯著的作用，為縮減開銷提供幫助。 為解決報表子系統的相關設置的圖形界面交互 ， 開發 了 應用 一整套設置界面，其中對于報表數據整理和 渲染 的功能進行了全面細致的支持 ，為報表柔性的 可用性和可參與性做出了 貢獻 。 為解決報表顯示限制而擴展的 格控件，取代了原先的純粹 素進行展示的模式。 格控件同樣可以成為公共控件用于其它諸如單據列表的系統功能頁面。 為解決報表導出限制而開發的基于 件的中間處理程序，取代了原先的根據 簽構建 式文件的模式。對于 件的研究和中間處理程序的再封裝，對于后續的數據導出類功能有著極大的借鑒意義，并提供良好的中間調用平臺。 第四節 論文組成和各部分內容 本文的 第二章 是針對報表子系統的需求分析內容。從系統的總體概況、系統的業務需求、功能需求和性能需求等方面進行了闡述。確定了系統的功能范圍和大體的角色分配，為系統的設計打下堅實的基礎。 本文的 第三章 是報表子系統的總體設計。介紹了系統運行的硬件環境和網絡環境以及系統的開發環境，從整體的角度闡述了報表子系統的功能需求并分模塊進行了描述。 第一章 緒論 7 本文的 第四章 是報表子系統的數據庫設計。其中考慮了子系統各個功能模塊的特點和限制，對于各部分的數據庫表結構進行了列舉。 本文的 第五章 是報表子系統的詳細設計和實現。依據 第三章 中的模塊劃分，對各個模塊的功能進行了細致的闡述和限定以及具體實現。 本文的 第六章 是針對報表子系統中各個關鍵問題以及相應解決方案的介紹。其中涉及了數據源、數據整理和數據渲染等各個部分的核 心算法和解決方案。 本文的 第七章 是關于報表子系統的總結和展望。對于目前存在的問題提出一個解決的思路，并對未來發展的趨勢進行預估并提出應對的措施。 第二章 系統需求分析 8 第二章 系統需求分析 系統的需求分析，是在確定系統需求之后，以實現系統目標為目的，通過對系統的功能分解，逐步明確各 功能模塊職能范圍和交互接口，最終確定系統的開發路線和解決方案。 第一節 系統概述 報表子系統主要對進銷存、客戶關系管理、財務管理、物流管理以及協同辦公等業務子系統的數據整合和顯示提供支持。 原有報表模式，屬于原始的功能性報表處理流程，是沒有一個整體系統支撐的，是簡單的基于后臺數據庫進行 詢，得到結果后進行相應的數據調整，最后輸出顯示 。 每張報表一個過程型文件，各個報表散落在平臺的相應業務子系統中，沒有一個統一高度的認識和處理，這樣每一張不同的報表都需要進行大量重復代碼編寫，造成報表開發的效率偏低，周期過長，維護成本大的現狀 17 第二節 系統業務總體描述 就整體而言，報表子系統所涉及的業務并不很復雜，至少相較于其它業務子系統來說，沒有繁雜的工作流和個性化的業務規則。根據長時間的需求積累和客戶需求調研，報表子系統的主要功能大項分為“系統管理”、“細部調整”和“報表展示”，如圖 示。 “系統管理”大項，用于統一管理報表子系統在客戶業務子系統中的應用范圍、權限和初始設置。“報表信息維護”主要用于維護客戶業務子系統開啟報表的范圍，以及所開啟報表的基礎信息?！盀g覽權限分配”主要依據客戶業務子系統的各個用戶角色的不同，對其可應用的報表范圍進行限定分配。“固定參數設置”主要用于報表子系統應用于客戶業務子系統是所涉及的公共參數的維護。例如：客戶業務子系統中報表的分組情況；報表數據導出的文件默認格式；客第二章 系統需求分析 9 戶業務子系統中報表頁面打開的默認方式等。 圖 報表子系統功能結構圖 “細部調整”大項 ，用于客戶根據業務子系統的應用情況，報表瀏覽的習慣以及客戶自身的人事關系、規章制度、業務流程，針對每張啟用報表進行適應性的調整?！皹邮秸{整”可以變更報表中的數據顯示顏色、字體字號、數字精度、數字千分位、金額符號等頁面顯示樣式。“數據范圍調整”可以變更客戶業務子系統中的不同角色用戶在報表中可見的信息范圍，這對于客戶的數據安全和保密性有著重要意義?！敖换バ畔⒄{整”可以維護報表瀏覽時報表子系統提供的實時交互的查詢條件的范圍和查詢類型。 “報表展示”大項，用于客戶業務子系統中可見報表的展示和應用。“數據展示”主要包 括了報表列表展示頁和報表數據展示頁，是報表瀏覽的主要入口，是報表子系統在業務子系統中最主要的嵌入式應用。“數據導出”會提供 式文件的導出，并且兼容舊版中根據 簽構建 式文件的導出模式。“數據鏈接”是指報表中應用的業務子系統中的基礎數據向業務子系統中該基礎數據展示的相關頁面跳轉的鏈接，數據鏈接的存在方便了客戶在瀏覽報表時在相應數據間的切換，當然這個鏈接是客戶通過報表子系統提供的接口注入到客戶業務子系統應用的報表中的。 “報表設置”大項，就是一張報表從需求的邏輯到報表子系統中 真實存在的整個演變發展的過程。其實報表設置是一個并不為客戶所知的部分，因為無第二章 系統需求分析 10 論是從客戶的專業背景還是報表需求的高度的邏輯抽象出發，報表子系統都是不能將報表的核心設置完全開放給客戶應用的。但從報表子系統完整性的角度看，報表設置又是絕對不可或缺的一部分。鑒于此項對于客戶的認知完全透明，所以具體的設計說明本文的將在 第五章 的 第五章第四節 中進行詳細的闡述。 第三節 系統各主要業務和流程描述 按照本章 第二節 中關于系統總體業務的描述，下面將對報表子系統的主要業務流程進行細致的描述。 報表 子系統的應用是屬于其它業務子系統中的嵌入應用，子系統本身更像一個整理數據邏輯的工具或者提供數據的服務。從業務子系統的角度來看的話，如圖 示，一張報表從需求的提出到最終的廢棄，期間存在若干狀態，而這也可以視為單一報表的生命周期。 一張全新的報表，總是由一個報表需求開始的，這個需求可能是客戶提出的，也可能是開發者根據業務子系統的功能流程的變化而破舊立新得來的，總之這是一個僅僅停留在邏輯層面的狀態。 對于客戶業務子系統來說，經過一個“黑盒”的報表設置過程之后，在報表子系統模板庫中生成了一張和所提需求對應的 備選報表。需要強調的是，此時的報表是位于報表子系統的模板庫中，無論該報表的需求是一般性通用需求還是客戶個性化定制需求。 當報表存在于報表子系統的模板庫中時，客戶可以通過報表子系統提供的接口，將該報表復制到業務子系統中以備使用。需要說明的是，此時的報表存在于業務子系統中，是與報表子系統模板庫中的報表區別存在的，所以此時所維護的報表基礎信息是不會影響到報表子系統中的模板報表的，同樣此時報表子系統中的模板報表如果發生改變，也不會對業務子系統報表現狀造成影響，除非重新從模板庫進行復制。當然，客戶可以復制多張相同的報 表，進行不同的設定以用于不同的用戶角色進行瀏覽。 通過權限分配，業務子系統中的報表進入到“可用”狀態，此時的報表已經可以在頁面進行查詢導出等操作，也可以針對使用中的一些問題對報表的細部進行調整。 當客戶不再需要這張報表時，可以進行刪除，該報表將會從業務子系統中第二章 系統需求分析 11 徹底清除，報表的生命周期也同時終止。此處被刪除的是業務子系統中的報表，而非報表子系統模板庫中的模板報表，也就是說，當客戶重新需要的時候，可以從報表模板庫中重新復制一張全新的報表重新開啟報表的生命周期，但是新復制的報表已經不是原先刪除的那張報表了。 圖 業務子系統報表狀態圖 第四節 系統功能要求描述 從客戶應用的角度來說，希望業務子系統中的報表能夠更靈活簡便的應用，是最直接的要求，至于報表子系統與諸多業務子系統之間的通用性和協調性，是開發者需要規劃和設計的。所以報表子系統中最先要討論的報表子系統的參第二章 系統需求分析 12 與者和報表子系統在業務子系統中的功能范圍。 統參與者 按照報表子系統的初步規劃和設計，報表子系統的參與者主要有系統管理員、高級用戶和一般用戶三種角色，如圖 示。由于報表子系統和業務子系統的特殊關系和功能劃分，報表設置部分是獨立于業務子系統的，而其他部分則屬于報表子系統功能在業務子系統中的潛入應用，總的來說都是報表子系統的功能，但擁有不同的入口。 圖 系統簡單用例圖 統管理員 系統管理員的職責范圍局限于報表子系統的獨立核心部分，通過報表設置的一系列操作，將報表的需求轉化成為真實存在的報表。主要針對報表子系統模板部分進行操作和維護，要嚴格遵守不干預業務子系統任何操作的原則。同樣，這個角色對于客戶來說是不可見的。 第二章 系統需求分析 13 般用戶 一般用戶僅能夠針對業務子系統中有權限的報表進行瀏覽、查詢以及導出等簡單操作。因為這種角色的用戶，在業務子系統中的業務職責本身大都存在局限性，不允許其對報表的數據范圍等約束和參數進行控制。一旦可以自由設置報表的數據范圍，那就意味著該用戶可以看到所有范圍的數據。 級用戶 相對于一般用戶而言，高級用戶的權限就大了很多，可以說在業務子系統中所涉及到的報表相關的操作，高級用戶都可以進行調整?？梢詾楫斍皹I務子系統增加新報表，刪除廢棄的舊報表；為一般用戶指定可瀏覽的報表范圍，以及各個報表中的數據的范圍；可以針對每張報表 進行調整，增加自定義的數據