【轉】SQL學習---數據庫設計

數據庫設計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.確定所需數據

要確定所需數據：

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數據類型”。

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。其定義如下：

Fields	Type	Size	Null/Not Null	Constraint
Dept_id	Integer	--	Not null	None
Dept_name	Char	40	Not null	None
Dept_head_id	Integer	--	Not null	None

注意每一字段都被指定爲“not null”。這種情況下，表中每一記錄的所有字段的數據都必填。

選擇主鍵及外部鍵
主鍵是唯一識別表中每一項記錄的字段。如何你的表已經正確標準化，主鍵應當成爲數據庫設計的一部分。
外部鍵是包含另一表中主鍵值的一個或一組字段。外部鍵關係在數據庫中建立了一對一及一對多關係。如果你的設計已經正確標準化，外部鍵應當成爲數據庫設計的一部分