FrameworkManager

元數據建模工具Cognos10產品培訓

數據庫(Oracle、DB2、SYSBASE、SQLSERVER)CognosFrameworkManagerCognos商業智能平臺數據模型ReportStudioBusinessInsightAdvancedCognosTransformerServercube3Cognos的元數據模型設計工具FrameworkManger可以連接企業的各種數據源（包括關系型數據庫，多維數據庫，文本，OLAP等），對數據結構進行描述，為Cognos的多維分析，即席查詢，報表等各種應用提供統一一致的數據視圖，降低對企業數據訪問的復雜性，同時提供對各種應用使用的結構的統一的管理。FrameworkManger4Cognos工作流程設置和維護安全性管理服務器和報表FrameworkManagerProject發布包運行、察看、打印報表/分析計劃管理模型制作使用實施計劃制作報表/分析配置安裝5了解元數據模型的角色元數據模型是對來自一個或多個數據源的信息的業務展現。BI用戶使用模型對他們的數據源進行分析和報告。報表層元數據模型關系型立方體其它文件元數據模型能隱藏底層數據源的復雜結構可以更好地控制數據怎樣展現給最終用戶6認識通用的數據結構1.認識通用的數據結構2.FrameworkManager介紹3.在FrameworkManager中準備元數據4.在FrameworkManager中為可預期結果建模5.在FrameworkManager中創建業務視圖6.在FrameworkManager管理包7.在FrameworkManager中設置安全性7區分業務型和報表型數據庫業務數據庫報表數據庫OrderFactSalesRepCustomerProductDate0..n1..10..n1..10..n1..10..n1..1CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..n元數據模型中包括的關系型數據庫通常是:業務型數據庫報表型數據庫8業務數據庫是：用于跟蹤每天業務的流程通常是標準化的或部分企業資源規劃(ERP)提供的包了解業務型數據源一個標準化業務型數據庫用來提高精確度并減少冗余。表關系CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..n9了解業務型數據庫的特點業務型數據庫:用于減少冗余適合于數據的寫入和更新而不是數據的讀取10了解業務型數據庫的問題因為標準化業務型數據庫中的數據被細分為很多表(為了消除冗余)，因此大的查詢執行起來比較慢。CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..n1..11..n1..11..n1..10..n1..10..n1..11..n1..11..n1..10..n顯示來自一個產品系列的所有客戶類型。在返回一個結果集之前，查詢必須對七個表中的數據進行檢查。11了解報表型數據源報表型數據源通常使用星型結構布局。所有事務型、大部分數值型數據存儲在事實表中，所有的參考數據，例如產品信息等，存儲在獨立的維度表中。該數據庫含有相同的信息，但是使用五個表而不是九個。OrderFactSalesRepCustomerProductDate0..n1..10..n1..10..n1..10..n1..1報表型數據庫是：典型業務數據庫的拷貝為快速和易于報告與業務數據庫有不同的結構通常維度化，采用星型結構12認識星型結構布局的好處因為星型結構數據庫比完全標準化數據庫含有的表少，因此查詢的性能會更快。OrderFactSalesRepCustomerProductDate1..10..n1..10..n0..n1..10..n1..1“顯示來自一個產品系列的所有客戶類型。”查詢只需要檢查三個表即可返回一個結果集。13FrameworkManager介紹1.認識通用的數據結構2.FrameworkManager介紹3.在FrameworkManager中準備元數據4.在FrameworkManager中為可預期結果建模5.在FrameworkManager中創建業務視圖6.在FrameworkManager管理包7.在FrameworkManager中設置安全性14什么是FrameworkManager?FrameworkManager為Cognos提供元數據模型環境。FrameworkManager中的模型是對來自一個或多個數據源的數據結構的業務展現。根據業務需求創建一個模型:面向報表的關系型，或面向OLAP分析和報表的維度化建模關系型(DMR)。關系型模型維度化模型15了解FrameworkManager中的Project當在FrameworkManager中工作時，實際上是在一個Project中進行操作的。Project以一個文件夾的形式出現在文件系統中，它包含一個Project文件(.cpf)和XML文件。16定義一個Project在一個Project的最高層中包括的對象有：模型名字空間數據源參數映射包17定義FrameworkManager數據元素在一個Project中，采用以下元素進行定義和組織數據:文件夾查詢主題查詢項關系標準維度度量維度范圍關系18了解查詢主題類型數據源查詢主題是底層數據源視圖的SQL查詢根據輸入的對象創建缺省的數據源查詢主題模型查詢主題含有基于模型中現有對象創建的查詢項存儲過程查詢主題含有基于數據庫存儲過程返回列表創建的查詢項19對象的名稱查詢項查詢主題名字空間屬性被設為fact的查詢項不含有任何屬性是fact查詢項的查詢主題至少含有一個屬性是fact查詢項的查詢主題屬性被設為Identifier的查詢項屬性被設為Attribute的查詢項20了解命名規范FrameworkManager中的對象:有一個標識符可以擁有相同的名字，但是必須使用一個名字空間進行唯一標識標識符可以由一個到五個部分組成，例如：查詢項有一個三部分的標識符[namespace].[querysubject].[queryitem]標準維度有一個五部分的標識符[namespace].[dimension].[hierarchy].[level].[queryitem]21了解FrameworkManagerUIProject信息察看器、圖示、維度圖22FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布23FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布24創建Project分析與報表作者合作，了解業務報表需求。了解數據和數據源的結構。創建創建Project確定Project結構導入所需元數據創建Project25分析BI和數據需求確定要解決的與業務智能相關的問題。要了解的問題包括:多語言性能安全表達什么數據能有效的解決它們？需要了解的問題包括:元數據多數據源建模需求關系26創建Project設定Project的名稱和文件地址27了解數據源從下面的數據源將元數據導入模型:關系型數據庫SAPBW現有Cognos模型OLAP數據源Architect模型Impromptu信息目錄DataManager目錄第三方元數據源其它FrameworkManager模型28從多數據源導入從一個或多個數據源導入元數據要考慮下面幾點:給每個導入單獨創建一個名字空間.在數據源之間定義關系.29創建數據源連接為數據源指定連接和認證信息30導入源數據從關系型數據庫導入元數據導入選擇導入對象選擇導入源選擇數據源創建數據源選擇導入對象選擇生成關系的標準31指定關系標準選擇一個創建關系(1)根據主鍵和外鍵創建關系(2)根據兩個表的唯一索引創建關系(3)根據查詢匹配名稱和數據類型創建關系選擇在關系生成過程中涉及的對象集

