數據模型設計

1.整體框架約束下的叠代漸進

談到關系數據模型設計，首先想到的可能會是“概念數據模型設計”及實體關系圖（ER
圖），但我認為完整的數據庫數據模型設計需要經過三個階段：
（1） 數據總體結構設計；
（2） 概念數據模型設計；
（3） 構建數據庫模式。

2 數據總體結構設計

由於總體結構只是一個靜態框架，因此總體結構設計只涉及靜態對象建模，建模工具
采用UML。

根據面向對象分析與設計方法，總體結構設計工作可按下列流程開展：
(1) 剖析問題域（工作流與數據流分析）；
(2) 劃分對象（面向對象分析）；
(3) 定義類（面向對象設計）；
(4) 定義類之間的關系（面向對象設計）；
(5) 繪制UML類圖，小組討論或專家認定；
(6) 發布總體結構，統一設計思想。

1.工作流與數據流分析

剖析問題域是期望通過問題域的工作流和數據流分析提取數據對象,從而構成數據類
的抽象。工作流和數據流分析可以通過UML活動圖理順工作過程以及工作過程中可能產生
的數據對象，如圖2.2（采用 Microsoft Visio 繪制）。

圖2.2中的UML活動圖符號說明如下：

圖2.2表示成果圖編制過程中的數據處理工作分為三個階段、五個環節。即資料匯聚，
細化處理和成品提交階段；其中細化處理階段又包括分組整理、分類加工及元數據編寫環
節，與數據供方的溝通交流和質量控制措施貫穿始終。在資料匯聚階段，數據處理方必須
明確數據包數據內容，並與數據供方溝通協調，暢通數據渠道，促使雙方形成一個有機的
整體，保障工作順利進行。細化處理階段，按照數據模型設計要求將數據包分解為各數據
集單元，然後將各數據集單元分解為數據子集單元，再按載體類型對不同載體的數據子集
資料進行分類加工；加工後的數據再以數據子集為單元物理整合，以數據集為單元邏輯組
合，質量檢查合格後提交數據產品；最後，編寫並提交數據集的元數據。成品提交階段，
將各數據集的數據與元數據匯總打包成數據集產品，數據質量審查合格後形成數據集成品
或數據包成品提交入庫。

工作流和數據流也可以采用結構化軟件設計中的工作流與數據流圖進行分析，如圖2.3、
圖2.４。工作流與數據流圖是結構化軟件設計中的分析工具，雖然現在多采用面向對象以及
UML來進行軟件系統的分析設計，但工作流與數據流圖因其簡易直觀仍然有著不可替代的作
用。

圖 2.3 與圖 2.4 表示了柱狀與鉆孔巖芯在室內的編錄與分析過程，首先沿按巖芯管中
軸線將柱狀與鉆孔巖芯剖分兩半，其中的一半進行封裝處理作永久保留，另一半用於室內
編錄和分析樣采集。編錄前對巖芯進行照相，然後進行巖芯分層描述。在巖芯描述完成後，
確定各類分析樣品的取樣位置，采取分析樣品。采取的分析樣品經定名、稱重、裝袋、貼
標簽、填寫送樣單，最後送各實驗室測試分析。

2 面向對象分析與設計

面向對象分析與設計中可采用的原則不少， Craig Larma 在其《UML和模式應用》）一
書中有詳細的論述，下面的原則我認為對數據總體結構設計來說很有用：

(1) 模塊化：將問題域數據分解成一組內部內聚、外部松散耦合的模塊。內聚指對象
自身職責的相關性和集中度比較高，類似於把相關性和集中度比較高的職責分配
給單獨的對象，不讓一個對象承擔過多不相關的工作。松散耦合指對象之間的依
賴程度比較低，需要時可以幫一下，不需要時相忘於江湖，互相沒有太多的牽連，
以此來降低對象之間的依賴程度，減少變化帶來的影響，提高系統的伸縮性。在
Geodatabase中的模塊化就是將數據分成不同的要素集，要素集內的數據共享同一
空間參照系，要素集內的要素類之間可以具有拓撲關系，但要素集之間的耦合是
松散的。

(2) 信息專家：把某類信息的管理職責分配給擁有該類信息的對象。信息專家原則實
際上是要求一個對象所涉及的信息要單一，不要涉及不相關的信息內容。

(3) 間接性：為了避免兩個或多個對象之間的直接耦合，可引入中介對象，使其作為
聯系的媒介，通過中介可使數據庫內部各數據模塊之間的關系達到最小化。這就
是所謂的不要和“陌生人”對象講話，增加公共的“熟人”對象原則。GIS系統設
計中最常見的是將位置模塊作為公共模塊，數據模塊之間的關聯均通過位置模塊
實現，使模塊之間的關系最小化。

