作業: 資料庫設計
這項作業說明如何設計資料庫,在應用程式中實作持續性。
規範: 分析 設計
目的
  • 確保持續資料以一致且有效的方式儲存。
  • 定義必須在資料庫中實作的行為。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
主要說明

這項作業呈現的步驟假設應用程式的持續資料設計,將會使用關聯式資料庫管理系統 (RDBMS) 實作。這裡假設您已經熟悉資料庫的概念,這包括正規化及反正規化,以及如參考資訊 [DAT99] 中涵蓋的資料庫專有名詞。 

這項作業中的步驟也引用「統一建模語言 (UML)」設定檔來進行資料庫建模,請參閱 [NBG01]. 另外,[NBG01] 中也包含使用 UML 建立及設計關聯式資料庫模型程序的一般說明。如需關於關聯式資料模型和物件模型之間的關係背景資訊,請參考概念:關聯式資料庫與物件導向

步驟
開發邏輯資料模型(選用)
目的 定義資料庫的邏輯設計模型。

「邏輯資料模型」的目的是要提供對主要的邏輯資料實體,以及各資料實體之間,和任何特定的軟體或資料庫實作方式無關的關係實現視圖。這一般都是採用第三種正規格式(請參閱概念:正規化),這是一種資料建模格式,其可減少冗餘,並確保不會有暫時性的相依關係存在。這種模型會考慮資料庫在擷取資料時的情況,而不考慮使用資料的應用程式及其效能。請注意,「邏輯資料模型」只被當作工作成果:資料模型的一部分而已,並不是獨立的 RUP 工作成果。不過,通常針對下列項目定義個別的「邏輯資料模型」是極為重要的工作:

  • 由不同的小組開發資料庫及應用程式設計的專案。
  • 有多重應用程式會共用相同資料庫的專案。

如果您要建立「邏輯資料模型」,您可以使用工作成果準則:資料模型中說明的模型元素,從頭開始著手工作,也可以從使用分析模型設計模型中的每個持續性類別之實體開始著手。

您也可能會決定不要建立個別的「邏輯資料模型」,特別是設計用來處理單一應用程式的資料庫時。在此情況下,資料庫設計師會依據「設計模型」 中的一組持續性類別以及類別之間的關聯,來開發「實體資料模型」。

在這些方法中,資料庫設計師以及設計師們務必要在整個分析及設計過程中一起合作,找出在工作成果:設計模型中的哪些類別需要將資訊儲存在資料庫中。如標題為「指出作業:類別設計中的持續類別」步驟的說明,資料庫設計師應該和設計師合作找出在「設計模型」中,有哪些設計類別是視為持續性,並且有可能會成為資料庫的表格。

開發實體資料庫設計
目的 定義資料庫的詳細實體設計。

實體資料庫設計包括代表資料庫詳細實體結構的模型元素(例如表格、概略表以及儲存程序),以及代表資料庫的基礎資料儲存體設計的模型元素(例如綱目與表格空間)。這些模型元素共同組成資料庫的「實體資料模型」。這個「實體資料模型」內含在工作成果:資料模型中,並不是獨立的模型工作成果。

開發實體資料庫設計的詳細步驟如下所示:

定義領域

目的 定義可重複使用的使用者定義的類型。 

資料庫設計師可能會在整個資料庫設計過程中,用領域來強制施行類型標準。領域是使用者定義的資料類型,此種資料類型可以套用在表格中的直欄。領域具有和直欄相同的內容,但沒有直欄名稱。 

建立起始實體資料庫設計元素

目的 建立起始資料庫表格與關係。

資料庫設計師會依工作成果準則:資料模型中的說明,使用表格以及表格中的直欄,來建立「實體資料模型」元素的模型。 

如果已經有建立「邏輯資料模型」,則可以用其邏輯實體作為一組起始表格的基礎。

另外,資料庫設計師也可能會使用「設計模型」中的持續性類別,作為建立「實體資料模型」的表格基礎,來快速開始建立「實體資料模型」。資料庫設計師會將持續性類別和類別屬性分別建立成為表格及直欄的模型。資料庫設計師也必須依據「設計模型」中的持續性類別之間的關聯,來定義表格之間的關係。工作成果準則:關聯式資料庫正推工程中,有提供「資料模型」元素及關係如何和「資料模型」元素及關係相對映的說明。

如果您是從使用持續性類別開始建立模型,而不是使用正規化的「邏輯資料模型」,您通常需要套用某些正規化,才能避免發生資料冗餘以及非索引鍵欄位相依關係。如需有關資料庫正規化的詳細資訊,請參閱概念:正規化

