準則: 資料模型
「資料模型」擷取系統所用的持續性資料儲存庫的設計。這個準則介紹「資料建模」和在 RUP 內的用法。
關係
主要說明

概觀

資料模型用來設計系統所用之持續性資料儲存庫的結構。資料庫設計的統一建模語言 (UML) 設定檔會提供一組建模元素,供資料庫設計者用來開發資料庫表格的詳細設計,以及建立資料庫實際儲存體佈置的模型。另外,UML 資料庫設定檔也會提供用來建立參照完整性模型的建構(限制和觸發程式),以及用來管理資料庫存取作業的儲存程序。

企業、部門或個別應用程式等層次都可以建構資料模型。企業和部門層次的資料模型可以提供主要商業實體(如客戶和員工)的標準定義,供企業或企業單元內的所有應用程式使用這些實體。這些類型的資料模型也可用來定義企業中的哪個系統是商業專用實體的資料「擁有者」,以及哪些其他系統是資料的使用者(訂閱者)。

這個準則說明用來建構關聯式資料庫資料模型的資料庫建模 UML 設定檔模型元素。由於有許多現成的一般資料庫理論書籍,因此,這個準則不討論這個部分。如果需要關聯式資料模型和物件模型的背景資訊,請參閱概念:關聯式資料庫和物件導向

附註:這個準則所包括的資料建模表示法是以 UML 1.3 為基礎。在開發這個準則時,還無法使用 UML 1.4 資料建模設定檔。

資料建模階段

如 [NBG01] 所說明,資料模型有三個一般開發階段:概念、邏輯和實體。這些資料建模階段反映了應用程式持續性資料的儲存和擷取機制的不同設計細節層次。關於概念性資料建模的討論,請參閱概念概念資料模型。關於邏輯和實體資料建模的摘要,請參閱這個準則的下兩節。

邏輯資料建模

在邏輯資料建模中,資料庫設計者的關懷在於識別主要實體和關係,它們用來擷取應用程式必須持續保存在資料庫中的重要資訊。在使用案例分析使用案例設計類別設計作業期間,資料庫設計者設計師必須一起工作,以確保應用程式的分析類別和設計類別的逐步設計,能夠適當支援資料庫的開發。在類別設計作業期間,資料庫設計者和設計者必須在設計模型中,識別一組要用來將資料持續保存在資料庫中的類別。

設計模型中的這組持續性類別會提供一個設計模型視圖,與傳統的邏輯資料模型有些不同,但仍符合許多相同的需求。設計模型所用的持續性類別,運作方式與邏輯資料模型中的傳統實體相同。這些設計類別能夠精確反映必須持續保存的資料,其中包括必須持續保存的所有資料直欄(屬性)以及主要關係。如此一來,這些設計類別便成為實體資料庫設計的最佳起點。

建立單獨的邏輯資料模型是一個選項。不過,在最佳情況中,它最後會用不同形式擷取相同的資訊;但在最糟情況中,便不如此,結果可能會不符合應用程式的商業需求。尤其是,如果預期資料庫只處理單一應用程式,應用程式看待資料的角度,可能才是最佳起點。資料庫設計者根據這組持續性設計類別來建立表格,以形成最初的實體資料模型。

儘管如此,資料庫設計者有時仍需建立與應用程式設計無關的理想化資料庫設計。在這個情況下,邏輯資料庫設計會呈現在整體工作成果:資料模型內的獨立邏輯資料模型中。這個邏輯資料模型用來描繪主要邏輯實體及其關係,在滿足系統需求來持續保存符合應用程式整體架構的資料時,會需要這些實體和關係。這個準則稍後幾節所說明的資料庫設計 UML 設定檔建模元素可用來建構邏輯資料模型。對於使用這個方式的專案而言,如果要順利開發資料庫設計,應用程式設計者和資料庫設計者之間的密切合作絕對重要。

在發展邏輯資料模型的元素來建立資料庫的實體設計之前,您可以先依照概念:正規化所定義來套用標準正規化規則,修正邏輯資料模型。

下圖描繪以設計模型類別作為邏輯資料庫設計的資訊來源,來建立起始實體資料模型的主要方式。另外,它也說明使用獨立的邏輯資料模型的替代方式。  

圖解說明詳見隨附的文字。

邏輯資料建模方式

實體資料建模