(1)檢查所選表間的關系，忽略所有現有查詢主題

(2)忽略所選中表的關系，只檢查每個導入的查詢主題和現有查詢主題的關系

(3)執行上面兩個選項當數據庫中存在外鏈接接時，說明導入查詢主題間的關系：選項(1)轉成內鏈接

(1..n)。兩邊的數據關系必須都為1選項(2)創建外鏈接(0..n)。兩邊的數據關系中有一邊必須為0選擇生成關系的標準32了解關系類型:基數（Cardinality）員工安全號1..11..1員工分公司1..10..n零件供應商1..n1..n一對一:一個員工持有一個安全號。一對多:每個分公司可能有很多員工。

多對多:每個零件可以由很多供應商提供，每個供應商可能提供很多零件。33認識基數組合(0,1)..n對(0,1)..n(多對多，需要在模型/數據庫中調整)0..(1,n)對1..(1,n)(可以引起性能的降低。產生外連接，成本高的查詢)1..1對1..1(如同一張表。可以考慮在模型中合并)1..1對1..n(被認為是理想狀態。理論上，所有的事情應該模擬成這種關系)UML符號中的第一個數字指示關系是可選(0)或必要(1)第二個數字定義在模型中兩個查詢主題之間數據關聯的發生：可以是一個（1）或多個（n）34組織內部結構指明數據源查詢主題產生的地方模型這部分中的定義項表示數據源和它們的原始結構為了維護清晰和方便，確定和創建一個project結構。創建數據源視圖(DataSourceView)名字空間(namespace).對每個數據源應用包含數據源查詢主題的名字空間。35關于建模的建議詳細說明報表需求和數據訪問策略只輸入需要的報表對象，并且改變盡可能的少檢驗關系和查詢項的屬性定制運行的元數據手工確定查詢的使用用模型查詢主題控制查詢的生成和使用定義determinants需求解決兩個查詢主題之間的多個不確定關系如果需要OLAP風格的查詢模型化維度用星型結構的分組構筑業務視圖36FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布37準備元數據準備檢查、修改、創建關系添加多語言支持檢查和修改對象屬性編輯SQL添加計算創建和應用過濾添加提示準備元數據38導入之后，確定元數據準確表達數據源。檢查和修改查詢項或度量屬性應該設成Identifier或Attribute修改查詢項或度量屬性，控制這些對象在報表中的展現。39確定查詢項和度量的聚合方式當報表制作者創建一個使用聚合查詢項的報表時，FrameworkManager會應用聚合規則40修改用途（Usage）和常規聚合屬性通過設置用途屬性，確定一個查詢項所代表的數據的預期使用。通過確定數據的預期使用情況，可以確定需要何種聚合規則。通過設置常規聚合屬性來設置一個查詢項的聚合規則。使用屬性有：Identifier：代表被用于分組或匯總與其相關的Fact數據的列。也代表一個索引列。還代表日期或時間列。Fact：代表一個包含數值數據可被分組或匯總的列，例如，產品成本。Attribute：代表一個既非標識也非事實的列，例如描述信息。Unkown：當模型設計開發者不能確定數據的角色時使用41確定FrameworkManager中的關系關系在對象圖表或內容探察器中維護。它們定義查詢主題間的連接和基數?；鶖刀x查詢主題之間關系的數量42認識FrameworkManager中的基數FrameworkManager中有四種類型的基數:0..n–