定義參照表格

目的 定義在整個專案中使用的標準參照表格。

通常在整個專案中,會使用標準查閱表格、驗證表格或參照表格。由於這些表格中的資料經常被存取,但是卻極少變更,因此那些資料就值得做特殊的考量。在「設計模型」中,這些表格可能會包含標準的產品程式碼、州/省 (縣/市) 代碼、郵遞區號碼、稅率表、區碼驗證表格,或是其他經常存取的資訊。在財務系統中,這些表格可能會包含原則代碼清單、保險原則等級分類或轉換率等。請在「設計模型」中,找出主要是作為唯讀,並為大量用戶端提供驗證資訊的類別。

如果參照表格很小,就不需要編製索引,因為索引作業可能會對小型表格造成額外的負荷。小型但卻經常被存取的表格,通常會保留在記憶體中,這是因為快取演算法通常會將經常存取的表格保留在資料快取記憶體中。

如果可能的話,請確定資料庫快取記憶體的大小足以將所有參照表格保留在記憶體中,並且有一般的「工作設定空間」可進行查詢和交易。提高資料庫效能的常用秘訣,是減少磁碟 I/O。

定義好參照表格架構後,則要決定用來將資料移入參照表格的策略。由於這些表格是在專案一開始時,就需要存取,因此會在應用程式執行時期的很早期,就需要決定參照值和載入表格。雖然資料庫設計師們並不負責取得資料,但他們卻要負責決定參照表格的參照方式以及參照時機。

建立主鍵及唯一限制

目的 定義一或多個直欄來唯一識別表格中的列。
定義直欄的限制,以保證資料或資料集合的唯一性。

主鍵是指一或多個直欄,用來唯一識別表格中的列。每個表格會有一個主鍵。通常表格會有一個「自然」鍵,可以用來唯一識別資料列(例如,參照表格中的郵遞區號)。主鍵不可包含很可能會隨商業環境變更的資料。如果「自然」鍵是會變更的值(例如,人員的姓名),我們建議資料庫設計師 在建立主鍵時,要建立一個沒有代表意義、不需要使用者輸入的直欄。如此將會建立一個資料結構,可以對商業結構、規則或環境變更具有極大的適應彈性。 

使用沒有代表意義、不需要使用者輸入的直欄作為主鍵,是設計資料倉儲的必要概念。交易式系統通常會選擇使用可能很少變更的直欄來作為「自然」主鍵,而不會選擇用沒有代表意義、不需要使用者輸入的直欄。

唯一限制會指定在直欄或直欄集合中的資料,在每一列中是唯一的。如果唯一限制是針對直欄,則在指定直欄的特定列中的資料,必須在相同直欄的其他列資料中具有唯一性。 

若針對一組直欄定義唯一限制時,其唯一特性是依據組成該唯一限制的所有直欄中的整體資料而定。在特定直欄的特定列中的資料,不需要在相同直欄的其他列資料中具有唯一性。資料庫設計師會使用唯一限制來確保商業資料的唯一性。

定義資料及參照完整性施行規則

目的 確保資料庫的完整性。

資料完整性規則亦稱為限制,可以確保資料值會維持在所定義的範圍內。若可以找到這些範圍時,資料庫就可以加以強制施行 (但這並不是說不需要在應用程式中進行資料驗證,這只是說若萬一應用程式無法正確運作,則可以將資料庫當作是「最終的驗證者」)。若有資料驗證規則存在時,就必須將資料庫限制設計為可施行那些驗證規則。

外部鍵是指表格中的一或多個直欄,對映到另一個表格中的主鍵。每個表格可以有多個外部鍵,並且每個外部鍵都會對映到不同的表格。表格之間的這種對映(或關係),通常稱為上下代關係。子表格中會包含外部鍵,此外部鍵會對映到母表格中的主鍵。 

查詢最佳化程式也常會使用外部鍵限制定義,來加速查詢效能。在許多情況下,外部鍵施行規則都是使用參照表格。 

反正規化資料庫設計以最佳化效能

目的 最佳化資料庫之資料結構的效能。

在關聯式「資料模型」中,起始的對映通常會產生出簡單的類別與表格對映。如果需要同時擷取不同類別中的物件時,RDBMS 就會使用一項稱為「表格合併」的作業,來擷取與屬意的物件相關的列。對於存取頻繁的資料而言,合併作業會耗費極多運算成本。為了刪除合併作業的成本,通常會採用稱為「反正規化」的標準關聯式技術。

