資料庫需求設計

『壹』 資料庫的需求分析方法

資料庫設計需求
1. 需求概述
建立完善的資料庫結構管理設備的基本參數、運行狀態和各種工作計劃。

資料庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平台業務的基本情況和運行狀況，滿足平台的基本要求。

2. 外部設計需求
2.1 標識符和狀態

資料庫表前綴：根據模塊名定義（如用戶模塊：sys_）

用戶名：root

密碼：待定

許可權：全部

有效時間：開發階段

說明：系統正式發布後，可能更改資料庫用戶/密碼。

2.2 使用它的程序

本系統主要利用java作為後端的應用開發工具，使用Mysql作為後台的資料庫， Linux或Windows均可作為系統平台。

2.3 約定

所有命名一定要具有描述性，杜絕一切拼音、或拼音英文混雜的命名方式。
字元集採用 UTF-8，請注意字元的轉換。
所有數據表第一個欄位都是系統內部使用主鍵列，自增欄位，不可空，名稱為：id，確保不把此欄位暴露給最終用戶。
除特別說明外，所有日期格式都採用date格式。
除特別說明外，所有欄位默認都設置不充許為空， 需要設置默認值。
所有普通縮影的命名都是表名加設置縮影的欄位名組合，例如用戶表User中name欄位設置普通所以，則縮影名稱命名方式為user_name_index。
2.4 專門指導

對本系統的開發者、使用這、測試員和維護人員，提出以下參考意見：

在使用資料庫時，首先要參考上面的約定內容，做好軟體的安裝以及表格的建立。
資料庫的輸入統一採用鍵盤。對於資料庫的使用許可權，請參考本系統其他相關文檔。
資料庫的後台管理員沒用等級差異，可根據實際情況添加刪除管理員。
2.5 支持軟體

操作系統： Linux / Windows

資料庫系統：MySQL

查詢瀏覽工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行環境下對中文支持不好，可能無法書寫帶有中文的 SQL 語句。

3. 結構設計需求
3.1 概念結構設計需求

概念資料庫的設計是進行具體資料庫設計的第一步，概念資料庫設計的好壞直接影響到邏輯資料庫的設計，影響到整個資料庫的好壞。

我們已經得到了系統的數據流程圖和數據字典，現在就是要結合數據規范化的理論，用一種模型將用戶的數據要求明確地表示出來。

概念資料庫的設計應該極易於轉換為邏輯資料庫模式，又容易被用戶所理解。概念資料庫設計中最主要的就是採用「實體-關系數據」模型來確定資料庫的結構。

數據是表達信息的一種重要的量化符號，是信息存在的一種重要形式。數據模型則是數據特徵的一種抽象。它描述的是數據的共性，而不是描述個別的數據。一般來說，數據模型包含兩方面內容：

數據的靜態特性：主要包括數據的基本結構、數據間的關系和數據之間的相互約束等特性。
數據的動態特性：主要包括對數據進行操作的方法。
在資料庫系統設計中，建立反映客觀信息的數據模型，是設計中最為重要的，也最基本的步驟之一。

數據模型是連接客觀信息世界和資料庫系統數據邏輯組織的橋梁，也是資料庫設計人員與用戶之間進行交流的共同基礎。概念資料庫中採用的實體-關系模型，與傳統的數據模型有所不同。「實體-關系」模型是面向現實世界，而不是面向實現方法的，它主要是用使用方便，因而在資料庫系統應用的設計中，得到了廣泛應用。「實體-關系」模型可以用來說明資料庫中實體的等級和屬性。

以下是實體-關系模型中的重要標識：

在資料庫中存在的實體；
實體的屬性；
實體之間的關系；
3.2 邏輯結構設計需求
物理結構設計需求

1）定義資料庫、表及欄位的命名規范：

資料庫、表及欄位的命名要遵守可讀性原則。
資料庫、表及欄位的命名要遵守表意性原則。
資料庫、表及欄位的命名要遵守長名原則。
2）選擇合適的存儲引擎：
3）為表中的欄位選擇合適的數據類型。

4）建立資料庫結構

4. 運用設計需求
4.1 表名的命名規范

表名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求小於30位。

4.2 表欄位的命名規范

欄位名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求不超過30位。
欄位名以名詞或名詞短語，欄位採用單數形式。若表名由多個單片語成，則取各個單詞的縮寫組成，單詞縮寫間使用下劃線作為分隔。
若某個欄位是引用某個表的外鍵，則欄位名應盡量與源表的欄位名保持一致，一面混淆。
5. 安全保密設計需求
5.1 防止用戶直接操作資料庫的方法

通過把關鍵應用伺服器和資料庫伺服器進行分離，防止用戶對資料庫伺服器的直接操作，保證資料庫安全。

