書評－給我份報告，讓數據說話

Professional SQL Server 2005 Reporting 　Services 　作者：Paul Turley, Todd Bryant, 　James Counihan, Dave DuVarney 等著 　Wrox出版 　售價：1,360 元 　推薦：Amazon 五顆星

大多數的資訊系統都輸出報表，而每個企業也都存在著各式報表。隨著商業競爭日益激烈，資訊系統需要提供隨手可得、即時而正確的資料。若要讓數據說話，就必須正確地引用資料，套上商業邏輯後，有條理而直觀地呈現。但當企業具一定規模後，要作到如此並不容易。

資訊發送平臺
以往的報表隨附在應用程式內，使用者要看什麼樣的報表，就開啟該應用程式。因此運算力憑藉的是各系統的電腦，安全由該應用程式控管，資料憑專屬的方式取得。而在我們需要廣泛地分析、大量的報表、整合的資料來源以及統一地管理維護時，這種分散的報表開發與部署方式並不合用。

隨著商業智慧（Business Intelligence，BI）概念的流行，大型資料倉儲、累積且集中的多方資料、廣泛而多樣的分析方式等種種需求，讓分析變成獨立的系統，而統籌各式報表的報表平臺應運而生，微軟2004年１月推出的Reporting Services是一個很好的範例。其訴求在完整的報表生命週期管理，從開發、管理、派送3個面向，滿足對報表平臺大部分的需求。

然而，真的要好好設計與照顧報表平臺並不容易，就筆者個人的經驗，主要的難度有以下面向：

正確：資料來源廣泛、商業邏輯複雜以及參與人員來自不同單位都會影響正確性。例如，在報表的生命過程中，參與者有報表檢視者、需求分析人員、報表設計者、提供資料來源之交易系統的操作者、轉至資料倉儲或超市的資料轉換過程等等。冗長的流程讓報表設計與除錯上必須小心翼翼。筆者就曾與同事為了上百筆紀錄彙總後達1億多的金額，但短少300元而忙了一天，最後發現是輸入者選錯了員工部門。開發的初期，更不知多少次，在資料海中比對了半天後，才發現資料轉換的過程中有誤。

呈現：資料呈現方式因人的好惡而難以設計，現今報表的製作還多少需要一點美術概念。報表設計需要能讓資訊以最有效的方式傳達，這裡面有著許多文化因素，例如，報表工具大都是英語體系國家發明的，而中文的呈現往往有些細微差異，例如直書/橫書、中文大寫數字、日期時間的呈現等等。最麻煩的是用新的工具作出與舊格式完全相同的報表。畢竟開發工具不同，例如，以往是用Clipper或Office系列產品，搭配徒手撰寫程式，因此許多用程式所造成的列印效果，而今要改用Web呈現，真是用鐵鎚打蒼蠅。

效率：報表平臺的資料量大，使用人數多，公式計算與繪製報表的邏輯，讓產生報表變得雙重複雜。實作過程中，隨時要考慮到如何有效地切割與分散運算，限制使用者的存取。

安全：當報表數量與使用人數皆多時，認證與授權設計的複雜度就會倍增，你可以想像數百人存取數百張報表，不同人可存取的報表不同，不同人存取相同報表時，呈現的內容也要不同。但這些人平日的工作執掌還會有許多的變動。另外，加密資料的維護也造成系統備份/還原上需要多花一點心思。

發送：使用者要如何方便地看到報表。由於集中在報表平臺，最方便的方式當然是讓使用者以瀏覽器瀏覽，但若使用者人數龐大，大家都擠到Web Server看報表，這會造成效率瓶頸，安全也難以管控。

Reporting Services預設提供週期性、批次地以電子郵件派送報表，或是自動產生報表後存放到共用資料夾，你可以再搭配FTP等方式提供存取機制。或是以.NET程式語言整合Report Viewer Control，乃至於以URL連結某報表，或直接呼叫Reporting Services Web Service，都是讓使用者可以存取報表的方式。選項多，事前規畫就變得重要。設計得好，既可減輕運算負擔，也簡化安全的複雜性。

彈性：由於企業體內早已存在行之有年的安全架構、資料存放與管理機制以及資訊呈現的前端平臺（如：Enterprise Information Portal，EIP），因此，要新加入一個報表平臺，很有可能要與上述的架構整合。這必須要能夠讓 RS的使用者或開發者自行擴充各種需求，例如安全的認證方式、資料提取的方式，以及整合進既有的應用程式來呈現報表。大家需自行依照需求，打造延伸功能的模組。

