資料庫設計/資料庫開發流程

軟體工程的核心方面是將開發過程細分為一系列階段或步驟，每個階段都專注於開發的一個方面。這些步驟的集合有時被稱為軟體開發生命週期 (SDLC)。軟體產品會經歷這個生命週期（有時會隨著它被改進或重新開發而重複），直到最終從使用中退休。理想情況下，生命週期的每個階段都可以在進入下一階段之前檢查其正確性。

軟體開發生命週期 - 瀑布模型

讓我們從瀑布模型的概述開始，就像您在大多數軟體工程教科書中看到的那樣。如圖 13.1 所示，這個瀑布模型圖說明了一個通用的瀑布模型，可以應用於任何計算機系統開發。它將流程顯示為一個嚴格的步驟序列，其中一個步驟的輸出是下一個步驟的輸入，並且必須完成一個步驟的所有內容才能進入下一個步驟。

圖 13.1. 瀑布模型。

我們可以使用瀑布流程作為一種方法來識別所需的任務，以及每個活動的輸入和輸出。重要的是活動的範圍，可以總結如下

建立需求涉及與利益相關者進行協商，並在利益相關者之間達成一致，以確定他們希望從系統中獲得什麼，並將其表達為需求說明。
分析從考慮需求說明開始，並以生成系統規格說明結束。規格說明是系統應該做什麼的正式表示，以獨立於其實現方式的方式表達。
設計從系統規格說明開始，生成設計文件，並提供有關如何構建系統的詳細說明。
實施是根據給定的設計文件構建計算機系統，並考慮到系統將執行的環境（例如，開發中可用的特定硬體或軟體）。實施可以分階段進行，通常從一個初始系統開始，該系統可以在釋出最終系統以供使用之前進行驗證和測試。
測試將實現的系統與設計文件和需求規格說明進行比較，並生成驗收報告，或者更常見的是生成需要分析、設計和實施過程審查以糾正的錯誤和缺陷列表（測試通常是導致瀑布模型在生命週期中迭代的任務）。
維護涉及處理需求或實施環境的變化，修復缺陷或將系統移植到新環境（例如，將系統從獨立的 PC 遷移到 UNIX 工作站或網路環境）。由於維護涉及對所需更改的分析、解決方案的設計、該解決方案的實施和測試，因此在維護軟體系統的整個生命週期中，瀑布生命週期將被反覆重新訪問。

資料庫生命週期

我們可以使用瀑布週期作為資料庫開發模型的基礎，該模型包含三個假設

我們可以將資料庫的開發（即，定義資料庫中資料的模式的規範和建立）與使用資料庫的使用者程序分開。
我們可以使用三級模式體系結構作為區分與模式相關的活動的基礎。
我們可以將約束表示為在資料庫中強制執行一次以強制執行資料的語義，而不是在使用資料的每個使用者程序中都表示一次。

圖 13.2. 資料庫開發活動的模型及其輸出。

使用這些假設和圖 13.2，我們可以看到該圖代表了資料庫開發活動的模型及其輸出。它適用於任何類別的 DBMS，而不僅僅是關係方法。

資料庫應用程式開發是獲取現實世界需求、分析需求、設計系統的資料和功能，然後在系統中實現操作的過程。

需求收集

第一步是需求收集。在此步驟中，資料庫設計人員必須與客戶（資料庫使用者）進行訪談，以瞭解提議的系統並獲取和記錄資料和功能需求。此步驟的結果是包含使用者提供詳細需求的文件。

建立需求涉及與所有使用者進行協商，並與所有使用者達成一致，以確定他們希望儲存哪些持久資料，以及對資料元素的含義和解釋達成一致。資料管理員在這一過程中發揮著關鍵作用，因為他們概述了組織內部影響資料需求的業務、法律和道德問題。

資料需求文件用於確認與使用者對需求的理解。為了確保易於理解，它不應過於正式或高度編碼。該文件應簡要概述所有使用者的需求，而不僅僅是一些人的需求，因為目的是開發一個共享的資料庫。

需求不應描述如何處理資料，而應描述資料項是什麼、它們有哪些屬性、適用哪些約束以及資料項之間存在哪些關係。

分析

資料分析從資料需求說明開始，然後生成一個概念資料模型。分析的目的是獲得對資料的詳細描述，以滿足使用者需求，從而處理資料的高階和低階屬性及其使用。這些屬性包括允許的屬性值範圍（例如，在學校資料庫示例中，學生的課程程式碼、課程名稱和學分）。

概念資料模型提供了在資料庫開發過程中客戶和開發人員之間溝通內容的共享正式表示 - 它專注於資料庫中的資料，而不考慮該資料在使用者程序中的最終使用或在特定計算機環境中的實施。因此，概念資料模型關注資料的含義和結構，而不關注影響其實現方式的細節。

然後，概念資料模型是對資料庫應包含的資料和資料必須滿足的約束的正式表示。這應該以獨立於模型實現方式的方式表達。因此，分析集中在“需要什麼？”這個問題上，而不是“如何實現？”

