1，數據庫設計概述

1.1，數據庫設計的基本概念

數據庫設計是指對于一個給定的應用環境，構造（設計）優化的數據庫邏輯模式和物理結構，并據此建立數據庫及其應用系統，使之能夠有效地存儲和管理數據，滿足各種用戶的應用需求，包括信息管理要求和數據操作要求。

數據庫設計的目標：是為用戶和各種應用系統提供一個信息基礎設施和高效率的運行環境 。

數據庫設計的基本任務：是根據用戶的信息需求、處理需求和數據庫的支持環境(包括硬件、操作系統和DBMS)，設計出數據庫模式(包括外模式、邏輯模式和內模式)及其典型的應用程序。

1.2，數據庫設計的方法

直觀設計法（手工試湊發）：數據庫設計只是一種經驗的反復實施，而不能稱為是一門科學，缺乏科學分析理論基礎和工程手段的支持，因為設計質量與設計人員的經驗和水平有直接關系，所以設計質量很難保證。具有周期短、效率高、操作簡便、易于實現等優點。主要是用于簡單小型系統。

規范設計法：將數據庫設計分為若干階段，明確規定各階段的任務，采用“自頂向下、分層實現、逐步求精”的設計原則，結合數據庫理論和軟件工程設計方法，實現設計過程的每一細節，最終完成整個設計任務。（新奧爾良方法、基于E-R模型的數據庫設計方法、基于3NF（第三范式）的設計方法、面向對象的數據庫設計方法、統一建模語言（UML）方法）。

計算機輔助設計法：在數據庫設計的某些過程中，利用計算機和一些輔助設計工具，模擬某一規范設計方法，并以人的知識或經驗為主導，通過人機交互方式實現設計中的某些部分。 （Oracle 公司開發的 Designer、Sybase公司開發的 PowerDesigner）。

1.3，數據庫設計的基本步驟

需求分析：通過詳細調查現實世界要處理的對象（組織、部門、企業等），充分了解原系統（手工系統或計算機系統）工作概況，明確用戶的各種需求。

概念結構設計：通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體數據庫管理系統的概念模型。

邏輯結構設計：將概念結構轉換為某個數據庫管理系統所支持的數據模型，并對其進行優化。

物理結構設計：為邏輯數據結構選取一個最適合應用環境的物理結構,包括存儲結構和存取方法。

數據庫實施：根據邏輯設計和物理設計的結果構建數據庫,編寫與調試應用程序,組織數據入庫并進行試運行。

數據庫運行和維護：經過試運行后即可投入正式運行,在運行過程中必須不斷對其進行評估、調整與修改。

★需求分析和概念設計獨立于任何數據庫管理系統

★邏輯設計和物理設計與選用的數據庫管理系統密切相關

設計階段	設計描述
	數據	處理
需求分析	數據字典、數據項、數據流、數據存儲的描述	數據流圖和判定樹、數據字典中處理過程的描述
概念結構設計	概念模型(ER圖)、數據字典	系統說明書 (系統要求、方案、概圖、數據流圖)
邏輯結構設計	某種數據模型(如關系)	系統結構圖(模塊結構)
物理設計	存儲安排、方法選擇、存取路徑建立	模塊設計
實施階段	編寫模式、裝入數據、數據庫試運行	程序編碼、編譯聯結、測試
運行維護	性能監測、轉儲/恢復、數據庫重組和重構	新舊系統轉換、運行、維護

2，需求分析

2.1，需求分析及其任務

需求分析就是分析用戶的需求：是設計數據庫的起點，結果是否準確地反映了用戶的實際要求，將直接影響到后面各個階段的設計，并影響到設計結果是否合理和實用。

需求分析的任務：由數據庫設計人員和用戶雙方共同收集信息需求和處理需求；通過仔細分析；將這些需求按一定的規范要求以用戶和設計人員都能理解接受的文檔形式確定下來。

2.2，需求分析的方法

需求分析的三個步驟：

①需求調查: 收集需求信息, 調查清楚用戶的實際要求, 與用戶達成共識。

②分析、整理和表達這些需求信息，形成需求說明書（例如，包括DFD和DD等）。

③評審：由主管部門和專家評價、審批。

需求調查

