A. 中心資料庫設計
5.2.2.1 資料庫
根據該系統的開發需求，按照資料庫的功能和作用將其分為風險查詢類、風險評價類、系統管理類三大類（薩師煊等，2000）。主要數據見表5.5。
表5.5 海外油氣與金屬礦產資源開發風險管理系統的主要數據表
續表
5.2.2.2 數據倉庫
油價數據來源於美國能源部（DOE）下屬的能源信息署（EIA）網站、中石油（CNPC）網站和《華爾街日報》（WSJ）網站提供的油價數據，油價序列本身就是一個不規則的時間序列，油價數據具有以下幾個特點。
（1）數據的一致性差
油價數據格式多樣，存在數據冗餘，主要體現在：使用的數據格式均不相同，並且各個子系統相對獨立。在網站單獨作用的情況下，一般都沒有問題，但要將這些不同系統或不同時期的數據集中起來綜合利用，就可能出現數據不齊全、不一致或重復的現象。
（2）數據存放的分散
油價數據來源多，缺乏統一管理，沒有一種相應的網頁數據自動化抓取操作實現數據的本地化操作過程。
（3）數據資源開發不充分
大容量數據導致對數據資源的開發利用不充分，缺乏對獲取的數據如各分析機構制定的期貨合約元數據進行各種深層次分析、綜合、提煉、挖掘和展現的應用，因此很難對豐富的統計數據資源進行二次開發利用。
根據油價數據中所包含的油氣產品種類、油氣產品合約制定日期、油氣產品的價格類型、不同市場下油氣產品價格的差異等，能夠加深對油價走勢的了解。油價的這種與時間相關性、不可修改性，以及集成的性質，使得我們採用多種角度對原始數據進行理解，並真實反映其特性，也讓我們發現使用一種整合的技術對油價進行精確預測十分必要。
數據倉庫的構建流程如圖5.13所示由下至上逐步實現。
圖5.13 數據倉庫構建流程
1）數據源。
A.數據源的復雜性。數據分散在資料庫管理系統、電子表格、電子郵件系統、電子文檔甚至紙上。系統中要求採集的3個數據源中，EIA 網站存儲在網頁上的油價相關事件更新較慢，雖然提供了各市場日、周、月、年的油價數據下載，但是下載完成之後的表格欄位格式時常發生變化，這為實現自動獲取數據並下載到本地自動入庫的要求增加了難度；中石油網站數據除上述只顯示3條數據之外，網站上會將訪問流量過大的IP地址列入黑名單使其不能繼續下載到本地進行保存，為這些數據建立統一的模型將會耗費很大精力。
B.數據的有效性。由於存在經驗局限，如何處理數據的空值、不同時間間隔時間欄位格式，入庫時應注意的問題等，如果應用程序沒有檢驗數據的有效性，會對數據多維顯示產生極大影響，因此也歸結為數據源數據質量問題。
C.數據的完整性。數據源上的數據並不那麼明顯或者容易獲得。油價是高度敏感的數據，因此各個網站雖然提供了各個油品交易市場的日、月或年數據，但是完整性並不能充分保證，根據企業政策的不同，有時對要獲得的數據，需花費大量精力。為此，要對不同的數據源進行建庫，以保證所獲數據的完整性。
2）數據處理。
高效的多維數據集展示離不開底層數據源數據的精確獲取，或者叫做數據理解和數據清洗。於是系統在基於元數據獲取、加工、入庫和多維數據集展示上實現預期的要求。
A.ETL。該功能是整個油價數據倉庫的核心之一，主要功能是按照事先定義的數據表對應關系從相關系統表中抽取數據（Extraction），經過數據清洗和轉換（Transform）,最終把正確的數據裝載到數據倉庫的源數據中（Load），作為以後應用的基礎。
B.數據轉換。該功能是在數據抽取過程中按照定義的規則轉換數據，避免了數據在分析時的多樣性，保證數據一致性。
C.數據集成。該功能主要是把油價信息數據倉庫系統的源數據，按照事先定義的計算邏輯以主題的方式重新整合數據，並以新的數據結構形式存儲。
3）數據存儲。
星型模型（星型架構）是數據倉庫開發中多維展現重要的邏輯結構，構成星型模型的幾個重要特徵是：維、度和屬性，在實際應用中表示為事實表和維度表。在油價數據中，各市場的期現貨價格表為數據倉庫的事實表，油品類型、合約規定日期等為維度表。
油價數據倉庫星型模型的設計方案如下：
A.事實表。資料庫表中EIA的期現貨價格表（包括日、周、月、年表）作為數據倉庫中的事實表，根據不同時間維度構成多個星型模型，即星座模型。這些價格表中以市場編號、油氣產品類型、期貨合約日期、價格單位度量衡編號作為主鍵和外鍵與其他維度表相連，形成多維展示聯動的基礎，以油價數據和其他事實數據為記錄數據，作為主要輸出結果。
B.維度表。根據市場、油品、價格數據、度量衡和事件類型作為油氣數據倉庫中多維分析的角度和目標。
圖5.14以EIA的日期貨數據表作事實表為例，構建星型模型，其他不同時間維度的模型結構圖與此圖基本相同。
圖5.14 以EIA數據為例的日期貨價格星型模型
以星型模型設計為基礎，完善數據存儲中操作型數據存儲（ODS）的原型設計，提供DB-DW之間中間層的數據環境，可實現操作型數據整合和各個系統之間的數據交換。
B. 什麼是數據倉庫 星型模式
（星形模式是一種多維的數據關系，它由一個事實表（Fact
Table）和一組維表（Dimension
Table）組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。事實表的非主鍵屬性稱為事實（Fact），它們一般都是數值或其他
可以進行計算的數據；而維大都是文字、時間等類型的數據，按這種方式組織好數據我們就可以按照不同的維（事實表主鍵的部分或全部）來對這些事實數據進行求
和（summary）、求平均（average）、計數（count）、百分比（percent）的聚集計算，甚至可以做20～80分析。這樣就可以從不
同的角度數字來分析業務主題的情況。）
在多維分析的商業智能解決方案中，根據事實表和維度表的關系，又可將常見的模型分為星型模型和雪花型模型。在設計邏輯型數據的模型的時候，就應考慮數據是按照星型模型還是雪花型模型進行組織。
當所有維表都直接連接到「 事實表」上時，整個圖解就像星星一樣，故將該模型稱為星型模型， 如圖 2 。
星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗餘，如在地域維度表中，存在國家
A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的信息分別存儲了兩次，即存在冗餘。
銷售數據倉庫中的星型模型
當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多
個雪花連接在一起，故稱雪花模型。雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 "
層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。如圖 2-3，將地域維表又分解為國家，省份，城市等維表。它的優點是 :
通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能。雪花型結構去除了數據冗餘
銷售數據倉庫中的雪花型模型
星型模型因為數據的冗餘所以很多統計查詢不需要做外部的連接，因此一般情況下效率比雪花型模型要高。星型結構不用考慮很多正規化的因素，設計與實現
都比較簡單。
雪花型模型由於去除了冗餘，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高。正規化也是一種比較復雜的過程，相應的資料庫結構設計、數
據的 ETL、以及後期的維護都要復雜一些。因此在冗餘可以接受的前提下，實際運用中星型模型使用更多，也更有效率。
C. 資料庫系統是層次形的，還是星形的，還是還是網狀的求告知
資料庫系統
的發展是經歷了好幾個階段，有層次型的，有網狀的，但現在用的最多的是
關系型資料庫
，即RDBMS(
關系型資料庫管理系統
)。其他類型的資料庫都用的比較少了。
另外，現在也不僅僅是資料庫了，還有
數據倉庫
等，如HBase。
D. 數據倉庫數據建模的幾種思路
數據倉庫數據建模的幾種思路主要分為一下幾種
1. 星型模式
星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連接在事實表上，像星星一樣。星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：a. 維表只和事實表關聯，維表之間沒有關聯；b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連接的外鍵；c. 以事實表為核心，維表圍繞核心呈星形分布；
星座模型
E. 數據倉庫的數據結構，到底是星型、雪花模型、還是三範式三範式和星型、雪花是什麼關系是不是包含他們
首先，你說的數據結構設計包括了兩種，一個是資料庫設計，一個是數據倉庫設計
針對資料庫設計一般用的是三範式。因為資料庫的數據會用於頻繁的增刪改查，因此出於減少系統壓力考慮，會盡量減少冗餘，從而提升系統頻繁讀寫數據的效率。
而星型、雪花型則是數據倉庫的設計模式。與資料庫的使用目的不同，數據倉庫更多的是存儲歷史數據，不會有頻繁的讀寫。其主要是用於從歷史數據中進行分析，進而獲取指導性的生產指引，生成報表等等。而這時資料庫設計中的範式拆表以提升效率的方法這時卻會適得其反（因為歷史數據的量相當龐大，而往往數據分析、BI等又需要從多個表中檢索數據來進行，這時大表之間的頻繁交互會使分析效率變得相當低，所以往往會考慮合並表的方法，故意製造冗餘）。
當然，以我個人的經驗，就算是資料庫設計，也很少會把表設計到三範式。因為一旦表的數據量變得龐大時，表與表之間交互的時間代價會比冗餘數據的代價大得多。
F. 數據倉庫建模，星型模型大致了解，就是事實表對應許多維表；對雪花型模型就不是很理解了
詳細和你說一下星型模型和雪花模型
星型模式 vs 雪花模型多維數據建模以直觀的方式組織數據，並支持高性能的數據訪問。每一個多維數據模型由多個多維數據模式表示，每一個多維數據模式都是由一個事實表和一組維表組成的。多維模型最常見的是星形模式。在星形模式中，事實表居中，多個維表呈輻射狀分布於其四周，並與事實表連接。在星型的基礎上，發展出雪花模式，下面就二者的特點做比較。 星型模式位於星形中心的實體是指標實體，是用戶最關心的基本實體和查詢活動的中心，為數據倉庫的查詢活動提供定量數據。每個指標實體代表一系列相關事實，完成一項指定的功能。位於星形圖星角上的實體是維度實體，其作用是限制用戶的查詢結果，將數據過濾使得從指標實體查詢返回較少的行，從而縮小訪問范圍。每個維表有自己的屬性，維表和事實表通過關鍵字相關聯。星形模式雖然是一個關系模型，但是它不是一個規范化的模型。在星形模式中，維度表被故意地非規范化了，這是星形模式與OLTP系統中的關系模式的基本區別。使用星形模式主要有兩方面的原因:提高查詢的效率。採用星形模式設計的數據倉庫的優點是由於數據的組織已經過預處理，主要數據都在龐大的事實表中,所以只要掃描事實表就可以進行查詢，而不必把多個龐大的表聯接起來，查詢訪問效率較高。同時由於維表一般都很小,甚至可以放在高速緩存中,與事實表作連接時其速度較快;便於用戶理解。對於非計算機專業的用戶而言，星形模式比較直觀，通過分析星形模式，很容易組合出各種查詢。總結：非正規化；多維數據集中的每一個維度都與事實表連接（通過主鍵和外鍵）；不存在漸變維度；有冗餘數據；查詢效率可能會比較高；不用過多考慮正規化因素，設計維護較為簡單。
雪花模式 在實際應用中，隨著事實表和維表的增加和變化，星形模式會產生多種衍生模式，包括星系模式、星座模式、二級維表和雪花模式。雪花模式是對星形模式維表的進一步層次化，將某些維表擴展成事實表，這樣既可以應付不同級別用戶的查詢，又可以將源數據通過層次間的聯系向上綜合，最大限度地減少數據存儲量，因而提高了查詢功能。雪花模式的維度表是基於範式理論的，因此是界於第三範式和星形模式之間的一種設計模式，通常是部分數據組織採用第三範式的規范結構，部分數據組織採用星形模式的事實表和維表結構。在某些情況下，雪花模式的形成是由於星形模式在組織數據時，為減少維表層次和處理多對多關系而對數據表進行規范化處理後形成的。雪花模式的優點是:在一定程度上減少了存儲空間;規范化的結構更容易更新和維護。同樣雪花模式也存在不少缺點:雪花模式比較復雜，用戶不容易理解;瀏覽內容相對困難;額外的連接將使查詢性能下降。在數據倉庫中，通常不推薦「雪花化」。因為在數據倉庫中，查詢性能相對OLTP系統來說更加被重視，而雪花模式會降低數據倉庫系統的性能。總結：正規化；數據冗餘少；有些數據需要連接才能獲取，可能效率較低；規范化操作較復雜，導致設計及後期維護復雜；實際應用中，可以採取上述兩種模型的混合體：如：中間層使用雪花結構以降低數據冗餘度，數據集市部分採用星型以方便數據提取及和分析。
有時候規范化和效率是一組矛盾。一般我們會採取犧牲空間（規范化）來換取好的性能，把盡可能多的維度信息存在一張「大表」裡面是最快的。通常會視情況而定，採取折中的策略。
星型有時會造成數據大量冗餘，並且很有可能將事實表變的及其臃腫（上百萬條數據×上百個維度）。
每次遇到需要更新維度成員的情況時，都必須連事實表也同時更新。
而雪花型，有時只需要更新雪花維度中的一層即可，無需更改龐大的事實表。
具體問題具體分析，如時間維度，年，季就沒必要做雪花，而涉及到產品和產品的分類，如果分類信息也是我們需要分析的信息，那麼，我肯定是建關於分類的查找表，也就是採用雪花模式
雪花型結構是一種正規化結構，他取除了數據倉庫中的冗餘數據。比如有一張銷售事實表，然後有一張產品維度表與之相連，然後有一張產品類別維度表與產品維度表連。這種結構就是雪花型結構。雪花型結構取除了數據冗餘，所以有些統計就需要做連接才能產生，所以效率不一定有星型架構高。正規化也是一種比較復雜的過程，相應資料庫結構設計、數據的ETL、以及後期的維護都要復雜一些。
星型架構是一種非正規化的結構，多維數據集中的每一個維度都與事實表相連接，不存在漸變維度，所以數據有一定的冗餘，正因為數據的冗餘所以很多統計查詢不需要做外部的連接所以一般情況下效率比雪花型要高。星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。
雖然兩種結構有一定差別，我個人認為沒有好壞之分，最主要的還是看項目的需求，看業務邏輯。
G. 請問數據倉庫都用什麼建立
數據倉庫是為了管理數據，主要是思想。
具體實施的工具就是為了解決問題而選取了
比如異構/不同源數據的數據抽取問題，要用到etl，可能會用工具 或者自己寫程序，看情況而定『
數據倉庫的模型建設，要用到erwin等建模工具；
數據的存放一般是藉助關系資料庫來實現，那麼會用到oracle之類。不過現在已經開始慢慢摒棄傳統關系資料庫了，藉助一些No sql平台，比如hadoop上的hive之類。
不過無論用什麼工具，一定要記住，數據倉庫的思想是不變的，就是管理數據、把數據的價值通過有效地管理而展現出來，不經管理的數據就是一堆沒有提煉的金礦，看著很值錢，直接狗屁用沒有。
H. 數據倉庫的數據模型
有別於一般聯機交易處理(OLTP)系統，數據模型設計是一個數據倉庫設計的地基，當前兩大主流理論分別為採用正規方式(normalized approach)或多維方式(dimensional approach)進行數據模型設計。 數據模型可以分為邏輯與實體數據模型。邏輯數據模型陳述業務相關數據的關系，基本上是一種與資料庫無關的結構設計，通常均會採用正規方式設計，主要精神是從企業業務領域的角度及高度訂出subject area model，再逐步向下深入到entities、attributes，在設計時不會考慮未來採用的資料庫管理系統，也不需考慮分析性能問題。而實體數據模型則與資料庫管理系統有關，是建置在該系統上的數據架構，故設計時需考慮數據類型(data type)、空間及性能相關的議題。 實體數據模型設計，則較多有採用正規方式或多維方式的討論，但從實務上來說，不執著於理論，能與業務需要有最好的搭配，才是企業在建置數據倉庫時的正確考量。
數據倉庫的建制不僅是資訊工具技術面的運用，在規劃和執行方面更需對產業知識、行銷管理、市場定位、策略規劃等相關業務有深入的了解，才能真正發揮數據倉庫以及後續分析工具的價值，提升組織競爭力。