(4) 純虛構：如果不想違背模塊化原則，信息專家原則又不合適時，可以創建新的對
象，該對象不代表問題域的概念，是憑空虛構的。如Geodatabase中的要素集實際
上就是純虛構對象。

(5) 防止變異：預測可能的變化點或進化點，在變化範圍之外創建對象，使其內部變
化不會對其它對象產生不良影響。最常見的是動靜隔離的方法，將多變的部分從
相對穩定的部分中隔離出來。

總體結構最終給出的應該是一個有機整體，整體內部自成體系，如：裏外分層、內部
分塊，外層有入口（數據入口或數據管理單元），有出口（數據對外的信息通道），內部有
不同的模塊（類）和模塊之間的通道（類之間的聯系）。同時，總體結構必須具有足夠的抽
象程度，能保持長期穩定，並包容變化。檢驗總體結構的基本標準是：總體結構來自問題
域數據流的抽象，但必須與問題域的具體應用無關。

圖中類與類的關系包括聚合/組合、泛化和依賴。
當類之間有整體與部分關系的時候，使用聚合或者組合。聚合是一種相對松散的整體
與部分關系，聚合類不需要對被聚合類負責。圖 2.6 中，“要素集”由“要素類”及其“關
系類”聚合而成。
組合是一種強聚合關系，組合類控制著被組合類的生命期，被組合類會隨著組合類的
創建而創建，隨著組合類的消亡而消亡。圖 2.6 中，“要素集”與“空間參照系”之間就是
組合關系，同一個要素集內的要素類享有同一空間參照系，離開空間參照系，空間數據就
失去了地理意義。
依賴是一種弱關聯，表示一個類與另一個類的涉及關系，但不是固定關系。例如：自
行車與打氣筒，汽車與汽油的關系。圖 2.6 中“要素集”與“拓撲規則”之間定義為依賴
關系，表示需要時可以通過拓撲規則來檢測地理要素的數據質量，兩者之間沒有必然聯系。
泛化表示子類與父類之間的關系，父類能夠派生出具有更多特殊行為的子類，此時父
類即為子類的超類或說子類的泛化，子類是父類的特化。圖 2.5 的抽象類（斜體字表示）“數
據集”為一泛化類，“文檔”、“圖件”、“遙感影像”和“原始數據”都是“數據集”的特化。
經常見到泛化與繼承混用，嚴格來說，兩者屬於不同的領域不擬混用。泛化和特化屬於問
題域，繼承屬於軟件領域。軟件領域的繼承是使超類的特性適應於子類的軟件機制，主要
是為了代碼重用。而在問題域是期望對泛化類的研究提取子類的共性，以便數據類的抽象。
圖 2.5 的設計意圖如下：
（1） 數據庫數據內外分層，層內分塊。外層為數據信息層，包括調查信息模塊的“調
查區”（Location）、“調查”（Survey）、“歷史事件”（HistoryEvent）、“成果目
錄”（Content）、“成果評價”（Asset）和“成果包”（Collection），以及元數據
模塊的“元數據”（Metadata），它們負責數據的對外信息服務。內層為數據資
源層，負責具體數據資源（文檔、圖件、遙感影像及原始數據模塊）的存儲。
外層與內層之間只有邏輯上的聯系，物理上可以是隔離的，這為數據的安全性
提供了保障。
（2） “調查”（Survey）、“成果包”（Collection）、“數據集”（Dataset）類是支撐數
據庫的中樞。在一個調查區可能進行多項專業調查，每項專業調查結果會形成
一個成果包，每個成果包中可能包括有多個報告文檔、多幅成果圖件、以及一
系列實測或收集的原始數據。

