商业智慧 -09 SSAS分析服务

MicrosoftSQLServer2005SSAS分析服務Instructor：Su-HsienHuang2商業資料的特性決策支援的需求比較特定期間內,各部門生產力成長的相對比率?依所選擇的產品線定義相關的市場佔有率定義廣告類型和銷售程度之間的關聯.而這個關聯可以運用於預測營運前台的資料龐大到無法人為解毒細節需要適度的彙總(Aggregate)，把明細資料轉成有意義的資訊，透過報表呈現3傳統資料庫與資料倉儲資料的不同傳統資料庫資料倉儲關聯式資料正規化的資料,資料正確性高著重在交易最佳化可擷取即時資訊常用動作：新增、刪除、修改資料庫中某個時間的資料著重在資料總和,查詢速度要快常用動作：“清空-載入”與”刪除-附加”4商業智慧市場概況1998:SQLServer7OLAPService2000:SQLServer2000AnalysisService2002年擊敗Hyperion成為多維度分析霸主市佔率由14.3%(2001)20%(2004)迫使IBM收購Informix(2000)，並且與Hyperion維持OEM關係2003:BusinessObject收購CrystalDecision(原微軟夥伴)2003:Hyperion併購Brio(報表與ETL專家)動搖了IBM與Hyperion的合作基礎2005:IBM併購Alphablox並且與Hyperion分手2005:SQLServer2005AnalysisService52005商業智慧市場概況關聯式資料庫市場IBM(34.2%)Oracle(33.9%)Microsoft(20.0%)NCR(3.0%)Others(8.9%)OLAP市場Microsoft(28%)Hyperion(19%)Cognos(14%)BusinessObject(7%)Microstrategy(7%)SAP(6%)66OLAP市場概況Inmon資料倉儲之父一個整合的全公司資料倉儲資料整合性高成本較高Kimball商業智慧之父創立starschema、snowflakeschema、dimensionarchitecture每個部門各自維持自己的資料超市(Datamart)資料分散成本較低查詢效率高88Inmon資料超市架構CurrentdetailOperationalTransformationOlddetailHighlySummarizedLightlySummarized(Datamart)MonthlysalesByproductline1981-1992WeeklysalesbySubproductline1984-1992Salesdetail1990-1991Salesdetail1984-198999DataMart建立架構來源一來源二來源三資料倉儲銷售Mart員工Mart財務Mart資料來源固定、確保資料完整性資料格式與單位一致，確保跨不同DataMart分析的正確性DataMart可以共享欄位須花費較多時間來設計Replication1010DataWarehousing架構DataSourcesDataAcquisitionDataWarehouseDataDeliveryDataConsumption•operationalsystems•transactionalsystems•Extraction•Transformation•modeling•Loading•centralrepository•subject-baseddatamarts•metadata•operationaldatastore•BI•decision-support•OLAP•querying•reportingSourceDatabaseOtherSources(files,Excel…etc.)ETLMetadataOperationalDataStoreServerApplicationsWebUserClientsDesktopUserClients•user-facingapps•reportgeneration•subject-baseddatacubes•dataminingDataMart1111DimensionalDataModelDimensionalDataModel是提供user進行查詢分析,最受歡迎的資料結構,也是建置OLAPcube的基礎.(OLAPcube是一種高效率的維度模型)DimensionalDataModel通常具備一個Facttables一套DimensiontablesDimensiontable和facttable組成“StarSchema”通常事實資料表資料量很大，維度資料表資料量很小1212StarSchema*source:DatabaseSystems:Design,Implementation,&Management,5thEdition,Rob&Coronel1313StarSchema事實(Facts):是數值上的衡量(值),代表了特定的商業部份或活動.通常存在於事實資料表,事實表包含了經由其維度加以連結的實實.維度(Dimensions):DSS資料幾乎都會以與其他資料關聯的角度來查看,維度是一般認可的分類,對給定的事實提供了額外的觀點.屬性(Attributes):每個維度表都包含了屬性,維度經由其屬性提供了關於事實的描述性特質.屬性階層(Attributehierarchies):屬性階層提供了由上而下的資料組織,它被用於聚集與資料鑽研(drill-down)/向上捲算(roll-up).14維度資料模型與ER模型比較維度資料表(4tables)v.s.ER資料表(11tables)15ER模型轉換成維度模型步驟一、找出需要匯總的資料成為事實資料表Eg:Order資料表中的Quan(數量)與Price_EA(價格)步驟二、根據分析的維度，把其他資料表反正規化Eg:Date+Date_typeTime維度表Eg:Customer+Cstomer_Type+City+StateCustomer維度表Item+Size+Colors+MaterialsProducts維度表步驟三、把各維度表的主鍵加入事實資料表1616資料立方體(DataCube)*source:DatabaseSystems:Design,Implementation,&Management,5thEdition,Rob&Coronel1717通常做決策支援分析時，為了利於統計分析，常常將一個基本的InformationObject分類成數個Hierarchies。也就是InformationObject間存在著一對多的邏輯關係，即MultipleHierarchies。MultipleHierarchies的維度分類方式又可以分成兩種方式(ConsolidatedDimensionalHierarchies及SnowFlakeHierarchies)產品總類產品類別產品細項分類產品名稱文具禮品雜誌書籍電腦類商業類小說類文藝小說科幻小說武俠小說天龍八部神雕俠侶倚天屠龍記書店書籍類別小說類別武俠小說DimensionAttributeHierarchies1818將不同Hierarchies的InformationObjects完成合併於同一個Dimension中。產品編號產品名稱產品總類產品類別產品細類產品類別分類特色：查詢簡單、速度快需要較多的硬碟儲存空間產品的DimensionTableStarSchema的Dimention1919•類似正規化，將所有類別以獨立的Table來儲存資料，再用PK及FK來維持彼此的關係。產品編號產品名稱產品細類編號(FK)特色：節省硬碟儲存空間，做過正規化，資料不重複存在查詢較複雜產品的DimensionTable產品細類編號產品細類名稱產品類別編號(FK)產品類別編號產品類別名稱產品總類編號(FK)產品總類編號產品總類名稱SnowFlake的多階層Dimension2020StarSchema與SnowFlake比較StarSnowFlake整體資料列(Row)數較少較多所佔硬碟空間大小較大較小設計難易度較容易較困難Table數量較少較多查詢複雜度較簡單較複雜維度搜尋較快較慢支援Bitmapped索引是否2121多維度模型的設計步驟定義OLAP的DataMartFact的選擇Dimension的建立Aggregation的設計2222多維度模型的設計步驟(一)定義OLAP的DataMart著重於企業的單一商業行為(selectthebusinessprocess)決定單元資料的精細程度(Declarethegranularityofatomicdata)決定使用StarSchema或SnowFlake決定資料的時間需求2323Fact的選擇Fact應與時間的階層相符Fact應符合所有Dimension的條件的分割資料設計時以最低Level來回應使用者查詢時非預期的需求四種常見的FactTransactionFact:交易次數SnapShotFact:某一特定時間的特殊狀況LineItemFact：與企業相關的個別項目的所有Meansure條件Event/StateFact:只觀察事情發生與否多維度模型的設計步驟(二)2424•Dimension的建立:要建立一個完整的維度模型，應該考慮三個構面：維度的共同特性、維度階層、維度資料異動。維度的共同特性：維度存在於關連式的Table中，因此包含了FK及支援的屬性。•屬性與Fact相關密切。•簡單及有用的文字資訊。•解析過的時間、名字、或地址元素。•SurrogateKey(代理鍵)，另外新增一個額外的唯一鍵欄位。•DegenerateDimension(退化維度)：存在fact中，與實際dim並無關連(如訂單編號)DimensionTable特性：•包含代理鍵的主鍵•跟factTable有一對多的關係•至少包含一個決策因子•包含Multi-Level的維度階層欄位•包含隨時間變化的資料記錄欄多維度模型的設計步驟(三)2525Aggregation的設計•利用預先計算好的加總來提高分析的速度。因為Aggregation可以在提交查詢前，就先準備好以改善查詢的反應時間，因此可以降低擷取資料時，系統動態計算結果所造成的效能負荷。但是必須注意：•動態建立Aggregation或在資料載入階段時建立Aggregation•Aggregation可以儲存在資料倉儲中以便重複使用，或是在做每一次查詢時動態的建立起來。•以儲存空間與處理時間為考慮因素多維度模型的設計步驟(四)2626DataCell與AggregationCell銷售數量硬體軟體台北100150高雄250100銷售數量硬體軟體電腦產品台北100150250高雄250100350台灣350250600DataCells:4DataCells:4AggregationCells:5為了加快終端決策者取得資料的反應時間，必須利用儲存空間將Aggregation資料事先算好並儲存起來。2727Cube範例2828一二三四時間（季)DimensionsIBMHPBellAcerCompaq台北台中高雄Meansure銷售數量高雄地區第四季HP的銷售量Cube範例(銷售分析架構)2929OLAPCube儲存模式M(multidimensional)OLAP是將多維度資料及彙總資料Aggregation直接存放在特定的資料結構中如：CUBE，藉由事先運算及彙總存放於CUBE中使MOLAP的儲存可提供最快速的查詢回應時間R(relational)OLAP關聯式線上即時分析