邏輯設計

資料庫設計從一個概念資料模型開始，並生成一個邏輯模式的規範；這將確定所需資料庫系統的具體型別（網路、關係、面向物件）。關係表示仍然獨立於任何特定 DBMS；它是另一個概念資料模型。

我們可以使用概念資料模型的關係表示作為邏輯設計過程的輸入。此階段的輸出是所有表格和約束的詳細關係規範（邏輯模式），這些表格和約束需要滿足概念資料模型中資料的描述。正是在這個設計活動中，才會對哪些表格最適合表示資料庫中的資料做出選擇。這些選擇必須考慮各種設計標準，包括例如靈活性的變化、重複控制以及如何最好地表示約束。由邏輯模式定義的表格決定了資料庫中儲存的資料以及如何操作這些資料。

熟悉關係資料庫和 SQL 的資料庫設計人員可能會在生成概念資料模型後直接進入實施階段。但是，將關係表示直接轉換為 SQL 表格並不一定會導致具有所有理想屬性的資料庫：完整性、完整性、靈活性、效率和可用性。一個好的概念資料模型是具有這些屬性的資料庫的必要第一步，但這並不意味著直接轉換為 SQL 表格會自動生成一個好的資料庫。第一步將準確地表示滿足概念資料模型描述所需的所有表格和約束，因此將滿足完整性和完整性要求，但它可能不靈活或提供較差的可用性。然後對第一個設計進行彎曲以提高資料庫設計的質量。彎曲是一個術語，旨在捕捉將某物彎曲以用於不同目的以及在彎曲時削弱其某些方面的同時想法。

圖 13.3 總結了資料庫設計中涉及的迭代（重複）步驟，基於給出的概述。它的主要目的是區分應該使用哪些表的總體問題以及每個表的組成部分的詳細定義 - 這些表被逐個考慮，儘管它們並不相互獨立。每次涉及表修訂的迭代都將導致新的設計；它們通常被稱為二次設計，即使該過程迭代了不止一個迴圈。

圖 13.3。資料庫設計中涉及的迭代步驟的總結。

首先，對於給定的概念資料模型，並非所有它代表的使用者需求都需要由單個數據庫滿足。開發多個數據庫可能有各種原因，例如在不同位置需要獨立執行或部門對“其”資料的控制。但是，如果資料庫集合包含重複資料，並且使用者需要訪問多個數據庫中的資料，那麼可能存在一個數據庫可以滿足多個需求的原因，或者需要檢查與資料複製和分發相關的問題。

其次，關於資料庫開發的一個假設是，我們可以將資料庫的開發與使用它的使用者程序的開發分開。這是基於這樣的預期，即一旦資料庫被實施，所有當前識別出的使用者程序所需的資料都已定義並可以訪問；但我們也需要靈活性，以便能夠滿足未來的需求變化。在為某些應用程式開發資料庫時，可能能夠預測將向資料庫提出的常見請求，因此我們可以針對最常見的請求最佳化我們的設計。

第三，在詳細級別上，資料庫設計和實施的許多方面取決於使用的特定 DBMS。如果 DBMS 的選擇是固定的，或者在設計任務之前完成，那麼該選擇可用於確定設計標準，而不是等到實施時才確定。也就是說，可以將針對特定 DBMS 的設計決策納入，而不是生成通用設計，然後在實施過程中將其定製為 DBMS。

通常會發現，單個設計無法同時滿足良好資料庫的所有屬性。因此，重要的是設計人員要優先考慮這些屬性（通常使用來自需求規範的資訊）；例如，要決定在給定開發中，完整性是否比效率更重要，以及可用性是否比靈活性更重要。

在我們的設計階段結束時，邏輯模式將由 SQL 資料定義語言 (DDL) 語句指定，這些語句描述了需要實施以滿足使用者需求的資料庫。

實施

實施包括根據邏輯模式的規範構建資料庫。這將包括指定適當的儲存模式、安全執行、外部模式等等。實施受可用 DBMS、資料庫工具和操作環境的選擇的影響很大。除了簡單地建立資料庫模式和實施約束之外，還有其他任務 - 資料必須輸入表中，需要解決與使用者和使用者程序相關的問題，以及與公司資料管理更廣泛方面的管理活動需要得到支援。為了保持與 DBMS 方法的一致性，我們希望儘可能多地將這些問題在 DBMS 中解決。我們現在簡要地看一下其中的一些問題。

在實踐中，在給定 DBMS 中實施邏輯模式需要非常詳細地瞭解 DBMS 所提供的特定功能和設施。在理想情況下，為了保持良好的軟體工程實踐，實施的第一階段將涉及將設計要求與最佳可用實施工具進行匹配，然後使用這些工具進行實施。用資料庫術語來說，這可能涉及選擇最適合我們需要實施的資料庫的 DBMS 和 SQL 變體的供應商產品。但是，我們並不生活在一個理想的世界中，而且通常硬體選擇和關於 DBMS 的決策是在考慮資料庫設計之前就做出的。因此，實施可能涉及對設計進行額外的調整，以克服任何軟體或硬體限制。