（3） “成果包”（Collection）是由外層進入內層的隘口，每個成果包的擁有者可以
擁有自己數據的管理權。這為實施多方數據管理奠定了基礎，如果對成果包對
象施加數據表行級安全策略，進入數據庫後，數據供方將只能看到並管理自己
的數據。
（4） “調查”（Survey）是數據信息層的非空間入口，同時“調查區”（Location）
可以作為數據的空間入口。入口意味著它們是數據的出入管理員，數據入庫必
須先向它們登記，數據檢索也首先從它們開始，對數據的任何操作將在入口處
被跟蹤。
（5） “元數據”（Metadata）作為對外信息窗口，調查可以有調查元數據，成果也可
以有成果元數據。
（6） “成果目錄”（Content）和“歷史事件”（HistoryEvent）由系統自動維護，追蹤
數據資源的入庫、修改及更新操作。“成果目錄”（Content）中可以容納“成果
評價”（Asset）信息，讓用戶在第一時間了解數據的質量級別。成果評價可以
由多方專家通過網絡評定。
（7） 內層的數據資源由“文檔”、“圖件”、“遙感影像”及“原始數據”模塊管理。
數據集作為數據資源的邏輯組織單元，數據集可以是一個文檔、一幅圖件、或
同期同類型的實測數據，沒有嚴格的範圍界定。數據集實際數據均通過索引表
調用。
圖 2.6 其實是 ArcGIS Geodatabase 的總體結構 UML 類圖，其包含信息描述如下：
(1) 地圖通過“圖件索引”（MapIndex）提取，“圖件”（Map）類負責地理要素的存儲，
“地圖模板”（MapTemplete）負責地理要素的顯示。
(2) 一幅圖件是 1 到多個要素集數據的專題聚合，及選定樣式下各要素類對應圖層
的綜合表現。
(3) 地圖數據由 ESRI 面向對象地理數據庫（Geodatabase）統一存儲及管理。包括
庫級的要素集、屬性表與關系類，以及要素集級別的要素類和關系類。
(4) 要素集聚合對象包括不同幾何類型的要素類以及與要素類相關的關系類。同一個
空間要素集內的要素類享有同一空間參照系。拓撲規則也在同一數據庫的要素
集中進行管理。
(5) 矢量要素類圖元類型包括有：點（Point）、線（Line）、面（Polygon）、註記

（Annotation）四種，一個要素類只能包含一種圖元類型。
(6) 屬性表存儲在地理數據庫中通過關系類與要素類關聯，實現要素類屬性的動態捆
綁。

總體結構設計有關大局， 它是整個數據模型的靈魂，需要思路合理和概念完整，能在
將來為數據庫系統的易用性及伸縮性提供保障，因為技術會不斷更新，需求也會不斷變化，
但數據庫是不應該推倒重來的。有效的總體結構模型應該捕獲了能滿足當前需求的問題域
概念，搭建起實用的概念連接框架，最終確保模型能回答任何合理的問題，譬如: 是否有
利於數據安全保護？是否有利於數據管理？是否有利於公眾服務？是否能適應變化？是否
能對後續設計起到指導與約束作用？等等。

3 概念數據模型設計

概念數據模型設計的目標是創建問題域對象的概念描述，使用關系模型時，問題域的
概念稱作實體，概念的描述就是定義實體以及實體間的聯系。概念數據模型通過實體
（Entity）、屬性（attribute）、域（domain）和聯系來描述。
概念數據模型設計在總體結構框架約束下進行，首先在總體結構框架中選擇數據類，
最好從你比較熟悉的、或你認為比較重要的、或具有代表性的數據類入手；然後依據規範
化原則將數據對象分解成可關聯的數據實體；在此基礎上根據實際需要定義各實體的屬性，
同時依照專業領域的業務規則定義屬性的域；最後進行模型的測試及優化。概念數據模型
設計工作可以由多人分模塊進行，但是必須將總體結構設計思想落實到每一個人，始終維
護總體設計思想的一致性。
概念數據模型設計流程如下：
(1) 從總體結構中選取數據模塊，確定待設計的數據對象；
(2) 分解數據對象，確定數據實體及實體間的關系，繪制總實體關系圖（不帶屬性 ER
圖）；

(3) 定義實體的屬性及域，繪制帶屬性的實體關系圖，並附數據字典對屬性的定義以
及屬性的域加以文字補充說明；
(4) 模型測試、修改與優化。

概念數據模型設計涉及許多“概念”，我很長時間處於模模糊糊之中，譬如說概念數據
模型的概念兩字其含義究竟是什麽？實體又是什麽？域又是什麽？規範化原則到底該貫徹
到何種程度？等等。2.3.1 的一些認識，可能會對設計工作有所幫助。

實體關系圖與數據字典

概念數據模型文檔一般包括兩部分，實體關系圖（ER圖）及數據字典，數據字典以字
典形式給出數據實體與屬性的文字定義，以避免多義理解。
實體關系圖（ER 圖）繪制一般分兩步走，第一步只考慮實體以及它們之間的聯系，第
二步考慮給定實體的屬性，不同時考慮兩者是為了讓設計工作變得單純一點。實體關系圖
的表示方法很多，當然只要能清楚表達設計意圖就好。
圖 2.8 為只考慮實體及其聯系的實體關系圖示例，圖 2.9 為包含屬性的實體關系圖。

劃分要素集和要素類

更多參見： http://pan.baidu.com/s/1jIE8H1O

數據模型設計