保險數據倉庫建模

⑴ 數據倉庫數據建模的幾種思路

數據倉庫接典型的兩種數據倉庫建模的理論是維度建模和基於主題域的實體關系建模，這兩種方式分別以Kimball和Immon兩位大師為代表。維度建模以數據分析需求為驅動，倡導匯流排架構：一致的事實和一致的維度，這種數據模型易於用戶理解和數據分析操作。基於主題域的實體關系建模以源系統數據為驅動，整合企業的所有數據，站在企業級的高度對數據進行抽象，整合，採用3NF的實體關系理論建模，這種數據建模方式以更為抽象的方式嘗試建立一個相對穩定的數據模型，並能描述企業級的數據關系。在工業界往往把兩種方式結合起來運用數據倉庫的不同數據層次結構中。
我們上周主要是針對採用基於主題域的實體關系建模中數據整合的方式進行較為深入的討論，討論了以下三種思路：
以屬性聚集的方式同一主題域中不同實體的屬性。比如對於會員、公司、客戶等等實體對象我們都有地址屬性信息、名稱標識屬性信息等等，這種思路就是把屬性內聚性高的欄位整合在一起，並把不同的屬性打上類型標識以樹表的形式存放。它的優點是：第一，模型穩定性好，外圍系統變化了欄位，只需要添加不同的類型，不需要進行表結構的變更；第二，減少大量冗餘記歷史數據。它的缺點是：第一，丟失了很多實體的屬性標識信息，我們從模型上將看不到一個會員究竟有哪些地址屬性，只能通過查詢類型代碼才能獲取這些信息；第二，它極度的膨脹數據表的記錄數，因為它採用豎表的形式存放；第三，應用起來很難，效率是一個大問題，因為我們往往要使用一個實體的多個欄位，就會有很多join操作和豎轉橫的操作。第四：屬性聚集也是一件比較難操作的過程，應為這是一個抽象的過程，對建模人員的業務背景知識和抽象能力都提出了很高的要求；第五：雖然減少了冗餘的記歷史數據，但是記歷史的操作也較為復雜。
採用面向對象建模的方式，抽象不同實體的共同屬性，然後再一步步採用繼承、組合等面向對象的思想具體化實體。他的優點是模型模型概念比較清晰，缺點也是模型相對不是很穩定，整合後的數據的後續應該也面臨重新組合的問題。
貼源的建模方式：
採用基本保持源系統的方式進行建模，重點放在數據的標准化，一致化，和數據業務意義的梳理。這種做法和我們目前數據倉庫的做法比較類似。它具有實施比較容易，快速實現，前台可以直接使用數據；缺點是整合度不高，模型不穩定。
模型終究是為數據分析應用服務的，具體採用什麼方式建模需要根據實際業務特點和源系統的特點決定。阿里巴巴的源系統具有變化快，數據分析應該變化快的特點，響應速度也要快的特點，而且我們要求不同系統之間整合的需求並不是很大，往往深度的數據整合帶來的是應用上的不方便。因此，我個人覺得採用貼源的方式是當前更優的方案。

⑵ 保險公司如何使用數據倉庫增加利潤

目前保險業的競爭愈演愈烈，綜合競爭力，特別是對大數據和變現能力的提升對於保險企業至關重要。因此，保險公司的數據倉庫建設相當必要和重要。
數據倉庫在保險業主要應用有CRM和DSS，另外還有RM，其實變現提升利潤更主要還是應用在業務系統，即CRM上。對客戶信息、客戶關系等大數據分析，能夠有效提高交易量和成交率。

⑶ 數據倉庫建模，星型模型大致了解，就是事實表對應許多維表；對雪花型模型就不是很理解了