需求調查的目的：主要是了解企業的組織機構設置, 各個組織機構的職能、工作目標、職責范圍，主要業務活動及大致工作流程，獲得各個組織機構的業務數據及其相互聯系的信息，為分析整理工作做好前期基礎工作。

需求調查的內容：①組織機構的情況:? 組成, 職責, 作用, 現狀, 問題，哪些業務適合計算機管理, 哪些不適合。②各個部門的業務活動現狀(調查的重點):? 輸入和使用的數據, 加工處理方法, 數據的流程, 輸出的數據及格式, 注意收集原始數據資料, 如臺帳、單據、發票、收據、統計報表、文檔、檔案等。③外部要求：調查數據處理的響應時間、頻度和如何發生的規則，以及經濟效益的要求，安全性和完整性的要求。④協助用戶明確對新系統的各種要求(調查的又一個重點): 信息要求, 處理要求, 安全性要求, 完整性要求, 未來規劃中對數據的應用需求等。⑤確定新系統的邊界: 哪些由計算機完成, 哪些由人工完成。

需求調查的步驟：①調查組織機構情況。②調查各部門的業務活動情況。③協助用戶明確對新系統的各種要求，包括信息要求、處理要求、完全性與完整性要求。④確定新系統的邊界。

需求調查的方式：①跟班作業：通過親身參加業務工作了解業務活動的情況。②開調查會：通過與用戶座談來了解業務活動情況及用戶需求。③請專人介紹。④詢問：對某些調查中的問題，可以找專人詢問。⑤設計調查表請用戶填寫：調查表設計合理，則很有效。⑥查閱記錄：查閱與原系統有關的數據記錄。

需求調查策略：

• 對高層負責人的調查: 一般采用個別交談方式, 先給一份詳細的調查提綱, 以便有所準備。
• 對中層管理人員的調查: 可采用開座談會, 個別交談, 發調查表, 查閱記錄的調查方式。
• 對基層業務人員的調查: 主要采用發調查表, 個別交談或跟班作業的調查方式。

分析整理

分析整理的工作：

①業務流程分析和表示

• 目的是獲得業務流程及業務與數據聯系的形式描述。
• 采用數據流層次結構分析法(SA法)。
• 分析結果以數據流圖(DFD圖)表示, 再輔以數據字典(DD)作補充描述。

②需求信息的補充描述

• 數據字典: 主要用于概念結構設計。
• 業務活動清單: 列出每一部門中最基本的工作任務。
• 其他需求清單: 如完整性、安全性、一致性要求。

③撰寫需求分析說明書

分析整理的方法：結構化分析方法（SA方法）

SA方法從最上層的系統組織機構入手，采用自頂向下、逐層分解的方式分析系統。

SA步驟：a)先把任何一個系統都抽象為DFD圖形式。b)然后從最上層的系統組織機構入手，采用自頂向下，逐步分解，逐步求精的方式分析系統，獲得多層DFD圖。

數據流圖（DFD）

軟件工程：可行性研究_燕雙嚶的博客-CSDN博客_軟件可行性研究

數據字典（DD）

軟件工程：可行性研究_燕雙嚶的博客-CSDN博客_軟件可行性研究

3，概念結構設計

3.1，概念模型

概念結構設計：將需求分析得到的用戶需求抽象為信息結構（即概念模型）的過程。

目前應用最普遍的是實體關系（E-R）模型，它將現實世界的信息結構統一用屬性、實體以及它們之間的聯系來描述。

3.2，E-R概念模型

數據庫：實體關系圖（ER圖）_燕雙嚶的博客-CSDN博客_er圖關系

3.3，概念結構設計

實體與屬性的劃分

為了簡化E-R圖的處置，現實世界的事物能作為屬性對待的，盡量作為屬性對待。

兩條準則：①作為屬性，不能再具有需要描述的性質。屬性必須是不可分的數據項，不能包含其他屬性。②屬性不能與其他實體具有聯系，即E-R圖中所表示的聯系是實體之間的聯系。

4，邏輯結構設計

4.1，邏輯結構設計概述

邏輯結構設計的任務：將概念結構轉換成特定DBMS所支持的數據模型的過程。關系數據庫邏輯設計的結果是一組關系模式的定義 。

邏輯結構設計的步驟：