當報表從交易型系統的附屬品搖身變成分析系統的主要角色之一時，其重要性與專業性已大幅提升。

就自己實際任職顧問的企業，以Reporting Service為報表平臺，負責開發報表者僅有1人，花了約1年半的時間，製作了70多張報表，至今50多張報表上線使用。她表示，開發工具很方便，可以很容易地作出報表，只是資料驗證要花時間，大部分碰到的問題都是從資料庫內數千個資料表間，釐清用途與報表邏輯的問題。

另一個較麻煩的問題是使用者需求變更。由於開發時程較長，1年半前系統分析人員（SA）所提供的報表規格，在驗收時可能已經不適用了。再則是使用報表的習慣改變，例如：將原本所列出的各單位業績金額，修改為只列出入帳的金額此種簡單的過濾條件增減，以及增加金額小計、總計的格式修改等。另一是較令人頭痛的結構變更，例如：企業組織調整。當組織結構一改，所有的報表就要重新檢驗。先前，組織內的5大體系合併，而造成報表開發時程延誤的原因之一是處理「報表共用」耗時過多。原本主體系設計了6、70支的報表，之後為了讓其他體系共用，改利用某個屬性的過濾條件撈取需要的組織資料。其中，若是沒有牽扯組織結構的報表內容，還好修改。但若碰上需要逐一呈現組織階層、隸屬單位或是人員的話，在製作的過程上還是遇到許多困難的地方需要克服。最主要的原因是每個體系的組織階層不同，以及同一個組織內其業務員所隸屬的階層單位不同，為了要將這些業務員的資料呈現在報表上，花費了不少腦力。所幸這些問題都已獲得解決，未來只要跟著既有規則走，就可以較輕鬆地開發報表了。

當問題無解時，回去唸理論
針對前文所討論的難處，先引用華碩董事長施崇棠先生常對員工說的話：「回去把電磁學再唸2、30遍，唸到不只Know How，還要Know Why。」面對錯綜複雜的問題時，唯有追本溯源，提綱挈領才能企求釜底抽薪地解決問題。所以，多看書是必要的第一步。

在此介紹1本講述微軟Reporting Services不錯的書：《Professional SQL Server 2005 Reporting Services》。你可以在網頁中取得該書的第7章試閱。這1章相當不錯，可以當作各種小技巧的範本。若沒時間閱讀該書，單靠此章就可以提升不少功力。

相對於上述整體報表平臺架構性的問題，本書著墨不多，而是平實地解釋各項功能，並提供各種設計範例。適合初學者按部就班地了解Reporting Services各個面向。但若要完整處理報表平臺，這就不僅僅是Reporting Services本身的問題了，例如Windows平臺的目錄服務、資料庫的管理維護、使用者存取報表的應用程式整合等等，這需要廣泛涉獵各種技術，並充分了解使用者需求才行。

該書是從前一版描述Reporting Services 2000的內容改寫而來，由於Reporting Services 2000和2005的相容性很高，因此若你仍在用2000版本，此本書仍有參考價值。

閱讀建議
該書是Reporting Services 2005的入門書，地毯式地描述各項功能。其英文文字平易近人，讓讀者不會因為語文本身造成艱澀難懂的問題。

本書分5個部分介紹Reporting Services，其中第2部分介紹報表設計（從第4章到第7章），第4部分討論報表服務管理（第10、11章），這兩部分需要熟悉。另外，第1部分的簡介，其第3章的架構說明最好也要熟讀。至於其他部分，例如第三部分的Report Model和Report Builder的使用，以及第5部分將報表平臺與應用程式整合，就看你是否有此需求了。

延伸閱讀
● 《SQL Server 2005 Reporting Services報表服務實務應用》：姚巧玫、尹相志、許致學這3位作者在SQL Server領域都鑽研已久，本書融合他們的技術與實務經驗而成。

另外，報表設計的主軸有二：一是資料來源，另一是布置呈現方式。對Reporting Services來說，要強化上述的兩部分，你還需要熟悉SQL與VB.NET兩種語言。SQL用在處理資料，例如將複雜的資料邏輯在資料庫端以預存程序（Stored Procedure）撰寫，然後餵給報表。而在報表版面設計時，所有預設功能外的加值，都是靠撰寫VB.NET。

《作者簡介》胡百敬
現任職恆逸資訊教育訓練處資深講師，聯合報系、睿智資訊與臺灣微軟技術顧問。著有《SQL Server 2005資料庫開發聖經》等書，並為專欄作家。