零記錄到多記錄1..n–一個記錄到多記錄0..1–零記錄到一個記錄1..1–必須有一個記錄43認識基數組合(回顧)(0,1)..n對(0,1)..n(多對多，需要在模型/數據庫中調整)0..(1,n)對1..(1,n)(可以引起性能的降低。產生外連接，成本高的查詢)1..1對1..1(如同一張表?？梢钥紤]在模型中合并)1..1對1..n(被認為是理想狀態。理論上，所有的事情應該模擬成這種關系)441..11..nFrameworkManager在導入過程中為元數據創建關系。可以修改現有關系，也可以創建一個不存在的新關系。關系可以在任意兩個查詢主題之間創建。模型查詢主題關系優先于數據源視圖關系。創建和修改關系ProductProduct_Forecast1..10..n模型查詢主題名字空間ProductProduct_Forecast數據源視圖名字空間優先于45為運行定制元數據在查詢主題中修改運行的SQL，動態控制返回的數據。例如，使用宏中的會話參數和參數映射處理多語言數據和安全性使用提示宏讓用戶對值進行選擇添加查詢結果集的用戶定義函數、計算和過濾46創建計算（Calculations）創建計算，給報表作者提供他們經常使用的值計算可以使用:查詢項參數函數有兩種類型的計算:內置（Embedded）：只想給一個查詢主題使用獨立（stand–alone）：希望重復使用[gosales].[ORDER_DETAILS].[QUANTITY][gosales].[ORDER_DETAILS].[UNIT_SALE_PRICE]查詢項算子計劃收入計算*47了解過濾過濾被用來限制查詢主題所檢索的記錄FrameworkManager有兩種過濾:獨立式(可重復使用)內嵌式(面向單個查詢主題)獨立過濾內嵌過濾48FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布49報表陷阱:引用兩個沒有維度背景的事實引用兩個沒有維度背景的事實被認為是笛卡爾基連接，是將來自兩個數據集的數據放到一個查詢中?？梢酝ㄟ^從事實表中刪除文本項(維度信息)來防止。所有查詢都應該至少用一個公共維度屬性來加以約束。50引用兩個沒有維度背景的事實(續)查詢主題報表輸出SALES_TARGETStaffcodeRetailernameSalestargetProductnumberOrderdetailcodeActualrevenueUnitcostProductnumber1..11..nPRODUCTProductnumberProductnameProductimage1..11..nORDER_DETAILS$171,576,387.88HinodeMegane$171,576,387.88CordagesDiscount$734,257$175,400$436,017$612,334SalestargetAnapurnaDieFitness-Experten$171,576,387.88AlloAllo$171,576,387.88HanagataGolfShopActualrevenueRetailername$50,882$958,122$171,576,387.88$171,576,387.88從事實表中引用維度信息容易產生笛卡爾基，應該將其刪除，而從兩表的共享維表中引用該項。51SALES_TARGETStaffcodeSalestargetRetailertnumberOrderdetailcodeActualrevenueUnitcostRetailertnumber引用兩個沒有維度背景的事實(續)查詢主題報表輸出1..11..nRETAILER_DIMENSIONRetailernumberRetailernameProductnumber1..11..n$76,387HinodeMegane$1,276,387CordagesDiscount$734,257$175,400$436,017$612,334SalestargetAnapurnaDieFitness-Experten$576,387AlloAllo$745,783HanagataGolfShopActualrevenueRetailername$50,882$958,122$171,576$876,387ORDER_DETAILS共享維表該項來自共享維表52報表陷阱:產生不需要的查詢裂縫不需要的查詢裂縫(完全外連接)會在下列情況下產生:模型允許創建含有盲點的查詢查詢主題被錯誤的當作事實53產生不需要的查詢裂縫:示例ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODESALES_TARGETSALES_STAFF_CODE

