Framework Manager

資料分析 Report Management System (1)

基本介紹

教學目標

初步了解報表管理系統之相關應用。

重點概念

許多組織會透過從組織中不同系統中取得相關的資料儲存至資料倉儲中,然而為了從資料倉儲中取得需要的資訊,就會使用商業智慧工具。商業智慧工具會透過報表中可用資訊之所代表的意義揭露出商業的觀點,以及允許人們選擇特定資訊和格式化報表。因此許多商業智慧的報表皆是被客製化撰寫,時常會花費許多時間在撰寫報表上,主要是因為撰寫報表會需要商業智慧工具和資料倉儲等相關智識。此外在過去為了要減少客製化報表的數量,許多套件分析的應用程式皆有提供預先定義的報表呈現存在於系統中的資料,可惜這些預先定義的報表通常會非常沒有彈性去面對企業客戶多樣化的需求,所以報表管理系統就能夠在面對客戶多樣化的需求時,透過更簡單的設定在對的時間提供對的資訊給對的人們。

其中報表管理系統主要針對資料倉儲管理系統架構中透過商業智慧工具產生的報表進行管理,首先資料倉儲解決系統會從 ERP 系統透過一個或多個來源框架模型取得資料,並且載入資料至資料倉儲中,接著資料倉儲會產生目標框架模型,最後就能夠透過商業智慧工具取得需要的資料協助使用者產生報表。然而資料倉儲解決系統主要由元資料模型、引擎和使用者介面所組成,其中引擎又可細分為報表管理服務單元、資料管理服務單元和來源模型產生,我們主要先了解何謂報表管理服務單元。

所謂報表管理服務單元主要是指提供報表產生服務,其中包括目標框架管理者和報表管理者,目標框架管理者主要是產生在資料倉儲上提供查詢和報表之語義層級的目標框架模型,接著我們會手動套用運算和安全等相關過濾處理,主要是針對報表需求進行建置,過程中會整合多樣化的商業規則形成目標模型套件規則,並且匯整至目標框架模型的套件中,最後目標框架模型的套件會被發佈至商業智慧工具,其中包括可能隱藏資料庫層、商業視圖、維度視圖和命名空間等元素,例如: 我們直接透過 IBM Cognos Framework Manager 產生目標框架模型並且封裝成套件,適合 IT 人員。接著報表管理者主要將模型需要的資訊 (Metadata) 轉換為對使用者有意義的報表維度和測量值,例如: 我們直接透過 IBM Cognos Report Studio 將套件中的來源資料直接拖曳至頁面中產生清單、交叉資料表和圖表,適合一般使用者。

最後報表管理系統可以根據不同的使用者角色,透過預定義報表更容易的產生圖表在對的時間產生對的資訊給對的人們,例如: 我們登入至 IBM Cognos Business Intelligence 報表網站時,會根據所屬的角色直接開啟在資料夾中擁有權限的報表,或者開啟擁有權限的套件,再透過 IBM Cognos Report Studio 建立新報表進行分享給符合權限的使用者開啟該報表。

相關資源

Cognos 建模應用 (3)

基本介紹

教學目標

初步了解 Cognos 多維度建模應用。

重點概念

線上即時分析處理 (Online Analytical Processing,OLAP) 主要是將資料庫中的資料進行多維度分析,雖然在 Cognos Framework Manager 中並無法直接建立 Cube ,卻能建立維度模型關聯 (Dimensionally Modeled Relation,DMR),所謂維度模型關係代表以關聯資料來源的方式實作 Cube 應用,主要透過分層的方式關聯資料,並且允許針對摘要和明細進行資料的切換,並且產生線上即時分析處理的查詢,以轉換出向上彙總和向下鑽取等應用對應的聚合函式之查詢。雖然維度模型關係執行效率較分析維度差,但是可以直接進行即時分析的應用,也就是隨時與資料庫保持連線,不需要先將資料進行轉換分析維度才可以產生報表,因此所花費的時間取決於資料大小和查詢複雜度為主。

