概念: 概念資料模型
概念資料模型描述重要實體及其關係,目的是探索專案關係人的領域概念;專案關係人定義系統解決方案欲解決的問題範圍。
關係
主要說明

簡介

根據 [NBG01] 的定義,在設計系統的持續資料和持續資料儲存體的開發過程中,概念資料模型代表其中的起始階段。系統的持續資料通常由關聯式資料庫管理系統 (RDBMS) 來管理。在概念層次上從商業模型和系統需求中找出的商業實體與系統實體,經過使用案例分析、使用案例設計及資料庫設計作業,逐步形成詳細的實體表格設計,最後在 RDBMS 中實作。請注意,本概念文件中討論的「概念資料模型」不是單獨的工作成果。而是及節已含在現有「商業模型」、「需求」及「分析和設計規範」工作成果中的資料所形成的綜合觀點,與資料模型的開發有關。 

資料模型通常會經歷下列三個階段:

  • 概念-這個階段會找出高階的關鍵性商業實體和系統實體及其關係,這些實體和關係定義了系統欲解決的問題範圍。接著會使用「商業分析模型」中的 UML 商業模型設定檔的建模元素及「分析模型」的分析類別模型元素來定義找出的關鍵性商業實體和系統實體。
  • 邏輯-這個階段將高階的商業實體和系統實體修正為更詳細的邏輯實體。根據準則:資料模型的說明,可以使用 UML 資料庫設計設定檔的建模元素,另外在「邏輯資料模型」中定義這些邏輯實體及其關係。這個選用的「邏輯資料模型」屬於工作成果:資料模型的一部份,不是獨立的 RUP 工作成果。
  • 實體-這個階段將邏輯類別設計轉換成詳細和最佳化的實體資料庫表格設計。實體階段也會將資料庫表格設計對映至資料庫儲存體設計的表格空間和資料庫元件。 

資料庫設計的相關作業橫跨整個軟體開發生命週期,且最初的資料庫設計作業,可能從初始階段就開始進行。對於以商業模型來描述應用程式商業情境的專案,資料庫設計可能從概念層次上開始,包括在「商業使用案例模型」中找出「商業參與者」和「商業使用案例」,在「商業分析模型」中找出「商業工作者」和「商業實體」。對於不使用商業模型的專案,資料庫設計可能從概念層次上開始,包括在「使用案例模型」中找出「系統參與者」和「系統使用案例」,在分析模型中從「使用案例實現化」找出分析類別。 

下圖顯示「商業模型」、「需求模型」及「分析模型」中的「概念資料模型」元素集。

圖解說明詳見下文。

下列章節說明「商業模型」、「使用案例模型」及「分析模型」的元素,這些元素可以為系統的持續資料定義起始的「概念資料模型」。

概念資料模型元素

商業模型

商業使用案例模型

商業使用案例模型由「商業參與者」和「商業使用案例」組成。「商業使用案例」代表關鍵性商業流程,可定義打算開發之系統的環境定義。「商業參與者」代表透過「商業使用案例」與商業互動的關鍵性外部實體。下圖簡單示範一個線上拍賣應用程式的「商業使用案例模型」。 



圖解說明詳見下文。

基於實體在系統空間問題領域中的重要性,「商業參與者」也就順理成章地成為「概念資料模型」的候選實體。在上述範例中,「買方」和「賣方」商業參與者是線上拍賣應用程式可能必須儲存資訊的候選實體。 

商業分析模型

「商業分析模型」中包含所有必要類別,可用來建立從分析「商業使用案例」的工作流程中找出的「商業工作者」和「商業實體」。「商業工作者」代表執行動作以實現此工作流程的參與工作者。「商業實體」是「商業工作者」在工作流程中使用或產生的「事物」。「商業實體」通常代表系統必須持續儲存的資訊類型。  

下圖是一個序列圖範例,圖中描述「提供線上拍賣」這個「商業使用案例」情境中的「商業工作者」和「商業實體」,以便管理此線上拍賣活動。

圖解說明詳見下文。

在這個簡單的範例中,「拍賣管理員 (Auction Manager)」物件代表一個「商業工作者」角色,很可能是由線上拍賣管理系統本身所扮演。「拍賣 (Auction)」和「拍賣物品 (Auction Item)」物件是「拍賣管理員」工作者使用或產生的「商業實體」,「拍賣管理員」扮演「買方 (Buyer)」和「賣方 (Seller)」商業參與者的代理人。從資料庫設計的角度來看,「拍賣」和「拍賣物品」商業實體就是「概念資料模型」的候選實體。  

需求和分析模型

對於不執行商業模型的專案,「需求模型」(系統使用案例)和「分析模型」中包含可以開發起始「概念資料模型」的模型元素。對於使用商業模型的專案,會將從「商業分析模型」中找出的商業實體及關係,進一步在「分析模型」中修正並細部化為「實體類別」。  

系統使用案例模型

「系統使用案例模型」包含「系統參與者」和「系統使用案例」,定義使用者與系統之間的主要互動。「系統使用案例」定義系統的功能需求。

從概念資料模型的角度來看,「系統參與者」代表系統的外部實體,且系統可能需要儲存這些實體的持續性資訊。如果「系統參與者」在開發過程中是擔任與系統間傳送和接收資料的外部系統,則該實體儲存持續資訊的能力就非常的重要。「系統參與者」可能衍生自「商業使用案例模型」的「商業參與者」和「商業分析模型」的「商業工作者」。  

下圖描述線上拍賣系統的「商業使用案例模型」。在此模型中,「買方」和「賣方」商業參與者衍生自一般的「使用者」商業參與者。新增的系統參與者稱為「信貸機構」,反映出透過外部實體來處理付款的需求。這個新的系統參與者是「概念資料模型」的另一個候選實體。 



圖解說明詳見下文。



分析模型

分析模型包含從「系統使用案例」的「使用案例實現化」中找出的分析類別。從概念資料模型的角度來看,主要的「分析類別」類型是「實體分析類別」。根據準則:分析類別的定義,「實體分析類別」代表由系統管理且必須持續儲存的資訊。「實體分析類別」及其關係會形成應用程式起始「資料模型」的基礎。  

「分析模型」中的概念性「實體分析類別」,可能在進一步「設計模型」中修正並細部化成邏輯性的「持續性」設計類別。這些設計類別代表「資料模型」中的候選表格。類別的屬性是表格的候選直欄,也代表直欄的候選鍵。關於「設計模型」元素如何對映至「資料模型」元素的說明,請參閱準則:正向工程關聯式資料庫