DW2.0–在開發過程中,業務模型和資料模型的角色及作用

來源:互聯網
上載者:User

DW2.0包含的內容是非常寬泛的。它包括企業內的所有資料,也包括外部資料;它包括昨天的資料,也包括今天的資料。在一些大型跨國企業中,DW2.0包含內容的範圍是相當龐大的。

而且,DW2.0中的資料還要儲存到非常細的粒度。

這樣,為了滿足企業的各種需求,就使得DW2.0的設計和構建變得非常複雜,需要高深的技術。

儘管DW2.0的設計面對的是如此的困難和挑戰,事實上它是可以被很好的完成的。這需要在DW2.0的構建過程中很好的平衡大的企業的視角和瑣碎的細節之間的關係。

那麼,這樣的一個DW2.0環境的構建模型是如何來實現的呢?在建立這樣一個大的模型時,設計者應該從什麼地方入手呢?

構建DW2.0的入手點應該是建模的過程。在構建DW2.0時有兩種基本的模型,一種是業務處理過程模型(Process Model),另一種是資料模型(Data Model)。業務處理過程模型包括HIPO圖表、功能分解圖和資料流向圖等內容。資料模型包括ERD圖、物理資料規劃,資料項目集等內容。

業務處理過程模型應用於資料集市環境。資料模型應用於整合區、近線區和歸檔區。

互動區的設計需要同時參考業務處理過程模型和資料模型。

資料模型

資料模型是DW2.0中整合區、近線區和歸檔區的核心,它有三個不同的層級。這三個層級分別是ERD層級(Entity Relationship Diagram,實體關聯圖),DIS層級(Data Item Set,資料項目集)和物理模型層級(Physical Model)。其中的每一個層級都有自己獨特的地方,並且每一個層級都是資料模型的必要部分。

這種針對不同層級的建模有一個很大的特點,就是雖然各個層級有顯著的區別,但是它們之間無論從技術上還是知識上都是相互關聯的。每一個層級的建模都提供了資料的不同層次的視角。

ERD層級的資料建模的是最高的層級,反映的也是最高視角的資料特點,它是資料的高度抽象。做一個類比,ERD層級就好比一個地球儀。就像地球儀展示了所有的大陸和所有的國家及其位置關係一樣,ERD展示了各個資料集合之間的關係。ERD資料模型的本質是高度抽象的模型的全集。

DIS層級是中等層級的建模,DIS模型好比地球上某一個國家或者國家內某一個州的地圖,例如德克薩斯州的地圖,人們不會期望這張地圖能提供新加坡或者非洲的周邊情況。這張地圖比地球儀要細節得多,在州地圖上記錄著一些在地球儀上根本看不到的城市。DIS關注的是地球儀的某一個子集,並且包含地球儀上沒有的更詳細的資訊。

物理模型是低層級的建模,也是最細節的建模。物理模型好比一個城市的地圖,它的範圍比DIS和ERD要小。從另一個角度講,物理模型的細節程度要比另兩個層級細,物理模型可以記錄如郵局、學校、公園等的位置。城市地圖包含的範圍比州地圖要小,但是包含了更多的細節資訊。

這三個層級的資料建模之間有著密切的關係。

ERD模型

ERD模型包括兩個主要的部分,一個是實體,或者說是企業的主題域,另一個是這些主題域之間的關聯。

實體是資料的最進階別的抽象。作為最進階別抽象的一個例子,我們來考慮一個實體,客戶實體。客戶實體可以包括企業客戶,也可以包括個人客戶,它可以包括以前的客戶,也可以包括潛在的客戶等等。總之,各種類型的、各種狀態的客戶都被高度抽象成一個客戶實體。

實體之間的關聯也包含在ERD中。關係(Relationship)用來標識這種實體間的關聯,通常,需要給這種關聯加上一個簡短的描述資訊。

舉幾個實體間關係的例子,如客戶可能會下一個訂單、發貨人可能會接受一個包裹、一個訂單可能會包含一個產品等等。

關係的一個特點是關係直接關聯兩個實體,一個關係不可能關聯三個或者更多的實體。

一個特殊類型的關係是遞迴。遞迴關係描述的是發生在兩個相同實體上的關係。遞迴關係的一個簡單的例子是,父親和女兒的關係。父親和女兒都是屬於同一個實體的,這個實體就是人。所以在人這個實體上就會建立遞迴的關係。

正因為ERD建立在這麼高度抽象的層級上,一般企業內建立的ERD不會很大。在企業建立其他資料模型前,應該首先建立好ERD模型。

DIS模型

DIS模型是資料模型中位於中間層級的一部分。在DIS模型中,屬性和鍵以及其他資料和關係被標識出來。

