最新国产亚洲免费在线视频,日本色情在线视频,免费的色情视频,99国产精品一区二区,向井蓝无码精品一区二区,成人性生交A片免费看游戏,国产在线视频你懂的,欧美一级性爱在线观看

1.數(shù)倉建模的理由

數(shù)據(jù)建模的主要目的是降低成本，提高數(shù)據(jù)的利用效率。尤其是大數(shù)據(jù)時代的到來，數(shù)據(jù)的多樣化，巨量，更需要有效的有針對性數(shù)據(jù)建模方法。

大數(shù)據(jù)的數(shù)倉建模正是通過建模的方法，更好的組織、存儲數(shù)據(jù)，以便在性能、成本、效率和數(shù)據(jù)質(zhì)量之間找到最佳平衡點，一般我們會從以下面四點考慮：

性能：能夠快速查詢所需的數(shù)據(jù)，減少數(shù)據(jù)I/O的吞吐。
成本：減少不必要的數(shù)據(jù)冗余，實現(xiàn)計算結果的復用，降低大數(shù)據(jù)系統(tǒng)中的存儲成本和計算成本。
效率：改善用使用數(shù)據(jù)的體驗，提高使用效率。
質(zhì)量：改善數(shù)據(jù)統(tǒng)計口徑的不一致性，減少數(shù)據(jù)計算錯誤的可能性，提供高質(zhì)量的、一致的數(shù)據(jù)訪問平臺。

因此，毋庸置疑，大數(shù)據(jù)系統(tǒng)、數(shù)據(jù)平臺都需要數(shù)據(jù)模型方法來幫助更好的組織和存儲數(shù)據(jù)，數(shù)據(jù)建模的工作，也正是圍繞上述四個指標取得最佳的平衡而努力。

2.數(shù)據(jù)建模的方法

數(shù)據(jù)倉庫本質(zhì)是從數(shù)據(jù)庫衍生出來的，所以數(shù)據(jù)倉庫的建模也是不斷衍生發(fā)展的。

從最早的借鑒關系型數(shù)據(jù)庫理論的范式建模，到逐漸提出維度建模等等，越往后建模的要求越高，越需滿足3NF、4NF等。但是對于數(shù)據(jù)倉庫來說，目前主流還是維度建模，會夾雜著范式建模。

數(shù)據(jù)倉庫建模方法論可分為：E-R模型、維度模型、Data Vault模型、Anchor模型。

2.1 E-R模型

1). 簡介

ER模型，全稱為實體聯(lián)系模型、實體關系模型或?qū)嶓w聯(lián)系模式圖（ERD）（英語：Entity-relationship model）由美籍華裔計算機科學家陳品山發(fā)明，是概念數(shù)據(jù)模型的高層描述所使用的數(shù)據(jù)模型或模式圖。

ER模型常用于OLTP數(shù)據(jù)庫建模，應用到構建數(shù)倉時更偏重數(shù)據(jù)整合，站在企業(yè)整體考慮，將各個系統(tǒng)的數(shù)據(jù)按相似性一致性、合并處理，為數(shù)據(jù)分析、決策服務，但并不便于直接用來支持分析。缺陷：需要全面梳理企業(yè)所有的業(yè)務和數(shù)據(jù)流，周期長，人員要求高。

ER模型分為實體、屬性、關系三個核心部分。實體是長方形體現(xiàn)，而屬性則是橢圓形，關系為菱形。

ER模型的實體（entity）即數(shù)據(jù)模型中的數(shù)據(jù)對象，例如人、學生、音樂都可以作為一個數(shù)據(jù)對象，用長方體來表示，每個實體都有自己的實體成員（entity member）或者說實體對象（entity instance），例如學生實體里包括張三、李四等，實體成員（entity member）/實體實例（entity instance）不需要出現(xiàn)在ER圖中。

ER模型的屬性（attribute）即數(shù)據(jù)對象所具有的屬性，例如學生具有姓名、學號、年級等屬性，用橢圓形表示，屬性分為唯一屬性（ unique attribute）和非唯一屬性，唯一屬性指的是唯一可用來標識該實體實例或者成員的屬性，用下劃線表示，一般來講實體都至少有一個唯一屬性。

ER模型的關系（relationship）用來表現(xiàn)數(shù)據(jù)對象與數(shù)據(jù)對象之間的聯(lián)系，例如學生的實體和成績表的實體之間有一定的聯(lián)系，每個學生都有自己的成績表，這就是一種關系，關系用菱形來表示。

ER模型中關聯(lián)關系有三種：