詳細和你說一下星型模型和雪花模型
星型模式 vs 雪花模型多維數據建模以直觀的方式組織數據，並支持高性能的數據訪問。每一個多維數據模型由多個多維數據模式表示，每一個多維數據模式都是由一個事實表和一組維表組成的。多維模型最常見的是星形模式。在星形模式中，事實表居中，多個維表呈輻射狀分布於其四周，並與事實表連接。在星型的基礎上，發展出雪花模式，下面就二者的特點做比較。 星型模式位於星形中心的實體是指標實體，是用戶最關心的基本實體和查詢活動的中心，為數據倉庫的查詢活動提供定量數據。每個指標實體代表一系列相關事實，完成一項指定的功能。位於星形圖星角上的實體是維度實體，其作用是限制用戶的查詢結果，將數據過濾使得從指標實體查詢返回較少的行，從而縮小訪問范圍。每個維表有自己的屬性，維表和事實表通過關鍵字相關聯。星形模式雖然是一個關系模型，但是它不是一個規范化的模型。在星形模式中，維度表被故意地非規范化了，這是星形模式與OLTP系統中的關系模式的基本區別。使用星形模式主要有兩方面的原因:提高查詢的效率。採用星形模式設計的數據倉庫的優點是由於數據的組織已經過預處理，主要數據都在龐大的事實表中,所以只要掃描事實表就可以進行查詢，而不必把多個龐大的表聯接起來，查詢訪問效率較高。同時由於維表一般都很小,甚至可以放在高速緩存中,與事實表作連接時其速度較快;便於用戶理解。對於非計算機專業的用戶而言，星形模式比較直觀，通過分析星形模式，很容易組合出各種查詢。總結：非正規化；多維數據集中的每一個維度都與事實表連接（通過主鍵和外鍵）；不存在漸變維度；有冗餘數據；查詢效率可能會比較高；不用過多考慮正規化因素，設計維護較為簡單。
雪花模式 在實際應用中，隨著事實表和維表的增加和變化，星形模式會產生多種衍生模式，包括星系模式、星座模式、二級維表和雪花模式。雪花模式是對星形模式維表的進一步層次化，將某些維表擴展成事實表，這樣既可以應付不同級別用戶的查詢，又可以將源數據通過層次間的聯系向上綜合，最大限度地減少數據存儲量，因而提高了查詢功能。雪花模式的維度表是基於範式理論的，因此是界於第三範式和星形模式之間的一種設計模式，通常是部分數據組織採用第三範式的規范結構，部分數據組織採用星形模式的事實表和維表結構。在某些情況下，雪花模式的形成是由於星形模式在組織數據時，為減少維表層次和處理多對多關系而對數據表進行規范化處理後形成的。雪花模式的優點是:在一定程度上減少了存儲空間;規范化的結構更容易更新和維護。同樣雪花模式也存在不少缺點:雪花模式比較復雜，用戶不容易理解;瀏覽內容相對困難;額外的連接將使查詢性能下降。在數據倉庫中，通常不推薦「雪花化」。因為在數據倉庫中，查詢性能相對OLTP系統來說更加被重視，而雪花模式會降低數據倉庫系統的性能。總結：正規化；數據冗餘少；有些數據需要連接才能獲取，可能效率較低；規范化操作較復雜，導致設計及後期維護復雜；實際應用中，可以採取上述兩種模型的混合體：如：中間層使用雪花結構以降低數據冗餘度，數據集市部分採用星型以方便數據提取及和分析。
有時候規范化和效率是一組矛盾。一般我們會採取犧牲空間（規范化）來換取好的性能，把盡可能多的維度信息存在一張「大表」裡面是最快的。通常會視情況而定，採取折中的策略。
星型有時會造成數據大量冗餘，並且很有可能將事實表變的及其臃腫（上百萬條數據×上百個維度）。
每次遇到需要更新維度成員的情況時，都必須連事實表也同時更新。
而雪花型，有時只需要更新雪花維度中的一層即可，無需更改龐大的事實表。
具體問題具體分析，如時間維度，年，季就沒必要做雪花，而涉及到產品和產品的分類，如果分類信息也是我們需要分析的信息，那麼，我肯定是建關於分類的查找表，也就是採用雪花模式

雪花型結構是一種正規化結構，他取除了數據倉庫中的冗餘數據。比如有一張銷售事實表，然後有一張產品維度表與之相連，然後有一張產品類別維度表與產品維度表連。這種結構就是雪花型結構。雪花型結構取除了數據冗餘，所以有些統計就需要做連接才能產生，所以效率不一定有星型架構高。正規化也是一種比較復雜的過程，相應資料庫結構設計、數據的ETL、以及後期的維護都要復雜一些。
星型架構是一種非正規化的結構，多維數據集中的每一個維度都與事實表相連接，不存在漸變維度，所以數據有一定的冗餘，正因為數據的冗餘所以很多統計查詢不需要做外部的連接所以一般情況下效率比雪花型要高。星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。
雖然兩種結構有一定差別，我個人認為沒有好壞之分，最主要的還是看項目的需求，看業務邏輯。

⑷ 數據倉庫的建模,很多公司都要用到這個，這個具體是用來做什麼的啊

數據倉庫模型的特點