ERD模型中的每一個實體(或者主題域)對應一個DIS模型。DIS模型細化了ERD模型的每一個實體。

對應於DIS中的每一部分有一個不同的物理資料模型。

每一個DW2.0的開發人員都面對著一個問題,就是在開始開發DW2.0的時候,全部的詳細的資料模型是否應該先建立完全。答案是不需要。如果要等到所有的資料模型都建立完全才開始進行資料倉儲的開發,那麼就不會有資料倉儲被建立出來了。資料倉儲的建立方式是一種漸進式開發的模式。首先建立資料倉儲的一部分,接著建立另一部分。

舉例來說,首先完整的ERD模型需要建立好,然後建立ERD模型中某一個實體的DIS模型,然後建立該DIS模型的物理資料模型。這時,ERD資料模型中的其他實體對應的資料模型還沒有建立。儘管大部分資料模型還沒有建立,但是針對建立好的這部分模型可以先進行開發。

接著,再逐步建立針對其他實體的DIS模型和物理資料模型。

接著再建立下一個。

隨著這種逐步的迭代過程,整個資料倉儲被建立起來,完整的資料模型也被建立起來。

這種迭代式建立資料倉儲的過程可能會經過很多次迭代,由很多重專案共同完成。

從某種觀點來看,企業完整的資料模型就好像一個拼圖,一次放入一塊,最終可以拼成一個完整的圖案。

這裡有另一個問題,上一章建立方法學中提到正因為迭代是採用的同一個資料模型所以才可以將每次迭代的結果整合在一起,這一章又說不需要建立好全部的資料模型,經過多次迭代的過程逐步建立好完整的資料模型,這看起來是矛盾的。

我的理解是,前一章提到的採用的同一個資料模型指的是ERD模型,Inmon的ERD講的主題領域模型,也就是常說的資料倉儲是按主題建立的那個主題的意思。這個模型是高度抽象的資料模型,這個模型應該在資料倉儲開始開發時建立好,它是企業完整的資料模型的基礎,DIS和物理資料模型是ERD的細化。

而這一章中講的不需要完整的資料模型的意思是建立資料倉儲時不需要將針對所有主題的DIS和物理資料模型都建立好,但是ERD模型是應該先建立好。Inmon這裡提到的物理資料模型應該和我們常說的物理資料模型在範圍上不太一樣,這裡的物理資料模型應該對應的是一個表及其相關的物理特性,我們常說的物理資料模型是針對一個項目的全部表的物理模型。

總之,企業的ERD模型即主題領域模型應該在建立資料倉儲的開始時先建立好,在這個ERD模型的基礎上,可以逐步開發針對不同主題的DIS和物理資料模型。

資料模型的來源

企業的資料模型應該如何來建立?有一種方法是根據企業的情況採用客戶化定製的方式來設計出來。這種從頭設計企業的資料模型的方法是昂貴的,它需要很長的時間。這種做法通常也是沒必要的。

我們可以考慮,兩個保險公司的資料模型基本上是相同的,兩個銀行的資料模型基本上也是相同的,兩個製造業的資料模型也很相似。也就是說,同一個行業內的資料模型是相似的。

所以如果已經有幾個銀行已經建立了自己的資料模型的話,我們為什麼還要去重新發明車輪呢。為什麼不和他們合作呢,完全可以參考他們已經建立好的資料模型。實際中,可以買也可以租他們的資料模型,再根據自己企業的需要來修改、增減。在一個通用的資料模型的基礎上建立企業資料模型比自己從頭設計要快很多,花費也要節省很多,尤其是當這個行業的資料模型已經比較成熟時。

如果你找不到另一個企業願意和你共用資料模型,有互連網或者書籍中兩個地方可以提供資料模型。第一個地方是一個互連網站,上面有免費的資料模型,這個網站是http://www.inmoncif.com。另一個地方是Len Silverson的書,他的書講的是通用資料模型,可以在Amazon.com買到。當然還有其他很多地方可以找到通用資料模型。

Len Silverson的書名是《The Data Model Resource Book》,共有兩本,這兩本書已經被翻譯成中文了,書名是《資料模型資源手冊》,網上有第一本的英文版可以下載,第二本的英文版還沒看到。

當得到或者考慮採用通用資料模型時,需要注意的是通用資料模型對我們來說並不是完善的資料模型。不管通用資料模型是多麼完整、多麼複雜,我們在使用時都需要根據企業的實際情況來對它進行修改和增減。

事實上,人們更擅長修改和增減,人們不擅長從一張白紙開始設計。通用資料模型的作用就是把人們從創作者的位置推到編輯者的位置。

還有一點需要注意的是,通用資料模型分為兩種,一種是通用操作型資料模型,另一種是通用資料倉儲資料模型。當我們基於通用資料模型建立資料倉儲時,要注意是以通用資料倉儲資料模型為基礎,而不是通用操作型資料模型。