反正規化會將兩個以上表格內的直欄合併成一個相同的表格,因此會有效率地預先合併資訊。反正規化突顯出可以將較昂貴的更新作業,改成較不昂貴的擷取作業。這項技術也可以對只要查詢已經在反正規化表格中有效合併的其中一個物件屬性的查詢系統,縮減效能,因為所有屬性通常都是在每一次查詢時就已擷取。對於應用程式通常需要所有屬性的情況而言,則可以顯著改善效能。

反正規化通常不會超過兩個表格,如果超過兩個表格,則不但會增加插入與更新的成本,也會增加非合併查詢的成本。除非有極重要且可信的證據可以證明反正規化多個表格的好處,否則將反正規化限制在兩個表格以內是較理想的原則。

如果類別是巢狀性的,則可以從設計類別中推斷反正規化。巢狀類別可以對映至反正規化表格。

有些物件資料庫容許使用和反正規化類似的概念,在這種概念中,相關的物件都會集合叢集在磁碟上,並在同一項作業內擷取。它所用的概念極相似:藉由減少系統從資料庫擷取相關的物件時需要執行的工作,來減少物件擷取時間。

在某些情況下,最佳化「資料模型」可以遮蔽設計模型中的問題,這包括效能瓶頸、建模不佳或設計不完整等。在這種情況下,請和類別的設計師進行問題討論,以激發適當的變更要求。

最佳化資料存取

目的 透過索引作業,提供有效率的資料存取。
透過資料庫概略表,提供有效率的資料存取。

設計好表格結構後,您必須決定要針對資料執行的查詢類型。索引作業是由資料庫用來加速存取速度。若直欄中用於編製索引的資料值相當特異時,索引作業的效率最高。

請考慮下列索引作業原則:

  • 表格的主鍵直欄一定要編製索引。主要鍵直欄常作為搜尋鍵及用於合併作業。
  • 表格大小若小於 100 列,並且只有少數幾個直欄,將享受不到索引作業的好處。小型表格通常可以輕易地放在資料庫快取記憶體中。
  • 對於經常執行的查詢,或是必須快速擷取資料的查詢(通常在執行任何查詢時,人員都必須等候),就應該定義索引。一起作為搜尋準則用的每一組屬性,都應該定義一個索引。比方說,如果系統需要找出有訂購某項特定產品的所有訂單時,就需要對「行項目」表格的產品號碼直欄建立索引。
  • 索引通常只應該針對當作識別碼用的直欄定義,但不可針對數值直欄定義,例如帳戶餘額,但不應該是如訂單備註的文字資訊。識別碼直欄值通常是在建立物件時指定,並且在該物件的生命週期內維持不變。
  • 針對簡單數字(整數及數字資料類型)定義的索引,要比字串的索引簡單且快速。因為在每個查詢或大型合併中處理的大量資料,使得小量的節省很快就會累積成大量節省。針對數值直欄定義的索引,通常要比字元索引節省許多空間。 

不過若往壞的方面看,使用索引並非完全免費;表格的索引愈多,插入及更新處理所花的時間就愈長。若要使用索引時,請記得下列預警:

  • 不要只是為了改善經常執行的查詢速度,而編製索引,除非該查詢是在重要情況時進行,並且需要以最快速度完成。
  • 在有些系統中,更新及插入的效能,要比查詢效能重要得多。常見的範例是工廠資料取得應用程式,此種應用程式必須即時擷取品質資料。在這種系統中,線上查詢只會偶爾進行,並且大部分的資料都是由批次產生報告應用程式分析,對資料執行統計分析。對於資料取得系統而言,移除所有索引將可以達到最傳輸量。需要索引的時候,則可以在執行批次報告及分析應用程式之前,重新建置索引,並於報告和分析作業完成時,刪除索引。
  • 一定要記得索引有其隱藏的成本在。例如,更新索引需要一些時間(在每次進行插入、更新或刪除時都需要花時間),並且會佔用磁碟空間。因此,請確定您可以獲得使用索引的價值。

許多資料庫都有提供索引類型選擇。最常見的類型包括:

  • B-tree 索引-這是最常用的索引,它是以平衡的 b-tree 索引資料結構為基礎。這種索引最適於索引鍵值是隨機分送,並且變化極大的情況。不過,若編製索引的資料已經處於循序次序時,它的效能卻很差。
  • 雜湊索引-較不常用,索引鍵值是雜湊形成的。如果已經知道索引鍵值的範圍,並且索引鍵值絕少更改且是唯一的時,雜湊索引可以提供很好的效能。這項技術仰賴使用鍵值來計算屬意的資料位址。由於它需要可預期能力,因此雜湊索引最適合用於很少變動的中型參考表。