首先我們先建立新的命名空間為維度視圖,接著在命名空間上按右鍵選擇「Create」->「Regular Dimension」,再來點選「Add Hierarchy」新增階層和點選擇「Add Level」新增層級。點選層級再按下「Add」增加查詢項目,此時查詢項目有三種角色,分別為 _businessKey 代表唯一不重複的鍵值,_memberCaption 代表以名稱為主和 _memberDescription 代表以描述為主,並且勾選「Unique Level」,此外每個維度會有若干個階層,而每個階層會有若干個層級。接著在命名空間上按右鍵選擇「Create」->「Measure Dimension」,再來點選「Add」新增測量值,因此維度模型關係主要可分為維度結構和測量值兩種類型。

最後在呈現視圖中建立維度和測量值的捷徑進行套件的發佈,此時就能夠讓使用者直接透過該套件建立多維度的報表。此外在 Cognos Report Studio 產生的報表中建立清單時,必須點選「資料」->「逐層分析行為」中,勾選「容許向上逐層分析和向下逐層分析」,就能夠在報表的清單中進行向上彙總和向下鑽取的操作。

相關資源

Cognos 建模應用 (2)

基本介紹

教學目標

初步了解 Cognos 進階建模應用。

重點概念

每當讓使用者直接透過報表專屬的模型套件建立相關的報表,若發生問題時我們要如何進行解決呢? 首先要先了解基數 (Cardinality) ,所謂基數指的是查詢子物件之間的關係程度,可以是一對一、一對多或多對多等情況。透過 Cognos 進行建模時會為了聚合目標和識別多維度查詢子物件採用基數的概念,此時可能會發一些有關報表的陷阱,主要可分為:

  1. 兩個事實資料表之間並沒有維度內容的參考。
  2. 產生不必要的查詢分割,此時會自動套用 FULL OUTER JOIN 關係。
  3. 採用模棱兩可關聯的查詢子物件撰寫報表。

針對上述三種陷阱在建立模型時進行檢查,以及在建立關係時進行驗證,就能夠降低產生報表問題的發生,也就是說透過基數可以避免對於資料進行重複計數,最佳化存取和識別不同的查詢主題所需的事實和維度。接著建立模型時會先建立基礎物件視圖 (Foundation Object View) 主要是由資料來源所產生查詢子物件和所有查詢子物件之間的關係,再透過合併視圖 (Consolidation View) 重複使用模型中已經建立的查詢子物件,並且進行運算和過濾,最後再匯整至呈現視圖 (Presentation View) 以利使用者直接產生報表。為何要多一層合併視圖,卻不能在基礎物件視圖進行運算和過濾,主要原因在於維護困難和可攜性不佳。

更進一步說明,建模應用建議為三層架構,主要可分為:

  1. 資料來源視圖 (Data Source View)
  2. 業務邏輯視圖 (Business Logic View)
  3. 呈現視圖 (Presentation View)

其中資料來源視圖又稱基礎物件視圖主要以資料來源為主、業務邏輯視圖又稱合併視圖主要以業務邏輯為主,透過上述的架構將易於維護和可攜性更佳。

此外再建立合併視圖之前,我們會先進行前置處理,主要可分為一致維度 (Conformed Dimensions) 和虛擬維度 (Virtual Dimensions) 其中一致維度代表在不同業務中能夠將共同資訊進行共享,主要採用查詢將其整合在一起,例如: 資料庫中有查詢一中包括產品和事實一,查詢二中包括產品和事實二,此時我們會在 Cognos 中透過查詢將其自動整合在一起,也就是自動套用 FULL OUTER JOINS,此時報表就能同時包括產品、事實一和事實二。虛擬維度代表在事實資料表之間再建立維度資料表,避免事實資料表多對多的關係對應導致報表中的數值加總不正確,也因此會需要透過維度資料表進行群組之後再產生關係,建議所有有關查詢子物件的關係皆要在基礎物件視圖中建立,再提供給合併視圖使用。

接著在合併視圖中將經常被使用的運算整合至其中,例如: 收益 = 數量 × 單位銷售金額,其中可以使用查詢物件、參數和函數的搭配進行運算,此外還能將經常被使用的篩選整合至其中,篩選主要可分兩種類型分別為嵌入和獨立,其差別主要在於嵌入主要是針對特定查詢子物件進行篩選,而獨立則是事先建立可以套用至所有查詢子物件。