①將概念結構轉換為一般的關系、網狀、層次模型；

②將轉換來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換；

③對數據模型進行優化。

關系數據庫邏輯設計的步驟

①將概念模型(例如基本E-R圖)轉換為關系模式的集合 --- 得到關系數據庫模式；

②運用關系數據理論對關系數據庫模式進行規范化處理；

③對關系數據庫模式進行評價；

④對關系數據庫模式進行修正；

⑤設計關系子模式 --- 視圖。

4.2，ER圖向關系模型的轉換

一個實體轉換為一個關系模式

原則：關系的屬性=實體型的屬性；關系的碼=實體型的碼；關系模式的碼(用下橫線標出) = 實體型的碼；

轉換為：學生(學號，姓名，系別)

每個聯系類型轉換為獨立的關系模式

原則：關系模式的屬性 = 與該聯系相連的各實體型的碼+該聯系自身的屬性；關系模式的碼(用下劃線標出) = 各實體型的碼；

①一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并

轉換為一個獨立的關系模式，原則：關系模式的屬性 = 與該聯系相連的各實體型的碼? +? 該聯系自身的屬性；關系模式的碼(用下劃線標出) = 各實體型的碼；

與某一端實體對應的關系模式合并，原則：合并后關系的屬性=加入對應關系的碼和聯系本身的屬性；合并后關系的碼不變；

②一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。

轉換為一個獨立的關系模式，原則：關系模式的屬性 = 與該聯系相連的各實體型的碼? +? 該聯系自身的屬性；關系模式的碼(用下劃線標出) = n端實體的碼；

與某一端實體對應的關系模式合并，原則：合并后關系的屬性=在n端關系中加入1端關系的碼和聯系本身的屬性；合并后關系的碼不變；

③一個m:n聯系必須轉換為一個獨立的關系模式

轉換為一個獨立的關系模式，原則：關系模式的屬性 = 與該聯系相連的各實體型的碼? +? 該聯系自身的屬性；關系模式的碼(用下劃線標出) =各實體碼的組合；

④三個或三個以上實體間的一個多元聯系轉換為一個關系模式，原則：關系模式的屬性 = 與該聯系相連的各實體型的碼? +? 該聯系自身的屬性；關系模式的碼(用下劃線標出) =各實體碼的組合；

⑤具有相同碼的關系模式可合并

目的：減少系統中的關系個數

合并方法：

• 將其中一個關系模式的全部屬性加入到另一個關系模式中
• 然后去掉其中的同義屬性（可能同名也可能不同名）
• ?適當調整屬性的次序

把每一個實體裝換為一個關系

首先分析各實體的屬性，從中確定其主鍵，然后分別用關系模式表示。

實體：學生 對應的關系：學生（學號，姓名，性別，年齡） 實體：課程 對應的關系：課程（課程號，課程名） 實體：教師 對應的關系：教師（教師號，姓名，性別，職稱） 實體：系 對應的關系：系（系名，電話）

把每一個聯系裝換為關系模式

將4個聯系轉換為關系模式，其中2個多對多類型的聯系轉換為獨立關系模式，2個一對多的聯系也轉換為獨立的關系模式。

聯系：屬于 對應的關系：屬于（教師號，系名） 聯系：講授 對應的關系：講授（教師號，課程號） 聯系：選修 對應的關系：選修（學號，課程號，成績） 聯系：擁有 對應的關系：擁有（學號，系名）

畫出關系圖

4.3，數據模型的優化

數據庫邏輯設計的結果不是唯一的，得到初步數據模型后，還應該適當地修改、調整數據模型的結構，以進一步提高數據庫應用系統的性能，這就是數據模型的優化。

★規范化過程可分為兩個步驟：確定范式級別，實施規范化處理

①確定數據依賴：寫出每個關系模式內部各屬性之間的數據依賴；寫出不同關系模式的屬性(外碼和主碼)之間的數據依賴；

②對于各個關系模式之間的數據依賴進行極小化處理，消除冗余的聯系。

③按照數據依賴的理論對關系模式進行分析，考察是否存在部分函數依賴、傳遞函數依賴、多值依賴等，確定各關系模式分別屬于第幾范式。