5.2 應用系統的用戶口令進行加密

在軟體系統中，對於數據的保護、業務操作的許可是通過識別用戶身份和許可權來完成的。用戶口令相比較，相同的話系統將該用戶的操作許可權分配給用戶，用戶再根據所分配的許可權對系統進行操作。

由以上過程可知，用戶口令在傳輸過程中容易被竊取泄漏，另外如果資料庫被非法進入則其中保存的口令能夠被非法查看。因此，在傳輸過程中和資料庫中的口令記錄欄位不應使用明文傳遞和保存，應該在口令被傳遞前對其明文口令使用有效的主流技術，對傳輸數據進行加密部分描述的加密演算法進行加密，在加密後傳輸到系統。系統將用戶提交的經過加密的口令數據保存的加密口令進行比較，相一致則進行後續操作。

『貳』 資料庫設計需求分析的重點有哪些

需求分析的重點是調查､收集與分析用戶在數據管理中的信息要求､處理要求､安全性與完整性要求｡

(1)信息要求｡其是指用戶需要從資料庫中獲得信息的內容與性質｡由用戶的信息要求可以導出數據要求

『叄』 資料庫需求分析

用戶的需求具體體現在各種信息的提供、保存、更新和查詢，這就要求資料庫結構能充分滿足各種信息的輸出和輸入。收集基本數據、數據結構以及數據處理的流程，組成一份詳盡的數據字典，為後面的具體設計打下基礎。

在本系統設計中，由於考慮到各種數據信息均具有空間屬性，即與區域或位置相關，因此在資料庫設計時，使用空間資料庫和屬性資料庫共同管理數據的方式，實現空間數據屬性和非幾何屬性的協同管理。

『肆』 簡述資料庫設計過程

資料庫設計過程分為以下六個階段：

1、需求分析階段

准確理解和分析用戶需求（包括數據和處理），它是整個設計過程的基礎，也是最困難、最耗時的一步。

2、概念結構設計階段

是整個資料庫設計的關鍵，通過對用戶需求的集成、歸納和抽象，形成了一個獨立於特定資料庫管理系統的概念模型。

3、邏輯結構設計階段

將概念結構轉換為DBMS支持的數據模型，對其進行優化。

4、資料庫物理設計階段

為邏輯數據模型選擇最適合應用程序環境的物理結構（包括存儲結構和存取方法）。

5、資料庫實現階段

根據邏輯設計和物理設計的結果，使用資料庫管理系統提供的數據語言、工具和主機語言，建立資料庫，編寫調試應用程序，組織數據倉庫，並進行試運行。

6、資料庫運行維護階段

資料庫應用系統經試運行後可投入正式運行，在資料庫系統運行過程中，需要不斷地對其進行評估、調整和修改。

註：在設計過程中，將資料庫的設計與資料庫中數據處理的設計緊密結合起來，在每個階段同時對這兩個方面的要求進行分析、抽象、設計和實現，相互借鑒和補充，從而完善這兩個方面的設計。

(4)資料庫需求設計擴展閱讀：

資料庫設計技術

1、清晰的用戶需求：作為計算機軟體開發的重要基礎，資料庫設計直接反映了用戶的需求。資料庫必須與用戶緊密溝通，緊密結合用戶需求。在定義了用戶開發需求之後，設計人員還需要反映具體的業務關系和流程。

2、注意數據維護：設計面積過大、數據過於復雜是資料庫設計中常見的問題，設計人員應注意數據維護。

3、增加命名規范化：命名資料庫程序和文件非常重要，不僅要避免重復的名稱，還要確保數據處於平衡狀態。為了降低檢索信息和資源的復雜度和難度，設計人員應了解資料庫程序與文件之間的關系，並靈活使用大小寫字母命名。

4、充分考慮資料庫的優化和效率：考慮到資料庫的優化和效率，設計人員需要對不同表的存儲數據採用不同的設計方法。在設計中，還應該使用最少的表和最弱的關系來實現海量數據的存儲。

5、不斷調整數據之間的關系：不斷調整和簡化數據之間的關系，可以有效減少設計與數據之間的聯系，進而為維護數據之間的平衡和提高數據讀取效率提供保障。

6、合理使用索引：資料庫索引通常分為聚集索引和非聚集索引，這樣可以提高數據搜索的效率。

參考資料來源：網路-資料庫設計

『伍』 資料庫設計的基本步驟是什麼

（1）需求分析階段：需求收集和分析，得到數據字典和數據流圖。

（2）概念結構設計階段：對用戶需求綜合、歸納與抽象，形成概念模型，用E-R圖表示。

（3）邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型。

（4）資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構。