1對1（1:1）：1對1關系是指對于實體集A與實體集B，A中的每一個實體至多與B中一個實體有關系；反之，在實體集B中的每個實體至多與實體集A中一個實體有關系。

1對多（1:N）：1對多關系是指實體集A與實體集B中至少有N(N>0)個實體有關系；并且實體集B中每一個實體至多與實體集A中一個實體有關系。

多對多（M:N）：多對多關系是指實體集A中的每一個實體與實體集B中至少有M(M>0)個實體有關系，并且實體集B中的每一個實體與實體集A中的至少N（N>0）個實體有關系。

舉一個簡單的例子：

2). ER實體詳解

ER的實體還可以分為弱實體和復合實體：

弱實體：一個實體必須依賴于另一個實體存在，那么前者是弱實體，后者是強實體，弱實體必須依賴強實體存在，例如上圖的學生實體和成績單實體，成績單依賴于學生實體而存在，因此學生是強實體，而成績單是弱實體。

弱實體和強實體的聯(lián)系必然只有1:N或者1:1，這是由于弱實體完全依賴于強實體，強實體不存在，那么弱實體就不存在，所以弱實體是完全參與聯(lián)系的，因此弱實體和強實體之間的聯(lián)系也是用的雙線菱形。

根據(jù)弱實體的描述，修改上面的實例：

復合實體：復合實體也稱為聯(lián)合實體或者橋接實體，常常用于實現(xiàn)兩個或者多個實體間的M:N關系，它由每個關聯(lián)實體的主體組成，用長方體內(nèi)加一個菱形來表示。

下圖就是一個典型的復合實體，因為只是舉例，相對粗糙，用戶和商品兩個實體是M:N的關系，中間又訂單這個實體聯(lián)系，因此訂單這個實體是一個復合實體，同時如果用戶實體不存在，就沒有訂單實體存在，因此對于用戶實體來說訂單是弱實體，同理商品實體如果不存在，同樣不存在訂單實體，因此對商品實體而言訂單是弱實體，具體如下：

2). ER屬性補充講解：

er圖的屬性還細分為復合屬性、多值屬性和派生屬性、可選屬性，同時還有用來表示聯(lián)系的屬性，稱為聯(lián)系屬性。

復合屬性(composite attribute)：復合屬性是指具有多個屬性的組合，例如名字屬性，它可以包含姓氏屬性和名字屬性，如下圖：

復合屬性也有唯一屬性，例如學生的所在班級屬性，由于多個年級都有班級，所以單單班級屬性是不唯一的，但是和年級組成的復合屬性后則可以匹配成唯一屬性。

多值屬性（multivalued attribute）：一個實體的某個屬性可以有多個不同的取值，例如一本書的分類屬性，這本書有多個分類，例如科學、醫(yī)學等，這個分類就是多值屬性，用雙線橢圓表示。

派生屬性(derivers attribute)：是非永久性存于數(shù)據(jù)庫的屬性。派生屬性的值可以從別的屬性值或其他數(shù)據(jù)（如當前日期）派生出來，用虛線橢圓表示，如下圖。

下面的社團人數(shù)就是典型的派生屬性，隨著學生實例的參加的社團變化，社團人數(shù)屬性也會變化，一般來講派生屬性不存在于數(shù)據(jù)庫中，而是通過相應的公式進行計算得到，如果要放到數(shù)據(jù)庫中，那么隔一段時間就要進行更新，否則會出現(xiàn)數(shù)據(jù)錯誤。

可選屬性(optional attribute)：并不是所有的屬性都必須有值，有些屬性的可以沒有值，這就是可選屬性，在橢圓的文字后用（O）來表示，如下圖的地址就是一個可選屬性。

關系屬性：關系屬于用戶表示多個實體之間關系所具有的屬性，一般來講M:N的兩個實體的關系具有關系屬性，在1:1和1：M的實體關系中關系屬性并不必要。

ER實體關系模型案例

假設在電商購物系統(tǒng)中，對商品、用戶設計ER實體關系模型圖來表示商品信息、用戶購買商品之間的業(yè)務聯(lián)系，完成數(shù)據(jù)庫邏輯模型設計。

設計ER實體關系模型圖，步驟如下：

1. 抽象出實體

2. 找出實體之間的關系

3. 找出實體的屬性

4. 畫出E-R關系圖

轉(zhuǎn)化為傳統(tǒng)數(shù)據(jù)庫表：

所以，ER模型完全可以使用圖數(shù)據(jù)庫代替。

2.2 維度建模

1). 維度建模簡介