④按照需求分析階段得到的各種應用對數據處理的要求，分析對于這樣的應用環境這些模式是否合適，確定是否要對它們進行合并或分解。（并不是規范化程度越高的關系就越優。當一個應用的查詢中經常涉及到兩個或多個關系模式的屬性時，系統必須經常地進行連接運算，而連接運算的代價是相當高的，可以說關系模型低效的主要原因就是做連接運算引起的，因此在這種情況下，第二范式甚至第一范式也許是最好的。）

⑤對關系模式進行必要的分解，提高數據操作的效率和存儲空間的利用率。常用的兩種分解方法是水平分解和垂直分解。

• 水平分解：把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統的效率。
• 垂直分解：把關系模式R的屬性分解為若干子集合，形成若干子關系模式。

4.4，設計用戶子模式（外模式）

將概念模型轉換為邏輯模型(數據庫模式)后, 還應根據局部應用的需求, 結合具體DBMS的特點, 設計用戶的外(子)模式 。利用RDBMS提供的視圖(View)功能設計。

定義用戶外模式時應該更注重考慮用戶的習慣與方便。包括三個方面：①使用更符合用戶習慣的別名。②針對不同級別的用戶定義不同的視圖，以保證系統的安全性。③簡化用戶對系統的使用。

視圖：數據庫：SQL語言，索引，連接查詢，視圖_燕雙嚶的博客-CSDN博客

5，物理結構設計

數據庫的物理結構：數據庫在物理設備上的存儲結構與存取方法稱為數據庫的物理結構，它依賴于選定的數據庫管理系統。

數據庫的物理設計：為一個給定的邏輯數據模型選取一個最適合應用要求的物理結構的過程，就是數據庫的物理設計。

數據庫物理設計的步驟：①確定數據庫的物理結構，在關系數據庫中主要指存取方法和存儲結構;②對物理結構進行評價，評價的重點是時間和空間效率；若評價結果滿足原設計要求，則可進入到物理實施階段。否則，就需要重新設計或修改物理結構，有時甚至要返回邏輯設計階段修改數據模型。

5.1，數據庫物理設計的內容和方法

準備工作：①要充分了解應用環境，詳細分析要運行的事務。以獲得選擇物理數據庫設計所需要的參數。分析數據庫查詢事務需要的信息、數據更新事務需要的信息、每個事務在各關系上運行的頻率和性能要求等。②要充分了解所用的 DBMS的內部特征, 特別是系統提供的存取方法和存儲結構。

內容：①為關系模式選擇存取方法，即要確定選擇哪些存取方法，建立哪些存取路徑。②設計關系(表)、聚簇、索引、日志、備份等數據的物理存儲結構。

5.2，關系模式存取方法選擇

數據庫系統是多用戶共享的系統，對同一個關系要建立多條存取路徑才能滿足多用戶的多種應用要求。

數據庫關系系統：①B+樹索引存取方法；②Hash索引存取方法；③聚簇存取方法；

B+樹索引

選擇索引存取方法 就是根據應用要求確定：對哪些屬性列建立索引、對哪些屬性列建立組合索引、對哪些索引要設計為唯一索引。

選賊索引存取方法的一般規則：

• 如果一個（或一組）屬性經常在查詢條件中出現，則考慮在這個（或這組）屬性上建立索引（或組合索引）
• 如果一個屬性經常作為最大值和最小值等聚集函數的參數，則考慮在這個屬性上建立索引
• 如果一個（或一組）屬性經常在連接操作的連接條件中 出現，則考慮在這個（或這組）屬性上建立索引

關系上定義的索引數過多會帶來較多的額外開銷，無論是維護還是查找

HASH存取方法

選擇Hash存取方法的規則：如果一個關系的屬性主要出現在等值連接條件中或主要出現在等值比較選擇條件中，而且滿足下列兩個條件之一

• 該關系的大小可預知，而且不變；
• 該關系的大小動態改變，但所選用的數據庫管理系統提供了動態Hash存取方法。

聚簇存取方法

為了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱為聚簇碼）上具有相同值的元組集中存放在連續的物理塊上，稱為聚簇。該屬性（或屬性組）稱為聚簇碼。許多關系型數據庫管理系統都提供了聚簇功能。