對於傳統的OLTP系統，我們總是按照應用來建立它的模型，換言之，OLTP系統是面向應用的。而數據倉庫則一般按照主題 (Subject)來建模，它是面向主題的。何謂應用?何謂主題?讓我們來看一個簡單的例子。在銀行中，一般都有對私 (個人儲蓄)、對公 (企業儲蓄)、信用卡等多種業務系統，它們都是面向應用的，所支持的交易類型簡單而且固定。由於實施的先後等原因，這些系統可能運行在不同的平台上，相互之間沒有什麼關系，各系統之間的數據存在冗餘。比如每個系統中都會有客戶的數據，當針對銀行建立其數據倉庫應用時，要把上述生產系統中的數據轉換到數據倉庫中來。從整個銀行的角度來看，其數據模型不再面向個別應用，而是面向整個銀行的主題，比如客戶、產品、渠道等。因此，各個生產系統中與客戶、產品、渠道等相關的信息將分別轉換到數據倉庫中相應的主題中，從而在整個銀行的業務界面上提供一個一致的信息視圖。
數據倉庫的建模方法

邏輯建模是數據倉庫實施中的重要一環，因為它能直接反映出業務部門的需求，同時對系統的物理實施有著重要的指導作用。目前較常用的兩種建模方法是所謂的第三範式 (3NF，即 Third Normal Form)和星型模式 (Star-Schema)，我們將重點討論兩種方法的特點和它們在數據倉庫系統中的適用場合。

⑸ 數據倉庫有哪些模型舉例說明

1、星型模型
星型模型是一種由一點向外輻射的建模範例，中間有一單一對象沿半徑向外連接到多個對象。星型模型反映了最終用戶對商務查詢的看法:銷售事實、賠償、付款和貨物的托運都用一維或多維描述(按月、產品、地理位置)。星型模型中心的對象稱為「事實表」，與之相連的對象稱為「維表」。對事實表的查詢就是獲取指向維表的指針表，當對事實表的查詢與對維表的查詢結合在一起時，就可以檢索大量的信息。通過聯合，維表可以對查找標准細剖和聚集。
2、雪花模型
雪花模型是對星型模型的擴展，每一個點都沿半徑向外連接到多個點.雪花模型對星型的維表進一步標准化，它的優點是通過最大限度的減少數據存儲量以及把較小的標准化表(而不是大的非標准化表)聯合在一起來改善查詢性能。化及維的較低的粒度，雪花模型增加了應用程序的靈活性。
3、混合模型
混合模型是星型模型和雪花模型的一種折衷模式，其中星型模型由事實表和標准化的維表組成，雪花模型的所有維表都進行了標准化。在混合模型中，只有最大的維表才進行標准化，這些表一般包含一列列完全標准化的(重復的)數據。

⑹ 數據倉庫的數據模型

1. 星型模式

星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連接在事實表上，像星星一樣。星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：a. 維表只和事實表關聯，維表之間沒有關聯；b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連接的外鍵；c. 以事實表為核心，維表圍繞核心呈星形分布；

星座模型

⑺ 數據倉庫建模 etl 哪個方向好

這幾個職位都是跟數據有關的工作。
BI 是商業智能，職位包括etl,數據倉庫，數據展示工作。
數據倉庫，是按設定好的一種資料庫模型
ETL，負責清洗原始數據的一個過程，清洗完之後將數據載入至數據倉庫。
大數據開發，數據量較大，上千萬乃至億級的數據量開發

⑻ 初學者的數據倉庫建模以後在access里建表的問題~~各位大蝦幫忙啊~~

看在你給了5分的份上 第一個問題:時間必須單獨建表 產品單獨建 工廠 商城 也可以單獨建。但是你要注意，維度表單獨建是挺好，但是單獨建多了也不好 第二個問題和第三個問題是一個問題 事實表（數據倉庫）是根據事實表（這里的事實指業務資料庫）與維度聯系來的
先回答這些 不明白再問

⑼ 數據倉庫的建模劃分

數據倉庫的數據建模大致分為四個階段：
1.業務建模，這部分建模工作，主要包含以下幾個部分： 劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關系。 深入了解各個業務部門的內具體業務流程並將其程序化。 提出修改和改進業務部門工作流程的方法並程序化。 數據建模的范圍界定，整個數據倉庫項目的目標和階段劃分。 2.領域概念建模，這部分得建模工作，主要包含以下幾個部分： 抽取關鍵業務概念，並將之抽象化。 將業務概念分組，按照業務主線聚合類似的分組概念。 細化分組概念，理清分組概念內的業務流程並抽象化。 理清分組概念之間的關聯，形成完整的領域概念模型。 3.邏輯建模，這部分的建模工作，主要包含以下幾個部分： 業務概念實體化，並考慮其具體的屬性 事件實體化，並考慮其屬性內容 說明實體化，並考慮其屬性內容 4.物理建模，這部分得建模工作，主要包含以下幾個部分： 針對特定物理化平台，做出相應的技術調整 針對模型的性能考慮，對特定平台作出相應的調整 針對管理的需要，結合特定的平台，做出相應的調整 生成最後的執行腳本，並完善之。