- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
                        查看更多
                        
                    
                维度资料表
                    圖3-34 兩次分離的迷你維度資料表 回前頁 新增資料到大維度資料表 分離核心維度 (Separation from core dimension) 隨著時間改變,客戶人口統計資料也會在迷你維度資料表中緩慢地增加,由於客戶維度資料分別儲存在不同的兩個維度資料表中,如此會造成查詢的複雜度,因此可在客戶維度資料表中複製一份最新的人口統計資料,如圖 3-35 所示,可以增加查詢效率。  圖3-35 最新客戶人口統計資料儲存兩份 回前頁 新增資料到大維度資料表 迷你維度資料表可能無法與原來的維度資料相連 即兩個維度資料表必須經由事實資料表才能聯結,而原來合在同一維度資料表上時並無這問題。 客戶的人口統計資料只有在產生消費後才能與客戶產生關聯。 建議新增空的交易資料來處理。 簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論 結論(I) 本章主要介紹建置 BI 系統所需使用到的資料模型理論基礎 Dimensional Model 事實資料與維度資料表  確定每一個維度模型的顆粒度,不同顆粒度的事實資料要放在不同維度模型中  如建多部門資料超市,則需建構一致的維度 (Conformed dimensions) 資料與事實 (Conformed facts) 資料 結論(II) 規劃維度資料表時盡量使用代理鍵 (Surrogate key) 機制當主鍵,避免後續不必要的更動 時間維度可獨立儲存或縮減成數值儲存到事實資料表 變動緩慢的維度邏輯上以第二型處理最好            ERP學會簡介 本會於91年1月26日成立。 使命:  整合產官學研資源,協助華人地區推動以ERP為基礎的企業e化。 目標:藉由統合與發展知識 協助廠商提高e化效率 協助軟體公司發展適合華人e化軟體 協助台灣成為華人地區最佳e化顧問供應地 認證起緣 企業面臨狀況 眾多的企業、軟體與顧問公司無法找到有企業e化核心知識的管理人才 台灣有獨步華人地區的製造業管理與運籌知識, 但利用此知識創造的服務產業還有很大成長空間  需有單位培養龐大且優質的人力資源  BI檢定考試結構 規劃師與應用師為企業內種子人員 中大ERP中心網站:.tw 學會網站:.tw Email: pyhsu@.tw  聯絡資訊 簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論 Kimball’s Architecture       Operational Source Systems       Extract          Data Staging Area       Load       Load          Data Presentation Area       Data mart #1       Data mart #2       Service       Data Store      Processing       Access       Access          Data Access Tools       Query Tools     Report Writers     Analytic App.         Modeling:           Forecasting            Scoring           Data Mining       DW Bus       Conformed facts  dimensions 回前頁 建立資料倉儲匯流排架構(I) 無法整合的最大原因為各部門用的模型中會有資料同名異義 (Polysemy) 與異名同義 (Synonymy) 的問題。 例如兩個不同部門的維度模型都使用庫存量來代表企業的庫存,但其中 A 部門的庫存量包含在途量,另 B 部門的庫存量並未包含在途量,因此就會造成同樣名稱的事實欄位卻在報表上有不同的數字。如果這兩個部門的報表被拿來相互比較就會出現令人非常困惑的狀況。 另一種情況如果 X 部門用訂單量來代表銷售量,而另一個 Y 部門用銷售量,則這兩部門的報表如放在一起被討論會產生另一種困惑—如果兩個欄位意義一樣為何不能只用一個名字,如果意義不同為何數字都一樣。 建立資料倉儲匯流排架構(II) 為了解決資料同名異義與異名同義,Kimball 建議需要事先建立資料倉儲匯流排架構 (Data warehouse bus architecture)。 企業須成立一個單位掌控整體性的 BI 系統的資料架構來達成資訊傳遞的一致性 建立資料倉儲匯流排架構(III) 
                 原创力文档
原创力文档 
                        

文档评论(0)