您的索引策略選擇以及建立索引的時間,對效能會有很大的影響。載入大量資料時,不應該使用索引(這可以靠刪除索引、載入資料,然後重新建立索引來達成)。採取這個做法的原因,是因為當新增每一列時,就會重新平衡索引結構。由於後續的列將會變更最佳的索引結構,因此在插入每一列時所做的重新平衡索引工作都會形成浪費。如果沒有索引時載入資料的速度會較快且較有效率的話,則可以在載入資料之後,再重建索引。有些資料庫有提供大量資料載入程式,來自動執行此動作。

另一項最佳化資料庫存取效能的策略,是使用概略表。資料庫概略表是一些虛擬的表格,這些表格沒有自己的儲存體。不過,對呼叫端程式(或使用者)而言,概略表的行為就和表格一樣。概略表可以支援擷取資料,也可以用來更新資料,視資料庫結構和資料庫供應商而定。概略表包含來自一或多個表格的資料,這些表格資料可以用同一個 select 陳述式存取。在效能方面的增益,是在選取資料時發生,這對於經常查詢的表格尤然。資料是從單一位置,即概略表擷取,而不需要搜尋存在資料庫中的多個表格或大型表格。

概略表也對資料庫安全具有舉足輕重的角色。包含局部表格的概略表,可以限制存取基本表格中包含的機密資料。

定義儲存體

目的 設計資料庫的空間配置及磁碟分頁組織。

資料庫設計師會使用表格空間來代表已配置給表格、索引、儲存程序等等的儲存體空間數量。每個資料庫都會對映至一或多個表格空間。資料庫設計師必須分析「資料模型」中的表格,以決定如何將表格以及其他資料庫支援元素,分散在資料庫的儲存體空間中。

在決定資料庫的表格空間架構時,請記得資料庫並不會對列、記錄或甚至於整個表格執行 I/O。資料庫只會針對磁碟區塊執行 I/O。這個做法的原因很簡單:系統的軟體和硬體通常會最佳化區塊 I/O 作業。因此,資料庫中的表格與索引之實體組織,就會對系統的效能有顯著的影響。

在規劃資料庫的空間配置及磁碟分頁組織時,請考慮下列因素:

  • 磁碟分頁中的資訊密度
  • 磁碟分頁的位置是在一個磁碟上或分散在多個磁碟上
  • 要配置給表格的磁碟空間數量

這些因素會在以下的章節中討論。

磁碟分頁密度

磁碟分頁的密度,是視資料預期在往後會做的變更程度而定。通常,密度較低的分頁較能接受往後對值的變更或新增資料,但資料分頁較滿時,則可以提供較好的讀取效能,因為在讀取每個區塊時,可以讀取較多資料。

若要簡化磁碟管理作業,資料庫設計師可以依表格可能會更改的程度,將表格分組。下列三個群組可以組成這種組織類型的良好開端:

  • 極動態的表格
  • 略微動態的表格
  • 最靜態的表格

極動態的表格應該對映至具有大量可用空間的磁碟分頁(約 30%);略微動態的表格則應該對映至具有較少可用空間的磁碟分頁(約 15%);而最靜態的表格應該對映至具有很少可用空間的磁碟分頁(約 5%)。表格的索引也應該做與此類似的對映。

磁碟分頁位置

對映好表格群組之後,資料庫設計師就必須決定放置磁碟分頁的位置。這裡的目標,是要在將工作量分散到不同的磁碟機,以減少或消除瓶頸。請考慮下列準則:

  • 絕不要將資料放置在和作業系統、暫存檔或交換裝置相同的磁碟上。這些磁碟機即使沒有添加更多的工作量時,就已經很忙碌了。
  • 將會同步存取的資料放置在不同的磁碟機上,以平衡工作量。有些系統可支援平行 I/O 通道。如果是這種情況,則將資料放置在不同的通道上。
  • 將資料的索引放置在和用來編制索引的資料不同的磁碟機上,以分散工作量。
  • 請參閱資料庫供應商文件,取得這些準則。
  • 所使用的儲存體類型(例如 RAID-5、RAID-10、SAN、NAS 以及附加通道),會影響資料庫效能。請善用儲存體供應商提供的效能準則。