聚簇索引：建立聚簇索引后，基表中數據也需要按指定的聚簇屬性值的升序或降序存放。也即聚簇索引的索引項順序與表中元組的物理順序一致。一個數據庫可以建立多個聚簇，一個關系只能加入一個聚簇。

聚簇索引的適用條件：很少對基表進行增刪操作；很少對其中的變長列進行修改操作；

聚簇索引的用圖：

• 大大提高按聚簇屬性進行查詢的效率
• 節省存儲空間：聚簇以后，聚簇碼相同的元組集中在一起了，因而聚簇碼值不必在每個元組中重復存儲，只要在一組中存一次就行了。

聚簇索引的局限性：

• 聚簇只能提高某些特定應用的性能
• 建立與維護聚簇的開銷相當大；對已有關系建立聚簇，將導致關系中元組的物理存儲位置移動，并使此關系上原有的索引無效，必須重建。當一個元組的聚簇碼改變時，該元組的存儲位置也要做相應改變。

聚簇索引的適用范圍：

• 既適用于單個關系獨立聚簇，也適用于多個關系組合聚簇
• 當通過聚簇碼進行訪問或連接是該關系的主要應用，與聚簇碼無關的其他訪問很少或者是次要的時，可以使用聚簇。尤其當SQL語句中包含有與聚簇碼有關的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短語時，使用聚簇特別有利，可以省去或減化對結果集的排序操作

設計候選聚簇：①常在一起進行連接操作的關系可以建立組合聚簇；

②如果一個關系的一組屬性經常出現在相等比較條件中，則該單個關系可建立聚簇；

③如果一個關系的一個（或一組）屬性上的值重復率很高，則此單個關系可建立聚簇。

檢查候選聚簇索引中的關系，取消不必要的關系

①從聚簇中刪除經常進行全表掃描的關系

②從聚簇中刪除更新操作遠多于連接操作的關系

③從聚簇中刪除重復出現的關系

5.3，確定數據庫的存儲結構

確定數據庫物理結構主要指確定數據的存放位置和存儲結構，包括：確定關系、索引、聚簇、日志、備份等的存儲安排和存儲結構，確定系統配置等。

影響數據存放位置和存儲結構的因素：硬件環境和應用需求；要綜合考慮存取時間、存儲空間利用率和維護代價（這三個方面常常是相互矛盾的。比如：消除一切冗余數據雖能夠節約存儲空間和減少維護代價，但往往會導致檢索代價的增加。必須進行權衡，選擇一個折中方案。）

確定數據的存放位置

原則：根據應用情況將易變部分與穩定部分分開存放，經常存取部分與存取頻率較低部分分開存放。

①可以將日志文件與數據庫對象（表、索引等）放在不同的磁盤以改進系統的性能。

②可以將比較大的表分別放在兩個磁盤上，以加快存取速度，這在多用戶環境下特別有效。

③數據庫數據備份、日志文件備份等由于只在故障恢復時才使用，而且數據量很大，可以考慮存放在磁帶上。

確定系統配置

①系統都為這些變量（同時使用數據庫的用戶數、同時打開的數據庫對象數、內存分配參數、緩沖區分配參數（使用的緩沖區長度、個數）、存儲分配參數 、物理塊的大小、物理塊裝填因子、時間片大小、數據庫的大小、鎖的數目等）賦予了合理的缺省值。在進行物理設計時需要根據應用環境確定這些參數值，以使系統性能最優。

②在物理設計時對系統配置變量的調整只是初步的，要根據系統實際運行情況做進一步的調整，以切實改進系統性能。

5.4，評價物理結構

評價物理數據庫的方法完全依賴于所選用的DBMS 。

評價內容：

• 對數據庫物理設計過程中產生的多種方案進行細致的評價；
• 定量估算各種方案的存儲空間、存取時間、維護代價；
• 對估算結果進行權衡、比較，從中選擇一個較優的合理的方案作為數據庫的物理結構。

6，數據庫的實施和維護

6.1，數據的載入和應用程序的調試

數據庫實施階段主要工作：

①建立實際的數據庫結構。用DDL定義數據庫：定義基本表、索引、約束、視圖等；

②裝入數據，組織數據入庫(又稱數據庫加載)，組織數據入庫是數據庫實施階段最主要的工作。

• 數據裝載方法：人工方法；計算機輔助方法
• 數據篩選、輸入、轉換(工具)、校驗，確保正確