維度模型是數(shù)據(jù)倉庫領域大師Ralph Kimall所倡導，他的《數(shù)據(jù)倉庫工具箱》，是數(shù)據(jù)倉庫工程領域最流行的數(shù)倉建模經(jīng)典。維度建模以分析決策的需求出發(fā)構建模型，構建的數(shù)據(jù)模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規(guī)模復雜查詢的響應性能。

維度建模是專門應用于分析型數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市建模的方法。數(shù)據(jù)集市可以理解為是一種"小型數(shù)據(jù)倉庫"。

維度建模的概念是比較少的，下面簡單介紹一下。

2).事實表

發(fā)生在現(xiàn)實世界中的操作型事件，其所產(chǎn)生的可度量數(shù)值，存儲在事實表中。從最低的粒度級別來看，事實表每一行都對應于一個度量事件，反之亦然。

事實表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個事實。

圖中的訂單表就是一個事實表，可以理解他就是在現(xiàn)實中發(fā)生的一次操作型事件，每完成一個訂單，就會在訂單中增加一條記錄。

事實表的特征：表里沒有存放實際的內(nèi)容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯(lián)的外鍵，可與維度表關聯(lián)。事實表的度量通常是數(shù)值類型(條/個/次)，且記錄數(shù)會不斷增加，表數(shù)據(jù)規(guī)模迅速增長。

3).維度表

維度表示要對數(shù)據(jù)進行分析時所用的一個量，比如你要分析產(chǎn)品銷售情況，你可以選擇按類別進行分析，或按區(qū)域分析。這區(qū)域，類別就分別就構成一個維度。上圖中的用戶表，商家表，時間表這些都屬于維度表。這些表都有一個唯一的主鍵，然后在表中存放了詳細的數(shù)據(jù)信息。

例如：交易金額分析

男性用戶的訂單金額、聯(lián)想商品的訂單金額、第一季度的訂單金額、收集的訂單金額、家里下單的訂單金額。

維度表的特征：每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯(lián)的任何事實表的外鍵，當然維度表行的描述環(huán)境應與事實表行完全對應。維度表通常比較寬，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性。

總得來說，在數(shù)據(jù)倉庫中不需要嚴格遵守規(guī)范化設計原則。因為數(shù)據(jù)倉庫的主導功能就是面向分析的，以查詢?yōu)橹鳎簧婕皵?shù)據(jù)更新操作。

需要強調(diào)的是：

事實表的設計是以能夠正確記錄歷史信息為準則。

維度表的設計是以能夠以適合的角度來聚合主題內(nèi)容為準則。

4).維度模型

a.星型模型

星型模型(star schema)是最常用的維度建模方式。星型模型是以事實表為中心，所有的維度表直接連接在事實表上，像星星一樣。

星型模型的維度建模是由一個事實表和一組維表組成，且具備以下特點：

維表只和事實表關聯(lián)，維表之間沒有關聯(lián)；
每個維表主鍵為單例，且該主鍵放置在事實表中，作為兩邊連接的外鍵；
以事實表為核心，維度表圍繞核心呈星型分布；

b.雪花模型

雪花模型(snowflake schema)是對星型模型的擴展。雪花模型的維表可以擁有其他維度表，雖然這種模型相比星型更加規(guī)范一些，但是由于這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯(lián)多層維表，性能也比星型模型要低。所以一般不是很常用。

c.星座模型

星座模型是星型模型延伸而來，星型模型是基于一張事實表的，而星座模型是基于多張事實表的，而且共享維度信息。前面的兩種維度建模方法都是多維表對應于單事實表，但是在很多時候維度空間內(nèi)的事實表不止一個，而一個維表也可能被多個事實表用到。在業(yè)務發(fā)展的后期，絕大部分維度建模都采樣這種星座模式。

5). 維度變化

你的應用必須反映出移植到倉庫中的數(shù)據(jù)源所發(fā)生的數(shù)據(jù)變化。維表中的數(shù)據(jù)特別容易變化。但你怎么維護記錄的歷史變化呢?

第一個也是最簡單的方法是重寫現(xiàn)有的記錄而不跟蹤變動。幸運的是，這個方法被許多維度所接受。例如，如果一個部門名稱從“財務”變?yōu)椤柏攧蘸蜁嫛保愫芸赡懿⒉恍枰涗涍@種歷史變化。但是，從客戶和學生的角度看，常常有必要保持跟蹤姓名、婚姻狀態(tài)、教育程度和其它屬性的變化——你的應用必要能夠獲得當前的以及歷史的數(shù)值。拉鏈表最常用。
管理維度慢慢改變的第二個方法是數(shù)值發(fā)生變化時創(chuàng)建一個新的記錄，并將舊的記錄標記為舊記錄。
第三個也是最后的一個方法是維護在維表的同一行中不同列的變化域的歷史數(shù)值。