SALES_YEAR

SALES_PERIOD

RETAILER_NAME

PRODUCT_NUMBER

SALES_TARGET

RETAILER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

FIRST_NAME_MB

LAST_NAME

LAST_NAME_MB

POSITION_EN

POSITION_FR

POSITION_DE

POSITION_NL

POSITION_JAPRODUCTPRODUCT_NUMBER

INTRODUCTION_DATE

PRODUCT_TYPE_CODE

PRODUCTION_COST

MARGIN

PRODUCT_IMAGEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

PRODUCT_NUMBER

ACTUAL_REVENUE

QUANTITY

UNIT_COST

UNIT_PRICE

UNIT_SALE_PRICE1..n1..11..11..n1..n1..11..n1..11..n1..1盲點查詢主題54產生不需要的查詢裂縫:示例用被選中的查詢主題制作報表結果如下：

可以看到ActualRevenue膨脹了。這是因為ActualRevenue是針對產品的合計，而不是產品和銷售的結合，即不管銷售是否賣過的產品，都被計算在內。這是由于ORDER_DETAILS查詢主題和SALES_STAFF查詢主題之間沒有直接的關系引起的。同兩邊有關系的ORDER_HEADER查詢主題也沒有包括在查詢里。這就是一個盲點。由于一個查詢主題在查詢中被省略使一個需求的關系路徑丟失時，就產生盲點。如果ORDER_HEADER查詢主題被包括在查詢里。就會得到正確的結果。解決這個問題的方法是將ORDER_HEADER和ORDER_DETAILS合并。55解決不需要的查詢裂縫:示例ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODESALES_TARGETSALES_STAFF_CODE

SALES_YEAR

SALES_PERIOD

RETAILER_NAME

PRODUCT_NUMBER

SALES_TARGET

RETAILER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

FIRST_NAME_MB

LAST_NAME

LAST_NAME_MB

POSITION_EN

POSITION_FR

POSITION_DE

POSITION_NL

POSITION_JAPRODUCTPRODUCT_NUMBER

INTRODUCTION_DATE

PRODUCT_TYPE_CODE

PRODUCTION_COST

MARGIN

PRODUCT_IMAGEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

PRODUCT_NUMBER

ACTUAL_REVENUE

QUANTITY

UNIT_COST

UNIT_PRICE