實體資料建模是資料庫設計的最後一個開發階段。實體資料模型由詳細的資料庫表格設計及最初從持續性設計類別及其關係建立起來的關係組成。將設計模型類別轉換成表格之執行機制的相關討論,在準則:關聯式資料庫正推工程中。實體資料模型是資料模型的一部分;它不是個別構件。

實體資料模型中的表格有定義好的直欄,以及必要的索引鍵和索引。另外,表格也可能會有定義為支援系統的資料庫功能和參照完整性時所需要的觸發程式。除了表格之外,儲存程序也已建立好,備妥文件,並關聯於儲存程序將放在其中的資料庫。

下圖顯示實體資料模型某些元素的範例。這個範例模型是虛擬線上拍賣應用程式之實體資料模型的一部分。它描述四份表格(Auction、Bid、Item 和 AuctionCategory),以及一個儲存程序 (sp_Auction) 及其儲存器類別 (AuctionManagement)。另外,這個圖也描述每份表格的直欄、主鍵和外鍵限制,以及所定義的表格索引。 

圖解說明詳見隨附的文字。

範例(實體)資料模型元素

另外,實體資料模型也包含從表格到資料庫中之實體儲存單元(表格空間)的對映。下圖顯示這項對映的範例。在這個範例中,Auction 和 OrderStatus 表格對映到稱為 PRIMARY 的表格空間。另外,這個圖也說明在資料庫(在這個範例中,稱為 PearlCircle)中實現表格的建模作業。

圖解說明詳見隨附的文字。

範例資料儲存體模型元素

在已有資料庫的專案中,資料庫設計者可以反向工程現有的資料庫來移入實體資料模型。請參閱關聯式資料庫反向工程,以取得詳細資訊。

資料模型元素

本節說明以資料庫建模 UML 設定檔為基礎的各個主要資料模型元素的一般建模準則。各模型元素的簡要說明之後,會有 UML 模型元素的範例說明。這個準則的關係一節包括模型元素的用法說明。

套件

標準 UML 套件用來分組和組織資料模型的元素。例如,您可以定義套件來將資料模型組織成個別的邏輯資料模型和實體資料模型。另外,套件也用來識別資料模型中,對於所開發之應用程式的商業領域很重要的主要資料 "Subject Areas",用來形成這些區域的邏輯上相關的表格群組。下圖顯示在資料模型中,用來組織概略表和表格的兩個主題區套件(Auction Management 和 UserAccount Management)的範例。

圖解說明詳見隨附的文字。

主題區套件範例

表格

在資料庫建模的 UML 設定檔中,表格的模型建立模板為 <<Table>> 的類別。表格中直欄的成模型建立成模板為 <<column>> 的屬性。您可以將一或多個直欄指定為主鍵,以提供給表格中的唯一列項目。另外,直欄也可以指定為外鍵。主鍵和外鍵有相關聯的限制,它們的模型分別建立成模板為 <<Primary Key>> 和 <<Foreign Key>> 的作業。下圖描述一個範例表格的結構,這個表格用來管理虛擬線上拍賣系統在拍賣時所售出之項目的相關資訊。 

圖解說明詳見隨附的文字。

表格範例

表格可以透過下列關係類型來關聯於其他表格:

  • 識別(組合聚集)
  • 非識別(關聯)

這個準則的關係一節提供如何使用這些關係的範例。這些關係類型如何對映到設計模型元素的相關資訊,在準則:關聯式資料庫反向工程中。

觸發程式

觸發程式是設計成在它所在的表格執行了某個動作之後,便跟著執行的程序化函數。觸發程式定義成在插入、更新或刪除表格中的某一列之時執行。另外,觸發程式也指定成在表格指令執行之前或之後執行。觸發程式定義為表格中的作業。這些作業的模板是 <<Trigger>>。 

圖解說明詳見隨附的文字。

觸發程式範例

索引

當利用特定直欄來搜尋表格時,索引用來作為加快存取資訊的機制。索引的模型建立成表格中模板為 <<index>> 的作業。索引可以指定為唯一的,也可以指定為叢集或非叢集。叢集索引用來將表格中資料列的順序強制對齊索引值的順序。下圖顯示索引作業 (IX_auctioncategory) 的範例。

圖解說明詳見隨附的文字。

索引範例

概略表

概略表是一種虛擬表格,不含任何獨立的持續性儲存庫。概略表具備表格的特性和行為,且會從概略表定義了相互關係的表格直欄中存取資料。概略表用來提供一或多份表格中更有效的資訊存取方式,也可用來強制施行限制表格資料存取權的商業規則。在下列範例中,AuctionView 定義成這個準則的實體資料建模區段所顯示的 Auction 表格中之資訊的「概略表」。