③編制和調試數據庫應用程序。數據庫應用程序的設計應該與數據庫設計并行進行。數據庫結構建立好后，就可以開始編制與調試數據庫的應用程序。

6.2，數據庫的試運行

數據庫的試運行：應用程序調試完成，并且已有一小部分數據入庫后，就可以開始對數據庫系統進行聯合調試，也稱數據庫的試運行。

主要工作包括：

①功能測試：實際運行應用程序，執行對數據庫的各種操作，測試應用程序的各種功能。

②性能測試：測量系統的性能指標，分析是否符合設計目標。

★數據庫性能指標的測量

①數據庫物理設計階段在評價數據庫結構估算時間、空間指標時，作了許多簡化和假設，忽略了許多次要因素，因此結果必然很粗糙。

②數據庫試運行則是要實際測量系統的各種性能指標（不僅是時間、空間指標），如果結果不符合設計目標，則需要返回物理設計階段，調整物理結構，修改參數；有時甚至需要返回邏輯設計階段，調整邏輯結構。

★數據的分期入庫

①重新設計物理結構甚至邏輯結構，會導致數據重新入庫

②由于數據入庫工作量實在太大，所以可以采用分期輸入數據的方法

• 先輸入小批量數據供先期聯合調試使用
• 待試運行基本合格后再輸入大批量數據
• 逐步增加數據量，逐步完成運行評價

★數據庫的轉儲和恢復

①在數據庫試運行階段，系統還不穩定，硬、軟件故障隨時都可能發生

②系統的操作人員對新系統還不熟悉，誤操作也不可避免

③因此必須做好數據庫的轉儲和恢復工作，盡量減少對數據庫的破壞

6.3，數據庫的運行和維護

在數據庫運行階段，對數據庫經常性的維護工作主要是由數據庫管理員完成的，包括：

①數據庫的轉儲和恢復

• 數據庫管理員要針對不同的應用要求制定不同的轉儲計劃，定期對數據庫和日志文件進行備份。
• 一旦發生介質故障，即利用數據庫備份及日志文件備份，盡快將數據庫恢復到某種一致性狀態

②數據庫的安全性、完整性控制

初始定義

• 數據庫管理員根據用戶的實際需要授予不同的操作權限
• 根據應用環境定義不同的完整性約束條件

修改定義

• 當應用環境發生變化，對安全性的要求也會發生變化，數據庫管理員需要根據實際情況修改原有的安全性控制
• 由于應用環境發生變化，數據庫的完整性約束條件也會變化，也需要數據庫管理員不斷修正，以滿足用戶要求

③數據庫性能的監督、分析和改進

在數據庫運行過程中，數據庫管理員必須監督系統運行，對監測數據進行分析，找出改進系統性能的方法。

• 利用監測工具獲取系統運行過程中一系列性能參數的值
• 通過仔細分析這些數據，判斷當前系統是否處于最佳運行狀態
• 如果不是，則需要通過調整某些參數來進一步改進數據庫性能

④數據庫的重組織與重構造

數據庫的重組織

• 為什么要重組織數據庫?? 數據庫運行一段時間后，由于記錄的不斷增、刪、改，會使數據庫的物理存儲變壞，從而降低數據庫存儲空間的利用率和數據的存取效率，使數據庫的性能下降。
• 重組織的形式：全部重組織和部分重組織，只對頻繁增、刪的表進行重組織
• 重組織的目標：提高系統性能

數據庫的重構造

• 為什么要重構造數據庫? 數據庫應用環境發生變化，會導致實體及實體間的聯系也發生相應的變化，使原有的數據庫設計不能很好地滿足新的需求。
• 重構造的主要工作? 根據新環境調整數據庫的模式和內模式增加或刪除某些數據項、改變數據項的類型、增加或刪除某個表、改變數據庫的容量、增加或刪除某些索引。
• 重構造數據庫的程度是有限的? 若應用變化太大，已無法通過重構數據庫來滿足新的需求，或重構數據庫的代價太大，? 則表明現有數據庫應用系統的生命周期已經結束，應該重新設計新的數據庫應用系統了。

總結

以上是生活随笔為你收集整理的数据库：数据库设计（需求，设计，运行，维护）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。