6). 事實變化。

通常人們認為事實表中的記錄是靜態(tài)的——一旦這條記錄錄入到了倉庫中你的工作就結束了，是嗎?不幸的是這個回答是“它取決于。”在某些情況下像在一個數(shù)據(jù)倉庫跟蹤病人的住院情況，所有的記錄通常都是靜態(tài)的。如果你從1月1日到2月5日住院，那這條記錄不太可能改變。

但是考慮到零售行業(yè)，所有的銷售都不是最終的——我肯定你知道有些人經(jīng)常將它們購買的貨物因為各種原因而退回商店。一些公司管理這種交易為一系列信用和負債來結算每筆交易。但在其它的情況下你必須更新或刪除事實表記錄，甚至在它們添加到了數(shù)據(jù)倉庫之后。例如，如果一個股票交易記錄不正確，用一個相反的交易來結算是不能接受的。還有另一個問題要考慮：你可能不希望你的客戶知道你的交易系統(tǒng)中存在的問題。甚至你希望他們只在數(shù)據(jù)被修正后才看到數(shù)據(jù)。

處理方法一:

將數(shù)據(jù)放在暫存區(qū)域直到它經(jīng)過了質(zhì)量檢查，然后將其移植到倉庫中。然而有時甚至是最全面的測試也無法捕獲數(shù)據(jù)源中的所有錯誤，你可能需要通過處理這些包含錯誤數(shù)據(jù)的部分來更新多維數(shù)據(jù)集。這就是為什么有必要保持你的分析服務部分盡可能的小以便處理可以相對快一些。

處理方法二：

采用一個回寫分區(qū)。采用多維數(shù)據(jù)集回寫，你沒有真的改變關系數(shù)據(jù)倉庫中的數(shù)據(jù);而是在一個單獨的分區(qū)中添加了一條記錄。當用戶查詢一個特殊的測量值組時，分析服務將只讀分區(qū)的數(shù)據(jù)和回寫分區(qū)的數(shù)據(jù)結合起來，然后顯示結果。當然，執(zhí)行這樣的查詢計算會額外增加分析服務器的執(zhí)行時間，并會造成性能下降。

2.3 Data Vault建模

Data Vault是一種由Dan Linstedt提出的數(shù)據(jù)倉庫建模方法，主要應用于企業(yè)級數(shù)據(jù)倉庫建模。

不同于三范式數(shù)據(jù)倉庫模型、維度模型，Data Vault模型主要用于存儲來自多個業(yè)務系統(tǒng)的完整歷史數(shù)據(jù)。它不區(qū)分數(shù)據(jù)在業(yè)務層面的準確與否，裝在數(shù)據(jù)也不做驗證和清洗，因此，Data Vault模型可用于跟蹤所有數(shù)據(jù)的來源。

它的每一行數(shù)據(jù)都需要包含來源系統(tǒng)和裝在時間，用于審計和跟蹤數(shù)據(jù)來源系統(tǒng)。

2.3.1 Data Vault模型定義

按照Dan Linstedt的定義，Data Vault模型是面向細節(jié)的、可追蹤歷史的、一組有鏈接關系的規(guī)范化的表的集合。它綜合了三范式建模和星型模型的優(yōu)點，其設計理念是滿足企業(yè)對數(shù)據(jù)模型靈活性、可擴展性、一致性和對需求的適應性要求，是專門針對企業(yè)級數(shù)據(jù)倉庫需要的一套建模方法。

Data Vault模型只按照業(yè)務數(shù)據(jù)的原始狀態(tài)存儲數(shù)據(jù)，不做任何過濾、清洗、轉(zhuǎn)換，比如：同一個客戶在不同系統(tǒng)有不同地址，Data Vault模型會存儲多個不同版本的客戶地址數(shù)據(jù)。

該模型的主要特點：

與源系統(tǒng)完成獨立。
所有數(shù)據(jù)基于時間戳，即便數(shù)據(jù)質(zhì)量很低，也不能清洗掉數(shù)據(jù)。
可以適應源數(shù)據(jù)的各種變化，并可以靈活的實現(xiàn)模型擴展。
數(shù)據(jù)的來源可以完全追蹤，并且數(shù)據(jù)處理作業(yè)可以支持重載。

2.3.2 Data Vault模型體系