實現設計

建立邏輯設計後，我們需要根據我們生成的設計建立資料庫。對於使用關係型 DBMS 的實施，這可能涉及使用 SQL 建立滿足邏輯模式描述的表和約束，以及選擇適當的儲存模式（如果 DBMS 允許該級別的控制）。

實現這一點的一種方法是將適當的 SQL DDL 語句寫入一個檔案，該檔案可以由 DBMS 執行，以便存在一個獨立的記錄，一個文字檔案，其中包含定義資料庫的 SQL 語句。另一種方法是使用像 SQL Server Management Studio 或 Microsoft Access 這樣的資料庫工具進行互動式操作。無論使用何種機制來實施邏輯模式，結果都是定義了一個數據庫，它具有表和約束，但不會包含使用者程序的任何資料。

填充資料庫

建立資料庫後，有兩種方法可以填充表 - 來自現有資料或透過使用為資料庫開發的使用者應用程式。

對於某些表，可能存在來自另一個數據庫或資料檔案的資料。例如，在為醫院建立資料庫時，您會期望已經存在一些必須包含在資料庫中的所有員工的記錄。資料也可能來自外部機構（地址列表通常來自外部公司）或在大量資料輸入任務期間產生（將硬複製的手動記錄轉換為計算機檔案可以由資料輸入機構完成）。在這種情況下，填充資料庫的最簡單方法是使用 DBMS 中提供的匯入和匯出功能。

通常提供用於以各種標準格式匯入和匯出資料的工具（在某些系統中，這些功能也被稱為載入和解除安裝資料）。匯入允許將資料檔案直接複製到表中。當資料儲存在不適合使用匯入功能的檔案格式中時，則需要準備一個應用程式，該應用程式讀取舊資料，根據需要進行轉換，然後使用專門為此目的生成的 SQL 程式碼將其插入資料庫。將大量現有資料傳輸到資料庫被稱為批次載入。批次載入資料可能涉及將大量資料載入到一個表中，因此您可能會發現 DBMS 提供的功能可以將約束檢查推遲到批次載入結束時進行。

開發 ER 圖的指南

注意：這些是一般指南，將有助於為實際資料庫設計（邏輯模型）奠定堅實的基礎。

記錄在資訊收集階段發現的所有實體。
記錄屬於每個實體的所有屬性。選擇候選鍵和主鍵。確保每個實體的所有非鍵屬性都完全依賴於主鍵。
開發初始 ER 圖，並與相關人員進行審查。（請記住，這是一個迭代過程。）
為多值屬性和重複組建立新實體（表）。將這些新實體（表）納入 ER 圖。與相關人員進行審查。
透過規範化表來驗證 ER 建模。

關鍵詞

分析: 從考慮需求陳述開始，以生成系統規範結束

批次載入: 將大量現有資料傳輸到資料庫

資料需求文件: 用於確認對使用者需求的理解

設計: 從系統規範開始，生成設計文件，並提供有關如何構建系統的詳細描述

建立需求: 涉及與利益相關者協商並達成一致，以確定他們對系統的期望；以需求陳述的形式表達

彎曲: 一個術語，它捕捉了將某物彎曲用於不同目的以及在彎曲時削弱其某些方面的同時存在的想法

實施: 根據給定的設計文件構建計算機系統

維護: 涉及處理需求或實施環境的變化、錯誤修復或將系統移植到新的環境

需求收集: 資料庫設計人員採訪資料庫使用者以瞭解擬議系統，並獲取和記錄資料和功能需求的過程

二次設計: 所有迭代的集合，每次迭代都涉及表修訂，從而導致新的設計

軟體開發生命週期 (SDLC): 資料庫開發過程中涉及的一系列步驟

測試: 將已實施的系統與設計文件和需求規範進行比較，並生成驗收報告

瀑布模型: 將資料庫開發過程顯示為嚴格的步驟序列，其中一個步驟的輸出是下一個步驟的輸入

瀑布過程: 識別資料庫開發所需任務的一種方法，以及每個活動的輸入和輸出（參見瀑布模型）。

練習

描述瀑布模型。列出步驟。
SDLC的首字母縮略詞是什麼意思？SDLC描述了什麼？
為了適應資料庫設計，瀑布模型需要哪些修改？
提供資料庫設計中涉及的迭代步驟。

歸屬

本節《資料庫設計》（包括所有影像，除非另有說明）是開放大學的《資料庫開發生命週期》的衍生作品，根據知識共享署名-非商業性使用-相同方式共享 3.0 許可證授權。

以下內容由 Adrienne Watt 撰寫。

關鍵詞
練習

參考文獻

BCOpenCampus：資料庫設計

← 規範化

資料庫設計

資料庫使用者 →