（5）資料庫實施階段：建立資料庫，編制與調試應用程序，組織數據入庫，程序試運行。

（6）資料庫運行和維護階段：對資料庫系統進行評價、調整與修改。

『陸』 資料庫設計主要包括哪幾部分，分別包括哪些內容

資料庫設計主要包括需求分析、概念結構設計、邏輯結構設計、物理結構設計、資料庫的實施和資料庫的運行和維護，具體內容如下：

1、需求分析

內容：調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。

2、概念設計

內容：對用戶要求描述的現實世界，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

3、邏輯設計

內容：主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。

4、物理設計

內容：根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。

5、驗證設計

內容：收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。

6、運行與維護設計

內容：在資料庫系統正式投入運行的過程中，必須不斷地對其進行調整與修改。除了關系型資料庫已有一套較完整的數據範式理論可用來部分地指導資料庫設計之外，尚缺乏一套完善的資料庫設計理論、方法和工具，以實現資料庫設計的自動化或互動式的半自動化設計。

(6)資料庫需求設計擴展閱讀：

重要性

1、有利於資源節約

對計算機軟體資料庫設計加以重視不僅可減少軟體後期的維修，達到節約人力與物力的目的，同時還有利於軟體功能的高效發揮。

2、有利於軟體運行速度的提高

高水平的資料庫設計可滿足不同計算機軟體系統對於運行速度的需求，而且還可充分發揮並實現系統功能。計算機軟體性能提高後，系統發出的運行指令在為用戶提供信息時也將更加快速有效，軟體運行速度自然得以提高。

3、有利於軟體故障的減少

加強資料庫設計可有效減少軟體故障的發生幾率，推動計算機軟體功能的實現。

『柒』 什麼是資料庫設計試述資料庫設計的步驟

答：（1）需求分析階段：需求收集和分析，得到數據字典和數據流圖。 （2）概念結構設計階段：對用戶需求綜合、歸納與抽象，形成概念模型，用E-R圖表示。（3）邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型。（4）資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構。（5）資料庫實施階段：建立資料庫，編制與調試應用程序，組織數據入庫，程序試運行。（6）資料庫運行和維護階段：對資料庫系統進行評價、調整與修改。

『捌』 資料庫設計的步驟有哪些

資料庫的設計過程大致可分為以下六個階段：

1. 需求分析階段

需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。

2. 概念結構設計階段

通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。

3. 邏輯結構設計階段

將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。

4. 資料庫物理設計階段

為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。

5. 資料庫實施階段

運用DBMS提供的數據語言（例如SQL）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。

6. 資料庫運行和維護階段

資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。

『玖』 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段

1.需求分析

2.概念結構設計

3.邏輯結構設計

4.物理結構設計

5.資料庫實施

6.資料庫的運行和維護

資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。

在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。

1.需求分析階段（常用自頂向下）

進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。

需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。

調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。

數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。

2.概念結構設計階段（常用自底向上）

概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。

設計概念結構通常有四類方法：

• 自頂向下。即首先定義全局概念結構的框架，再逐步細化。

• 自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。

• 逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。

• 混合策略。即自頂向下和自底向上相結合。

3.邏輯結構設計階段（E-R圖）

邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。

在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。

各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。

E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。

4.物理設計階段

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

首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。

常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.資料庫實施階段

資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。

6.資料庫運行和維護階段

資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。

資料庫設計5步驟
Five Steps to design the Database

1.確定entities及relationships

a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。

b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。

c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。

d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：

· 增加新員工

· 修改存在員工信息

· 刪除調走的員工

e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。

====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。


定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。



細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級

這些微觀行為可用來確定需要哪些table或relationship。

確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。

2.確定所需數據

要確定所需數據：

a)確定支持數據

b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼

c)為每個table建立數據

d)列出每個table目前看起來合適的可用數據

e)為每個relationship設置數據

f)如果有，為每個relationship列出適用的數據

確定支持數據

你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果將這些數據畫成圖表，就像：



• 需要注意：


• ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。


• ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。


• ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。


• ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。


• ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。

3.標准化數據

標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。

標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。

如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。

數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。

主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。

將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。


將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。

4.考量關系

當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。

考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。

遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。

考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。

有一些基本原則能幫助你決定將這些鍵放在哪裡：

一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。

一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。

多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。

5.檢驗設計

在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。

最終設計
最終設計看起來就像這樣：

設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。

對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。

選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。

為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型

關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。

長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。

關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。

『拾』 資料庫設計的四個階段是:需求分析、概念設計、邏輯設計和（）。

資料庫設計的四個階段是：需求分析、概念設計、邏輯設計和 D
A） 編碼設計 B）測試階段 C）運行階段 D）物理設計