最後同時選取在合併視圖中建立好的所有查詢子物件,按右鍵選擇「Create Star Schema Grouping」建立捷徑至呈現視圖中,接著在套件發佈之後,就能夠讓使用者直接使用呈現視圖中的捷徑快速產生關聯報表。此外合併視圖與呈現視圖之間,實務應用時會再細分出維度視圖 (Dimensional View) 主要是以來基於合併視圖中查詢子物件的多維度物件為主,其被應用於線上即時分析處理 (OLAP) 的查詢報表。

相關資源

Cognos 建模應用 (1)

基本介紹

教學目標

初步了解 Cognos 基本建模應用。

重點概念

Cognos Framework Manager 主要提供 Metadata 模型的建置環境,建立報表專屬的模型套件主要的處理流程為「資料來源」->「建立專案」->「匯入 Metadata」->「準備 Metadata」->「建立報表專用的模型」->「建立和管理套件」->「設定安全」->「發佈套件」。其中 Metadata 模型可以來自於資料庫、檔案、分析維度和其它資料來源。因此 Metadata 模型有兩種類型,第一種為關聯模型,第二種為維度模型,其主要針對資料來源提供有商業呈現觀點,使用者會使用 Metadata 模型針對資料來源進行分析和產生報表。然而報表模型的設計則建議採用星狀綱要,其中主要有兩種類型的資料表,分別為以交易資料主的事實資料表和以參考資料為主的維度資料表,透過此星狀綱要的模型設計將有助於改善報表系統的效能。

規劃多維度模型主要三種綱要類型分別為星狀綱要、雪花式綱要和星座式綱要,其中最多人採用星狀綱要建立多維度模型,因為其查詢較雪花式綱要和星座式綱要更有效率。主要可以分為事實資料表和維度資料表,事實資料表主要是儲存企業關心的主題並且處理過的相關資料,所謂事實代表可衡量數值績效,此外為了效率不會進行正規化,通常資料表非常大量,又稱大型中心資料表,在模型中只允許一個事實資料表。維度資料表中每個維度皆是企業為了達成特定關心主題所需要的查詢資訊,並且與事實資料表有很大的關連係,簡單來說在事實資料表中所識別的主鍵值對應的項目,可以藉由維度資料表快速查詢相關資料,所謂維度代表決策者觀察績效的角度和特性,通常資料表內容較少,但是會有詳細的相關資訊,會進一步進行正規化,形成雪花式綱要,在模型中允許數個維度資料表。

當從資料來源建立一個新專案,在專案中建立多個階層命名空間,接著透過「Run Metadata Wizard」將資料庫中的資料表進行匯入至專案中產生查詢子物件,同時針對多個查詢子物件自動進行關聯,此時若資料表中有數值欄位,則其使用類型主要有三種分別為事實、屬性和識別,針對不同欄位的需求我們會設定不同使用類型和相關屬性設定。再來我可以在查詢子物件上按右鍵選擇「Edit Definition」就能夠進行查詢相關設定。

此外也能直接在命名空間上按右鍵選擇「Create」->「Query Subject」客製化設定查詢子物件,主要有三種類型分別為模型、資料來源和預儲程序。至於查詢子物件之間的關係視覺化呈現可以在查詢子物件上按右鍵選擇「Launch Context Explorer」就能夠了解與其相關的查詢子物件之間的關係。當然我們還可以在查詢子物件上按右鍵選擇「Create」->「Relationship」建立關係,針對不同的需求關係可設為 1..n 、 1..1 、 0..n 和 0..1,例如若我們要進行 LEFT OUTER JOIN 則可設定資料表 A 之關係為 1..1 和資料表 B 之關係為 0..n 就能夠產生對應的 SQL 語法,至於全部查詢子物件之間的關係更可以透過 Diagram 視窗以視覺化方式進行呈現,儘可能以星狀綱要為主,次而雪花式綱要為主,最後非不得已才以星座式綱要為主。

最後在專案中的「Packages」按右鍵選擇「Create」->「Package」建立報表專屬的模型套件,接著在該套件上按右鍵選擇「Publish Packages」就能夠將此套件進行發佈,就能夠讓使用者直接透過該套件建立相關的報表。此外發生多維度報表執行發生錯誤時,建議可以先確認報表專屬的模型套件中之查詢子物件關係是否設定正確。

相關資源