UNIT_SALE_PRICE1..n1..11..11..n1..n1..11..n1..11..n1..1查詢主題56SALES_TARGET解決不需要的查詢裂縫:示例PRODUCTNAME:AloeRelief,BearEdgeANDLASTNAME:AllessoriPRODUCT_NAMELAST_NAMEACTUAL_REVENUEAloeReliefAllessori$69,346.28$1,190Summary$1,154,494.82$22,586BearEdgeAllessori$1,085,148.54$21,296合并前的報表輸出SALES_TARGETPRODUCT_NAMELAST_NAMEACTUAL_REVENUEAloeReliefAllessori$2,129.16$1,190Summary$35,946.36$22,486BearEdgeAllessori$33,817.20$21,296合并后的報表輸出57當一個查詢對象和另一個查詢主題具有多種關系時會產生模糊連接。使用哪個關系呢？報表陷阱:使用含有模糊連接的查詢主題編寫報表OrdersTimeOrderDate=DayKeyShipDate=DayKeyCloseDate=DayKeyCognoa8通常按字母順序選擇關系，在這種情況下將選擇CloseDate。58解決多模糊連接的問題讓查詢主題扮演不同的角色解決多模糊連接的問題。OrdersTimeOrderDate=DayKeyCloseDate=DayKeyShipTimeCloseTimeShipDate=DayKey59用FrameworkManager進行星型模式建模無論是對業務型還是報表型數據源進行建模，將其模型化為一種虛擬的星型模式通常會產生最佳的結果。模型化不恰當的元數據會產生不可預料的結果和各種報表陷阱。60星型模式建模的優點主題域集市(星型模式分組)數據針對特定的業務區最終用戶更加容易理解——表數量最少可編輯和擴展——可以輕松添加一個新的事實并重復使用現有維度共享維度可以防止數據陷阱——事實通過維度和其它事實建立關系61定義Cognos的基數使用Cognos使用基數:用于聚合目的告訴Cognos哪些查詢主題是維度，哪些是事實（細節）ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1只帶有0..n或1..n基數的查詢主題定義為事實?；鶖凳且圆樵冎黝}在查詢中的使用為基礎。62認識查詢的使用了解包括四個查詢主題的查詢。事實維度維度事實ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1ORDER_HEADER并不確定為事實，因為它并沒有只帶有“1對n”的基數。63認識查詢的使用(續)了解包括SALES_STAFF、SALES_BRANCH和ORDER_HEADER的查詢。不在查詢中事實維度事實ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1只使用SALES_STAFF、SALES_BRANCH和ORDER_HEADER時，ORDER_HEADER將起到一個事實的作用。64手工建模手工建模:打印模型的導入視圖確定哪些查詢主題可以作為事實或維度確定其中含有描述性數據的事實查詢主題65作業1對象圖表66作業1對象圖表(解決方案)1..n1..n1..11..1OrderDetailsDimensionBranchHistoryDimension1..11..n①③②④⑤67①PRODUCT和PRODUCT_TYPE兩個查詢主題根據查詢表現為事實或維度。它們是十分合適的合并對象，因為PRODUCT是一個雪花維度?？梢院喜RODUCT、PRODUCT_TYPE、PRODUCT_LINE和PRODUCT_MULTILINGUAL。②

ORDER_HEADER和ORDER_DETAILS可以合并，因此ORDER_HEADER就不模糊了。這對于ORDER_HEADER不是最終的解決方案，但是一個開端。③

SALES_BRANCH和SALES_STAFF根據它們在查詢中的使用，兩者都是模糊查詢主題。這兩個查詢主題連同COUNTRY和COUNTRY_MULTILINGUAL有著緊密的關系，并可以合并成一個模型查詢主題。④這個新的查詢主題將有兩個潛在的連到ORDER_HEADER的關系，一個從SALES_STAFF，一個從SALES_BRANCH。為了確保新的查詢主題之間的連接路徑不模糊，可以建一個允許跟蹤歷史的拷貝，對于銷售員轉移到另一個部門發生的銷售事件進行追蹤。我們將為每個查詢主題刪除不必要的關系，保持合適的關系。⑤盡管ORDER_DETAILS和ORDER_ITEM之間沒有報表問題，為了遵循星型結構的規則，要在兩個查詢主題之間放一個維表。這讓我們在只有一個事實表的一個邏輯業務組中放置一個事實（星型模式）。我們還可以用共享維度查詢兩個事實。解決方案說明68定義模型查詢主題模型查詢主題可以重復使用來自數據源查詢主題和其它模型查詢主題的查詢項。對解決報表陷阱問題和為報表作者創建有意義的元數據視圖很有用。模型查詢主題允許對元數據進行進一步的定制來滿足特定的需求，不會對底層查詢主題產生影響。用于創建模型查詢主題的數據源查詢主題模型查詢主題ProductProductLineProductTypeProductDimension69對數據源視圖建模盡可能的保持數據源視圖為其原始狀態。當數據源發生變化時可以減少維護工作。數據庫ProductTimeCustomerFrameworkManager模型

(數據源視圖)ProductLineProductTypeProductDimensionProductsTimeCustomerProductLineProductTypeOrdersOrders新建名字空間70為運行定制元數據通過添加模型和計算創建動態SQL，增強業務規則或解決報表問題71控制查詢的生成和使用通過下列方式使用模型查詢主題明確數據源查詢主題的角色:用維度分開事實并用事實分開維度將雪花型表壓縮為單一模型查詢主題SALES_STAFFSALES_BRANCH1..11..nSALES_TARGET1..11..nCOUNTRY1..11..nSalesStaffDimension1..1SALES_TARGET1..n模型查詢主題72解決多模糊連接的問題一些查詢主題可能含有到另一個查詢主題的多個模糊連接。OrdersFactSalesStaffDimensionSalesStaffCodeSalesBranchCodeOrdersFactSalesStaffCodeSalesStaffDimensionBranchHistoryDimensionSalesBranchCode73創建“純”事實ORDER_HEADER含有應該在一個OrdersFact查詢主題中使用的鍵。ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