建立資料模型

建立資料模型的第一步是選擇主題,建立主題領域模型,也就是進階別的實體模型。當主題領域模型建立好之後,接下來要做的是將所有的資料分成兩類,分別是未經處理資料(Primitive Data)和派生資料(Derived Data)。

未經處理資料是最低粒度的資料,是不能再進行細分的資料。未經處理資料的例子如,客戶名稱、客戶地址、客戶存款金額等等。

派生資料是可以由更細粒度的資料經過計算、匯總等資料處理得到的資料。派生資料的例子如,客戶數,月銷售額,日交易量等等。

資料模型中不要包含派生資料。有一個很好的理由可以說明資料模型中不應該包含派生資料。這個理由是派生資料變化的非常快。如果資料模型中包括派生資料的話,定義、計算和使用派生資料會導致資料模型經常變化。這種變化會給資料建模者帶來很大的問題。因此,派生資料是不應該進入資料模型的。

資料模型中不應該包含派生資料的另一個原因是派生資料會使資料模型過於膨脹。派生資料會使資料模型變得過大而不實用。而且,由於派生資料經常變化,也會使資料模型始終不能完成。

移除派生資料後,下一步要做的是選擇一個主題進行開發。有時,一個主題過於龐大,這時可以選擇這個主題的一個子集進行開發。

通常來說,建模者對業務的理解越深刻,建立的模型越完善。

選擇好主題後,下一步要做的就是針對這個主題開發DIS模型。

DIS模型描述了該主題內的資料。分析與該主題相關的業務需求,找出相關的鍵、屬性、標識、表等內容。這些鍵、屬性、標識等都需要被建立到DIS模型中的不同部分中。

DIS模型中的第一部分資料是根資料(Root Set)。根資料是該主題的一些特點、標識等內容,如當主題是人時,根資料就包括人的標識,如社會安全號碼碼。如果主題是企業,根資料就包括企業的唯一標識,如工商註冊號。

根資料也包括與主題直接相關的其他屬性資訊。

DIS模型中的第二部分資料是類型資料(Type of Data)。類型資料描述了該主題的不同類別。例如,如果主題是客戶,不同的類別包括客戶類別,如曆史客戶、潛在客戶等。也可以包括客戶的其他的分類方式,如高消費客戶、商業客戶、個人客戶等內容。客戶在每個分類方式中的類別應該是唯一的。

DIS模型中的第三部分資料是重複性的資料(Multiply Recurring Data)。例如,主題是人,重複性的資料包括這個人的多次的教育經曆,這個人的多個小孩的資訊,這個人曾經參加的工作單位等等。

DIS模型的內容包括

-鍵

-屬性

-外鍵

需要注意到的是,鍵只是標識,它不一定是唯一的。

重複性的資料以普通的層級關係依賴於根資料。

另外需要注意的是,類型資料中也可能有重複性的資料,重複性的資料中也可能有類型資料。(這句話表達的不清晰,我的理解是,這裡的類型資料就是我們常用到的類型表,而重複性的資料是主實體的子表,如前面提到的工作經曆情況,一個人有三次工作經曆,重複性資料建立工作經曆表,裡面就會有三條記錄。類型表的描述如果複雜的話,類型表的某些屬性也可能會建立子表。而像工作經曆這樣的子表中的某些屬性也可能會用類型表來描述。

在資料倉儲的開發過程中,所有的純操作性資料應該被刪除掉。例如,電話號碼就是典型的純操作型資料。在DIS模型中沒有時間元素的情況下,需要添加時間元素。

DW2.0建模的另一個需要考慮的問題是設定預設值。有時源系統不能提供DW2.0需要的所有資料值,這種情況下,為源系統中沒有的資料提供預設值是有必要的。

合并資料項目在DW2.0的建模中也是有可能使用到的。在源系統中屬於不同地方的資料,如果在DW2.0中經常在一起使用就可以考慮將它們建立在一起。也就是說,如果不同的資料項目經常在一起使用,可以考慮建立在同一張物理表中。例如,使用重複的群組技術。

DW2.0中的DIS模型中的另一項常用的技術是建立概要資料(Summarizations)。如果資料經常在較高的層級被使用,即在較高粒度使用,那麼可以為資料建立概要資料。概要資料也是派生資料,通常來說概要資料是不能建立在資料模型中的,但是如果概要資料能被很廣泛的使用的話,也可以建立概要資料。

DIS模型建立之後,可以開始建立物理資料模型。物理模型中儲存的是有物理特性的各個屬性。在建立物理模型時,各種物理資訊被包含進來,如表名、相關表、鍵、索引、屬性名稱、屬性類型、屬性長度等內容。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.