Data Vault模型由中心表(hub)、鏈接表(link)、附屬表(satellite)三部分組成，其核心是中心表，用于存儲業(yè)務主鍵，鏈接表用于存儲業(yè)務關系，附屬表用于存儲業(yè)務描述。

a. 中心表

中心表用于存儲企業(yè)每個業(yè)務實體的業(yè)務主鍵，業(yè)務主鍵需要能夠唯一標識一個業(yè)務實體。按照此定義，中心表與源系統(tǒng)無關，即無論業(yè)務主鍵是否用于多個業(yè)務系統(tǒng)，其在Data Vault模型中也只有一份數(shù)據(jù)。處于設計上的考慮，中心表一般由主鍵，業(yè)務主鍵，裝載時間戳，數(shù)據(jù)來源系統(tǒng)四個字段構成，其中主鍵根據(jù)業(yè)務主鍵唯一分配，一般是與業(yè)務無關的序列數(shù)值。

b. link表

鏈接表是不同中心表之間的關系鏈接，鏈接表一般由一組外鍵字段構成，表示一種業(yè)務關系，比如：交易表、客戶關聯(lián)賬戶等。鏈接表主要包括主鍵、外鍵1、...、外鍵n、裝載時間戳、數(shù)據(jù)來源等字段構成，其中主鍵對應多個外鍵的唯一組合，一般是與業(yè)務無關的序列數(shù)值。

c. satellite表

附屬表用于保存中心表和鏈接表的描述屬性，包含了所有歷史變化數(shù)據(jù)，附屬表有且僅有一個唯一外鍵關聯(lián)到中心表或者鏈接表。附屬表主要包括主鍵、外鍵、屬性1、 ... 、屬性n 、是否失效、失效時間戳、裝載時間戳、數(shù)據(jù)來源系統(tǒng)，主鍵用于唯一標識附屬表中的一行記錄，一般是與業(yè)務無關的序列數(shù)值。

2.3.3 Data Vault 模型設計

根據(jù)Data Vault模型體系構成，Data Vault模型設計也由此分為三大部分。

a.中心表設計

1) 明確模型需要覆蓋的業(yè)務范圍。

2) 按業(yè)務范圍劃分若干原子業(yè)務實體，比如：客戶、產(chǎn)品、投資品種等。

3) 從業(yè)務實體中抽象業(yè)務主鍵，業(yè)務主鍵必須是可唯一標識業(yè)務實體且不會發(fā)生變化。

4) 按照業(yè)務主鍵生成中心表。

b. 鏈接表設計

1) 分析業(yè)務實體間的業(yè)務關系，并識別對應的中心表，這些業(yè)務關系可以是一對一、一對多、多對多多種關系。

2) 按業(yè)務關系涉及的中心表，提取中心表主鍵，組成構成鏈接表的外鍵，并確定鏈接表的主鍵。

說明：鏈接表內(nèi)可以保存交易數(shù)據(jù)，也可以用附屬表描述交易數(shù)據(jù)。

c. 附屬表設計

附屬表的設計相對比較簡單，主要是從中心表、鏈接表出發(fā)，提取與中心表、鏈接表相關的上下文描述信息。由于同一業(yè)務實體的各類描述信息可能會經(jīng)常變化、變化頻率也不盡相同，因此需要按變化頻率將不同屬性信息分割，建立多個附屬表。

為了訪問數(shù)據(jù)的方便，可能需要設計PIT表，PIT表不是必須的，但是如果一個中心表有多個附屬表，就有可能用到PIT表。PIT表的主鍵是有附屬表關聯(lián)的中心表提取而來，有幾個附屬表就會有幾個字段用于記錄附屬表的變化時間戳。

Data Vault案例

2.4 Anchor模型

Anchor模型是Data Vault模型的進一步規(guī)范化，核心思想是所有的擴展只是添加而不會修改，因此將模型規(guī)范到6NF，基本變成了k-v結構化模型。
我們看一下Anchor模型的組成。
1.Anchors：類型于Data Vault的Hub，代表業(yè)務實體，且只有主鍵。
2.Attributes：功能類型于Data Vault的Satellite，但是它更加規(guī)范化，將其全部k-v結構化，一個表只有一個Anchors的屬性描述。
3.Ties：就是Anchors之間的關系，單獨用表來描述，類似于Data Vault的Link，可以提升整體模型關系的擴展能力。
4.Knots：代表那些可能會在多個Anchors中公用的屬性的提煉，比如性別、狀態(tài)等這種枚舉類型且被公用的屬性。

數(shù)倉建模方法論