SHIP_DATE

PRODUCT_NUMBER

Quantity

UnitCost

…….1..n1..1OrdersFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

ORDER_DATE

ORDER_CLOSE_DATE

SHIP_DATE

Quantity

UnitCost

UnitPrice

UnitSalePrice

ActualRevenue

PlannedRevenue

GrossProfit

ProductionCost

Margin合并ORDER_HEADER和ORDER_DETAILS創建一個可用的事實查詢主題的基礎。然而，不是所有的ORDER_HEADER查詢項，都應該放進新的查詢主題。刪除任何代表維度信息的查詢項(如：RETAILER_NAME),并隱藏那些報表制作者可見的事實的鍵。這使新的查詢主題象在星型結構數據倉庫中的一個“純”的事實表。74OrdersFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

ORDER_DATE

ORDER_CLOSE_DATE

SHIP_DATE

Quantity

UnitCost

UnitPrice

UnitSalePrice

ActualRevenue

PlannedRevenue

GrossProfit

ProductionCost

MarginReturnsFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

RETURN_CODE

RETURN_DATE

ORDER_DETAIL_CODE

RETURN_REASON_CODE

RETURN_QUANTITY創建“純”事實(續)RETURNED_ITEM需要和OrdersFact相同的關系。RETURNED_ITEMRETURN_CODE

RETURN_DATE

ORDER_METHOD_CODE

RETURN_REASON_CODE

RETURN_QUANTITY因為退貨和訂單的關系緊密，所以它們需要與作為訂貨維度的關系同樣。這樣能夠提供給有寫邏輯報表能力的報表制作者，在沒有包括訂單信息的情況下得到退貨的結果，如“哪些產品被退貨？”。為了建立RETURNED_ITEM與所有需要的維度之間的關系，可以創建一個模型查詢主題或改變數據源查詢主題的SQL以包含所有需要的鍵。75ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

SHIP_DATE

PRODUCT_NUMBER

Quantity

UnitCost

…….1..n1..1創建“純”維度將來自ORDER_HEADER的維度查詢項添加到OrderDetailsDimension。OrderDetailsDimensionORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

ORDER_DETAIL_CODE添加ORDER_NUMBER,RETAILER_NAME和RETAILER_NAME_MB到OrderDetailsDimension解決ORDER_HEADER作為一個模糊查詢主題產生的問題。確定用于報表目的需要的ORDER_HEADER中的查詢項，如ORDER_NUMBER和RETAILER_NAME。我們可以安置ORDER_HEADER中剩余的需求項到OrderDetailsDimension中。通過把查詢項放置到一個邏輯位置，并確定這些維度查詢項在最終的模型展示中沒有丟失，來創建一個“純”維度。報告也可能需要ORDER_DETAIL_CODE。我們可以選擇把它放在OrdersFact模型查詢主題中使它生效，或更適合它放在一個和它有同樣描述信息的查詢主題中。76建模為星型模式–考慮事項需要克服的一些障礙:復雜的數據源視圖（業務系統數據源非為報表設計）大量連接的性能影響（為提高報表性能，參考數據倉庫存儲理念，無法避免大量表的連接）缺少時間維度表造成時間匯總很難處理（沒有時間維度，用LevelsFact和OrdersFact作報表得不到預期的結果）實現一個時間維度添加一個時間維度可以讓作者進行比較簡單的基于時間的查詢。77TimeDimension

MONTH_KEY

DAY_KEY

……OrdersFact

SHIP_DAY_KEY

Quantity

…….SalesTargetFact

MONTH_KEY

SALES_TARGET1..n1..1SalesTargetFact

SALES_YEAR

SALES_PERIOD

SALES_TARGET1..11..nOrdersFact

SHIP_DATE

Quantity

…….ProductDimension1..11..n1..11..n1..11..n1..n1..1ProductDimension78解決多模糊連接的問題實現一個時間維度后，我們可能需要使用不同角色扮演時間維度解決多模糊連接的問題。OrdersTimeOrderDate=DayKeyCloseDate=DayKeyShipTimeCloseTimeShipDate=DayKey79設定DeterminantDeterminant可以定義唯一標識一個數據集的數據庫列(查詢項)集合，或者可以指定一個能夠標識數據中的非唯一集的列集合。下列情景，在很有限的情況下才需要設定determinants，其中包括：連接在一個查詢主題上的多個粒度層BLOB數據類型在查詢主題中Determinant是Cognos8的特性，它設計成提供控制所有粒度。在Determinant中指定的設置給Cognos8提供了充分的信息正確聚合有多粒度層查詢中的事實數據。Determinant與數據庫中的鍵和索引的概念的關系最密切。在Determinant中沒有層次結構的概念，盡管它們被指定的順序決定它們估算的順序。設定Determinant(續)TimeDimension