資料庫 I/O 通常就是限制資料庫效能的因素。I/O 平衡是一種反覆式,靠經驗的過程。在詳述階段建立資料庫存取效能的原型,以及使用適當的設備來監視實體與邏輯 I/O,您就可以在還有時間可以調整資料庫設計時,及早看出效能問題。

磁碟空間配置

使用持續性設計機制的特性,預估必須儲存的物件數。不同的 RDBMS 對儲存物件所需要的磁碟空間量各不相同。因此在計算磁碟空間數量時,務必將新增資料所造成的成長納入考慮。若要預估資料庫需要的磁碟空間,請先預估每個表格需要的磁碟空間,再計算所有表格的空間需求。請參考特定的 RDBMS 產品的資料庫管理手冊,來決定精確的大小預估公式。以下是預估表格的空間需求時,需要採取的一些一般步驟: 

  • 計算平均的列大小。這項計算應該包括記錄層次的所有控制資訊,以及可變長度直欄需要的任何控制資訊。 
  • 計算每個分頁或 I/O 區塊要涵蓋的列數。因為大部分的資料庫都只在每個分頁或 I/O 區塊儲存完整的記錄,因此這必須是可以納入一個分頁或 I/O 區塊的整數橫列數。 
  • 計算在資料庫中儲存預估的記錄數時,所需要的分頁或 I/O 區塊數。所預估的記錄數目必須包括任何載入因素。 
  • 將所需要的分頁或 I/O 區塊數乘上分頁或 I/O 區塊的大小。
  • 加上額外索引的任何額外負荷。
  • 加上表格的任何固定額外負荷。

定義好表格空間需求後:

  • 計算表格需要的空間總數。
  • 加上資料庫管理所需要的任何固定空間數量。
  • 加上交易日誌以及審核追蹤所需要的磁碟空間。 

在經常更新的環境中,若需要保留審核追蹤,將會耗用可觀的儲存體量。大部分的商用資料庫管理系統文件都會提供有關設定大小的詳細指示。在計算您的資料庫磁碟空間需求預估時,請務必要參考這些指示。

設計儲存程序以分送類別行為至資料庫

目的 判斷是否應該使用儲存程序或觸發程式,來實作資料存取類別作業。

大部分的資料庫都有支援儲存程序功能。儲存程序是可執行程式碼,可在資料庫管理系統的程序空間內執行。它提供在伺服器上執行與資料庫相關的動作,但不需要透過網路轉送資料。適度使用儲存程序可以改善系統的效能。

常用的儲存程序有兩種類型:實際的程序或觸發程式。程序是由應用程式明確地執行,通常會有參數,並且會提供明確的回覆值。另一方面,觸發程式則是在發生某些資料庫事件 (例如插入橫列、更新橫列或刪除橫列)時,隱含地啟動,除了要修改的橫列外,它沒有參數(因為它們只是隱含地啟動),並且不會提供明確的回覆值。

在沒有限制的資料庫系統中,通常會使用觸發程式來強制施行參照及資料完整性。不然的話,它們通常是在事件需要觸發(或導致)其他事件時使用。觸發程式也常用在安全用途,其做法是靠審核觸發事件。

必須審查「設計模型」中的設計類別,查看其中是否有作業應該要使用儲存程序或觸發機能來實作。可能的作業包括:

  • 主要是用來處理持續資料(建立、更新、擷取或刪除)的任何作業。
  • 計算作業(如計算庫存產品的平均數量和平均值)需要進行查詢的任何作業。
  • 必須存取資料庫以驗證資料的作業。

請記得,改善資料庫效能通常是表示減少 I/O。因此,如果對 DBMS 伺服器執行計算 可以減少透過網路傳送的資料數量時,就應該在伺服器上執行計算。

請和設計類別的設計師一起討論如何使用資料庫,以改善效能。設計師會更新作業方法,指出是否可以使用一或多個儲存程序來實作作業。

審查結果
目的 確保資料模型的品質與完整性。

在這項作業的整個過程中,您必須持續考量核對清單:資料模型,以評定投入努力的完整性和品質。此外,資料庫設計師也必須定期審查資料庫的實作結構,以確保「資料模型」和在資料庫中直接做的任何變更維持一致。如果專案使用的資料建模工具可以支援將「資料模型」和資料庫的實體結構同步化,資料庫設計師就必須定期核對「資料模型」和資料庫的狀態,並做必要的調整。   

目前無法更正的問題,必須記錄在變更要求中,並且指派由某個人擁有並驅使找出解決方案。

詳細資訊