概略表的模型建立成模板為 <<view>> 的類別。概略表類別的屬性是概略表所參照的表格直欄。概略表中的直欄資料類型繼承定義了概略表相依性的表格。

 圖解說明詳見隨附的文字。

概略表範例

領域

領域是一個用來建立使用者定義資料類型的機制,以便將這些資料類型套用到多份表格的直欄上。 領域的模型建立成模板為 <<Domain>> 的類別。在下列範例中,定義了郵遞區號 "zip + 4" 的領域。 

圖解說明詳見隨附的文字。

領域範例

儲存程序儲存器

儲存程序儲存器是資料模型內儲存程序的分組。儲存程序儲存器建立成模板為 <<SP Container>> 的 UML 類別。在單一資料庫設計中,可以建立多個儲存程序儲存器。每個儲存程序儲存器都必須有至少一個儲存程序。

儲存程序

儲存程序是通常會在資料庫伺服器中的獨立程序。儲存程序是用分組到模板為 <<SP Container>> 之類別中的作業來說明。這些作業的模板是 <<SP>>。下列範例顯示名稱為 AuctionManagement 的儲存器類別中的單一儲存程序作業 (SP_Auction)。當設計儲存程序時,資料庫設計者必須瞭解特定 RDBMS 所用的任何命名慣例。

圖解說明詳見隨附的文字。

儲存程序儲存器和儲存程序範例

表格空間

表格空間代表要配置給表格、儲存程序和索引等項目的儲存體空間數量。表格空間會利用相依性關係而鏈結到特定資料庫。表格空間的數目以及個別表格對映它們的方式,會隨著資料模型的複雜度而不同。經常存取的表格可能需要分割到多個表格空間中。如果表格並未包含大量經常存取的資料,便可以將它們分組到單一表格空間中。

每個表格空間都會定義一個表格空間儲存器。表格空間儲存器是表格空間的實體儲存裝置。雖然單一表格空間可以有多個表格空間儲存器,但建議您只將表格空間儲存器指派給單一表格空間。表格空間儲存器定義為表格空間的屬性;它們並不明確建模。

圖解說明詳見隨附的文字。

表格空間範例

綱目 到頁面頂端

綱目用來說明資料庫的組織或結構。綱目是以模板為 <<Schema>> 的套件來表示。將綱目定義成套件時,組成這個套件的表格應該包含在綱目內。建立資料庫和綱目之間的相依性,便可以說明資料庫和綱目之間的關係。 

圖解說明詳見隨附的文字。

綱目範例

資料庫 到頁面頂端

資料庫是組織成能夠存取和管理其中之資訊的資料集合。資料庫中之資訊的管理和存取,是利用商務資料庫管理系統 (DBMS) 來執行。在資料模型中,資料庫是用模板為 <<Database>> 的元件來表示。

圖解說明詳見隨附的文字。

資料庫範例

關係 到頁面頂端

資料庫建模的 UML 設定檔用來定義資料模型主要元素之間的有效關係。下列各節提供不同關係類型的範例。 

非識別

非識別關係是在資料庫內相互獨立存在的兩份表格之間的關係。非識別關係是利用表格之間的關聯來說明。關聯的模板是 <<Non-Identifying>>。下列範例描述 Item 表格和 AuctionCategory 表格之間的非識別關係。

圖解說明詳見隨附的文字。

非識別關係範例

識別

識別關係是在兩份表格之間,子表格必須與母表格共存的關係。識別關係是利用兩份表格之間的組合聚集來說明。組合聚集的模板是 <<Identifying>>。下圖是識別關係的範例。這個範例顯示子表格 (CreditCard) 的實例,在母表格 (UserAccount) 中,必須有一個相關聯的項目。

圖解說明詳見隨附的文字。

識別關係範例

對於關聯和組合聚集,您都應該定義對應關係來說明關係中的列數。在上述範例中,UserAccount 表格中的每一列,在 CreditCard 表格中可以有 0 或多個 CreditCard 列。CreditCard 表格中的每一列,UserAccount 表格中會有正好一列。另外,對應關係也稱為基數。

資料庫概略表