MONTH_KEY

DAY_KEY

……OrdersFact

SHIP_DAY_KEY

Quantity

ActualRevenue

…….SalesTargetFact

MONTH_KEY

SALES_TARGET1..11..n1..11..n1..11..n1..n1..1ProductDimension在一個TimeDimension查詢主題中，出現多粒度層的連接，MONTH_KEY和DAY_KEY

。這樣當在兩層進行多事實查詢時，會出現問題，而你則需要防止重復計數。81多粒度的查詢會出現重復計算查詢結果82單粒度查詢的正確結果83設定Determinant(續)數據集示例#1Monday,Jan2,200520050102Jan052005012005Sunday,Jan1,200520050101Jan052005012005DayNameDayKeyMonthNameMonthKeyYearKey數據Determinant設置NoYesDayNameMonthKeyMonthNameYearKeyDayKeyDayYesNoMonthNameMonthKeyMonthYesNoNoneYearKeyYearGroupByUniquelyIdentifiedAttributesKeyName84設定Determinant(續)在例中，能定義3個Determinant，兩個非唯一Determinant(YearKey和MonthKey)，和一個唯一Determinant(DayKey)。DayKey是表的唯一鍵。因為它是唯一鍵，我們只選UniquelyIdentified設置，而不選GroupBy。MonthKey也是鍵，但不唯一。因此不能選UniquelyIdentified設置。然而，MonthKey是所有在數據中為一個特定年指定一個月值所需要的。如果要從這個時間表查詢月，要通過MonthKey分組查詢。這樣做是因為值是重復的。這就是為什么我們在Determinant設置中選GroupBy。類似的邏輯應用于YearDeterminant。當用上表的一個列評估一個查詢時，Cognos8查詢引擎每次就要尋找一個Determinant列參照，當找到它時就停止。85設定Determinant(續)數據集示例#2Monday,Jan2,200520050102January012005Sunday,Jan1,200520050101January012005DayNameDayKeyMonthNameMonthKeyYearKey數據Determinant設置NoYesDayNameMonthKeyMonthNameYearKeyDayKeyDayYesNoMonthNameYearKey,MonthKeyMonthYesNoNoneYearKeyYearGroupByUniquelyIdentifiedAttributesKeyName86設定Determinant(續)在例中，能定義3個Determinant，兩個非唯一Determinant(YearKey和MonthKey)，和一個唯一Determinant(DayKey)。與數據集示例#1不同，MonthKey不能滿足在數據中為一個特定年指定一個特定月值。如果想要從這個時間表在給定的年查詢月，我們要寫一個使用selectminfunction的語法和通過YearKey和MonthKey分組。因此，當我們為這個特殊的數據集指定Determinant時，我們為月組合一個YearKey和MonthKey的Determinant鍵，并設置中選GroupBy。87月層Determinant的作用查詢結果GroupBy的設置避免了重復計算88FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布89模型化元數據和準備業務視圖要增強模型的業務視圖，可以:模型化預知的結果（星型結構）模型化OLAP風格的查詢（模型化維度）創建一個或多個業務視圖添加計算創建和應用過濾添加提示模型化元數據&準備業務視圖90創建一個業務視圖基本的模型結構包括一個數據源視圖和一個業務視圖.業務視圖為報表作者提供一個有意義的元數據視圖。展現層物理層在FrameworkManager中可以用多種方式構造Project。在此推薦的構造FrameworkManagerProject的方案，主要考慮可以降低報表制作的復雜性，有利于模型的維護：推薦基本結構采用由包含數據源和存儲過程查詢主題的數據源視圖(物理層)和包含快捷鍵和模型查詢主題的業務視圖(展現層)構成的雙層模型。雙層模型適用報表制作者和數據建模人員。展現層可以讓報表制作者更加容易的查找和理解數據，物理層則是展現層的基礎。91創建一個業務視圖(續)創建一個代表星型模式的業務視圖可以:為最終用戶提供一個直觀視圖提供可預測的結果Customer數據源視圖ProductLineProductTypeProductTimeCustomerOrdersProductOrdersBusinessViewOrdersProductsTime業務視圖最終的業務視圖可以是為解決報表陷阱而創建的數據源查詢主題以及模型查詢主題的捷徑92使用星型模式分組構建業務視圖可以使用星型模式分組快速構建業務視圖。對象表項目查看器用StarSchemaGroupingWizard創建基于以事實為中心和其關聯維度的模型的邏輯業務視圖。這種類型的展現允許報表制作者容易用共享維度創建多事實查詢93識別業務視圖中的共享維度命名規范使得共享維度的識別變得很容易。項目查看器為了返回在查詢中指定的每個事實都帶有正確的聚合結果數據，共享維度允許Cognos創建一個拼接的查詢。這些出現在每個名字空間中的維度的快捷鍵有相同的名稱，表示它們是共享的和指向的是同一個原查詢主題94認識FrameworkManager中遞歸關系當導入元數據時，FrameworkManager在表中顯示自連接（self–join），但是不以查詢來執行它們。遞歸關系

