亚洲区小说区图片区,蜜芽亚洲av无码精品色午夜,亚洲经典在线观看

數據庫設計5步驟

數據庫設計5步驟
來源：SQL Anywhere User's Guide
翻譯作者：Sarkuya

版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
原文地址:
http://www.matrix.org.cn/resource/article/43/43717_Database_Design.html
關鍵詞： Database Design

1.確定entities及relationships

a)設計宏觀行為。你用此數據庫來做什么？比如，希望管理雇員的信息。

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

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

d)細化行為。你從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：
●        增加新員工
●        修改存在員工信息
●        刪除調走的員工

e)確定業(yè)務規(guī)則。看著你的業(yè)務規(guī)則，確定你要采取哪種。比如，可能有這樣一種規(guī)則，一個部門有且只能有一個部門領導。這些規(guī)則將被設計到數據庫的結構中。

范例：

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

定義宏觀行為
一些ACME公司的宏觀行為包括：
●        招聘員工
●        解雇員工
●        管理員工個人信息
●        管理公司所需的技能信息
●        管理哪位員工有哪些技能
●        管理部門信息
●        管理辦事處信息

確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，并創(chuàng)建一個基于宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以后會細化。

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

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

確定業(yè)務規(guī)則
業(yè)務規(guī)則常用于確定一對多，一對一，及多對多關系。
相關的業(yè)務規(guī)則可能有：
●        現在有5個辦事處；最多允許擴展到10個。
●        員工可以改變部門或辦事處
●        每個部門有一個部門領導
●        每個辦事處至多有3個電話號碼
●        每個電話號碼有一個或多個擴展
●        員工被招進時，每一種技能的專業(yè)等級都被確定。
●        每位員工擁有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相對應無關緊要，你可以根據自己的喜好來定。在下節(jié)中，你會通過測試對此作出判斷。

3.標準化數據

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

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

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

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

主鍵是一張表中唯一區(qū)分各行的一組字段。Employee表的主鍵是Employee ID字段。Works In relationship中的主鍵包括Office Code及Employee ID字段。給數據庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。

將數據放在第一遍的標準化格式中
●        除去重復的組
●        要測試第一遍標準化格式，除去重復的組，并將它們放進他們各自的一張表中。
●         在下面的例子中，Phone Number可以重復。（一個工作人員可以有多于一個的電話號碼。）將重復的組除去，創(chuàng)建一個名為Telephone的新表。在Telephone與 Office創(chuàng)建一個名為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可能集含有數據。這經常發(fā)生在多對多的關系中。

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

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

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

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

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

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

5.檢驗設計

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

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

設計數據庫的表屬性
數據庫設計需要確定有什么表，每張表有什么字段。此節(jié)討論如何指定各字段的屬性。

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

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

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

關于數據類型的內容，請參見“SQL Anywhere數據類型”一節(jié)。字段的數據類型影響字段的最大尺寸。例如，如果你指定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”。這種情況下，表中每一記錄的所有字段的數據都必填。

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

posted on 2007-04-02 14:30 leoli 閱讀(162) 評論(0) 編輯收藏所屬分類: database

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發(fā)表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: debian mysql remote access sql 不錯（http://www.lzbk.com/blog/vista/index.html）數據庫設計2 數據庫設計5步驟數據庫設計1 Oralce中的to_date()函數 oracle 存儲過程 oracle 日期處理 sql 語句

Thinking in MyLife

數據庫設計5步驟

導航

統計

常用鏈接

留言簿(6)

隨筆分類

隨筆檔案(17)

文章分類(86)

收藏夾(3)

flex blog

good site

java blog

my friend

tools

抓蝦

搜索

最新評論

閱讀排行榜

評論排行榜