資料庫設計5步驟

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.確定所需資料

要確定所需資料：
1. 確定支援資料
2. 列出所要跟蹤的所有資料。描述table(主題)的資料回答這些問題：誰，什麼，哪裡，何時，以及為什麼
3. 為每個table建立資料
4. 列出每個table目前看起來合適的可用資料
5. 為每個relationship設定資料
6. 如果有，為每個relationship列出適用的資料

確定支援資料

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

如果將這些資料畫成圖表，就像：

需要注意：
● 在確定支援資料時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些資料。
● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支援資料分解為名字與姓氏，這比簡單地提供一個名字會更好。
● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。
● 比如，如果你在某些地方用了一個縮寫名稱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中抽取其鍵產生。

將資料放在第一遍的標準化格式中
● 除去重複的組
● 要測試第一遍標準化格式，除去重複的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，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資料類型”。

NULL與NOT NULL

如果一個欄位值是必填的，你就將此欄位定義為NOT NULL。否則，欄位值可以為NULL值，即可以有空值。SQL中的預設值是允許空值；你應該顯示地將欄位定義為NOT NULL，除非你有好理由將其設為允許空值。

關於NULL值的完整描述，請見“NULL value”。有關其對比用法，見“Search conditions”。

選擇約束

儘管欄位的資料類型限制了能存在欄位中的資料（例如，只能存數字或日期），你或許希望更進一步來約束其允許值。

你可以通過指定一個“CHECK”約束來限制任意欄位的值。你可以使用能在WHERE子句中出現的任何有效條件來約束被允許的值，儘管大多數CHECK約束使用BETWEEN或IN條件。

更多資訊

有關有效條件的更多資訊，見“Search conditions”。有關如何為表及欄位指定約束，見“Ensuring Data Integrity”。

例子
例子資料庫中有一個名為department的表，欄位是dept_id, dept_name, dept_head_id。其定義如下：

注意每一欄位都被指定為“not null”。這種情況下，表中每一記錄的所有欄位的資料都必填。

選擇主鍵及外部鍵
主鍵是唯一識別表中每一項記錄的欄位。如何你的表已經正確標準化，主鍵應當成為資料庫設計的一部分。
外部鍵是包含另一表中主索引值的一個或一組欄位。外部鍵關係在資料庫中建立了一對一及一對多關聯性。如果你的設計已經正確標準化，外部鍵應當成為資料庫設計的一部分。