SALES_STAFF_CODE和MANAGER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

…….MANAGER_CODE95解決遞歸關系使用模型查詢主題或快捷方式創建和修改遞歸關系。遞歸關系現在可以進行編輯1..n1..1SALES_STAFFSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

…….MANAGER_CODEManagersSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

96定義維度建模關系(DMR)元數據在Cognos中，DMR指的是一個建模人員為關系型數據源提供的允許進行OLAP風格查詢的維度信息。這種信息通過以下元素定義：標準維度度量維度范圍關系（ScopeRelationship）97決定一種建模樣式使用標準關系建模：用基本關系即席查詢和報表使用維度建模關系建模:希望在AnalysisStudio里對關系型數據進行分析希望在報表和即席查詢中進行向上/向下鉆取希望在制作工具中訪問成員函數98定義標準維度標準維度由一個或多個用戶定義的層次結構組成，這些層次結構由層、鍵、標題和屬性組成。層次結構層成員標題業務鍵屬性層次結構面板項目查看器層的信息用于在執行查詢和分析時正確地聚合度量99區分Determinant和標準維度Determinants為查詢主題設置多事實/多粒度查詢所需rollup聚合Blob需要不能提供OLAP功能標準維度設置的層次結構允許對關系型數據進行OLAP風格的分析給單粒度查詢定義rollup聚合是AnalysisStudio所需的100定義度量維度度量維度是一個事實邏輯集合，可以實現對關系型數據源進行OLAP風格的查詢。度量維度用于鏈接相關標準維度，可以:從數據庫中的單一表創建從跨多個數據庫的多個表創建度量維度用圖標來標識101定義范圍關系范圍關系存在于度量維度和標準維度之間，定義可以用于報表的度量所在的層。范圍可以被創建、修改或刪除。在度量維度和標準維度之間的范圍關系自動創建，它隱含在已經定義了有效的連接關系的查詢主題中102FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布103創建和管理包要創建和管理包，可以:定義包的內容修改包指定語言設置和編輯包的內部啟用版本控制創建和管理包104將要發布的模型對象包括在包里創建和修改包模型包105設置包函數列表（PackageFunctionList）包函數列表可以用來指定給報表作者提供哪些數據源函數。106發布包當發布一個包時，可以選擇保存到ReportNetserver或一個網絡地址在發布之前，應該對包進行檢查CognosConnectionFileSystem107設置模型版本控制（ModelVersionControl）發布一個包時，可以選擇在CognosBIserver上保留多少個模型版本。設定保留多少個版本108嵌套包創建一個嵌套包時，會建一個基于其它現有包的主包（masterpackage）。用嵌套包重復使用模型信息，可以節省時間，維護也更加方便。嵌套包的另一個優點是可以僅發布主包(masterpackage)就能夠將所有被引用的包提供給報表作者109FrameworkManager工作流程導入ContentStore數據源ReportStudioQueryStudioAnalysisStudio創建Project準備元數據模型化元數據&準備業務視圖創建和管理包管理Project設置安全性發布110設置安全性Cognos的安全性是通過用戶認證和內容授權訪問來實現的要在FrameworkManager中設置安全性，可以：定義包的訪問權限創建安全性過濾定義對象的訪問權限定義包管理權限設置安全性111配置認證提供者Cognos使用第三方認證，同時利用提供者現有的用戶和組知識庫。提供者保存認證信息，例如用戶名、ID