當定義資料庫概略表與表格的關係時,會使用從概略表畫到表格的相依性關係。相依性的模板是 <<Derive>>。概略表相依性通常會有名稱,且相依性的名稱與資料庫概略表相依性關係中所定義的表格同名。

圖解說明詳見隨附的文字。

概略表和表格相依性關係範例

表格空間

相依性關係用來將表格空間鏈結到特定的資料庫。如下圖所示,所繪製的關係顯示資料庫相依於表格空間。多重表格空間可以關聯到模型中的單一資料庫。

圖解說明詳見隨附的文字。

表格空間和資料庫相依性關係範例

相依性關係用來說明表格空間和表格空間內的表格之間的關係。單一表格空間可以有一或多份相關的表格,單一表格也可以有多個相關的表格空間。下列範例顯示 Auction 表格指派給名稱為 PRIMARY 的單一表格空間。

圖解說明詳見隨附的文字。

表格和表格空間相依性關係範例

實現化

實現化用來建立資料庫和其中的表格之間的關係。表格可以由資料模型中的多個資料庫來實現。

圖解說明詳見隨附的文字。

表格和資料庫實現化關係範例

儲存程序

相依性關係用來說明儲存程序儲存器和儲存程序儲存器內的儲存程序所處理的表格之間的關係。下列範例描述這類型的關係,它顯示 SP_Auction 儲存程序將用來存取 Auction 表格中的資訊。

圖解說明詳見隨附的文字。

儲存程序儲存器和表格相依性關係範例

資料模型的發展

初始階段

初始階段的「執行架構綜合活動」作業中,初步的資料建模作業和任何概念實證原型的開發可能同時進行。 在已包含資料庫的專案中,資料庫設計者可以反向工程現有的資料庫來開發以現有資料庫結構為基礎的起始實體資料模型。請參閱準則:關聯式資料庫反向工程,以取得詳細資訊。您可以依照需要,將實體資料模型的元素轉換成設計模型元素,以支援任何證明概念的原型作業。

詳述階段

詳述階段的目標是消除技術風險和產生穩定的(設定基準線的)系統架構。 在大型系統中,因資料模型設計不良而造成效能不好是主要的架構問題。因此,為了實現穩定架構,架構原型的資料建模和開發非常重要,它必須使資料庫的效能可以接受評估。在每次反覆詳述和分析了含架構重要性的使用案例之時,也會以使用案例的持續性類別設計之開發為基礎來定義資料模型元素。在類別設計穩定之後,資料庫設計者便可以將類別設計定期轉成資料模型中的表格,以及定義適當的資料儲存體模型元素。

在詳述階段結束之時,必須備妥主要資料庫結構(表格、索引,以及主鍵和外鍵直欄)來支援執行應用程式已定義好的含架構重要性的情境。另外,您也必須將代表性的資料容體載入資料庫中,以支援架構上的效能測試。您可能需要根據效能測試的結果,利用最佳化技術來調整資料模型,其中包括但不限於反正規化、最佳化實體儲存體屬性或分散,和編製索引。

建構階段

建構階段,「資料模型」絕對不可以進行重大的重組。在建構階段各項反覆期間,可能會以配置給反覆的一組使用案例和已核准之變更需求的詳細設計為基礎來定義其他表格和資料儲存體元素。建構期間的主要資料庫設計焦點是連續監視資料庫的效能,以及依照需要,藉由反正規化、定義索引、建立資料庫概略表及其他最佳化技術來最佳化資料庫設計。

實體資料模型是資料庫設計者在建構階段所維護的設計構件。維護方式可能是直接更新模型,或由工具讀取資料庫的直接更新來進行。

轉換階段

如同「設計模型」一樣,轉換階段也會維護「資料模型」來回應已核准的變更要求。 隨著應用程式走到最後的驗收測試,以及部署到正式作業中,資料庫設計者也必須保持資料模型與資料庫的同步。

正反向工程考量

如果開發小組使用能夠將類別轉換成表格(反之亦然)且/或能夠正向工程和反向工程資料庫的最新視覺化建模工具,小組便需要建立轉換流程和工程流程的管理準則。主要是大型專案會需要這些準則,在這些專案中,小組以平行方式來設計資料庫和應用程式。開發小組必須在應用程式的開發(建置/發行循環)中,定義幾個適合執行「類別至表格」轉換和正推資料庫的點。建立好起始資料庫之後,隨著系統的設計和程式碼在專案中的進展,開發小組也必須定義資料模型和資料庫的同步化管理準則。