數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)中最為常見(jiàn)的設(shè)計(jì)三個(gè)范式

MS SQLServer數(shù)據(jù)庫(kù)結(jié)構(gòu)讀取工具V1.0.0.1 綠色版

• 類型：數(shù)據(jù)庫(kù)類大�。�965KB語(yǔ)言：英文 評(píng)分：2.5
• 標(biāo)簽：

立即下載

為了建立冗余較小、結(jié)構(gòu)合理的數(shù)據(jù)庫(kù)，設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)必須遵循一定的規(guī)則。在關(guān)系型數(shù)據(jù)庫(kù)中這種規(guī)則就稱為范式。范式是符合某一種設(shè)計(jì)要求的總結(jié)。要想設(shè)計(jì)一個(gè)結(jié)構(gòu)合理的關(guān)系型數(shù)據(jù)庫(kù)，必須滿足一定的范式。

在實(shí)際開發(fā)中最為常見(jiàn)的設(shè)計(jì)范式有三個(gè)：

1．第一范式

第一范式是最基本的范式。如果數(shù)據(jù)庫(kù)表中的所有字段值都是不可分解的原子值，就說(shuō)明該數(shù)據(jù)庫(kù)表滿足了第一范式。

第一范式的合理遵循需要根據(jù)系統(tǒng)的實(shí)際需求來(lái)定。比如某些數(shù)據(jù)庫(kù)系統(tǒng)中需要用到“地址”這個(gè)屬性，本來(lái)直接將“地址”屬性設(shè)計(jì)成一個(gè)數(shù)據(jù)庫(kù)表的字段就行。但是如果系統(tǒng)經(jīng)常會(huì)訪問(wèn)“地址”屬性中的“城市”部分，那么就非要將“地址”這個(gè)屬性重新拆分為省份、城市、詳細(xì)地址等多個(gè)部分進(jìn)行存儲(chǔ)，這樣在對(duì)地址中某一部分操作的時(shí)候?qū)⒎浅７奖恪＿@樣設(shè)計(jì)才算滿足了數(shù)據(jù)庫(kù)的第一范式，如下表所示。

用戶信息表

上表所示的用戶信息遵循了第一范式的要求，這樣在對(duì)用戶使用城市進(jìn)行分類的時(shí)候就非常方便，也提高了數(shù)據(jù)庫(kù)的性能。

2．第二范式

第二范式在第一范式的基礎(chǔ)之上更進(jìn)一層。第二范式需要確保數(shù)據(jù)庫(kù)表中的每一列都和主鍵相關(guān)。也就是說(shuō)在一個(gè)數(shù)據(jù)庫(kù)表中，一個(gè)表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫(kù)表中。

比如在設(shè)計(jì)一個(gè)訂單數(shù)據(jù)表的時(shí)候，不可以包含與訂單信息無(wú)關(guān)的其它數(shù)據(jù)。如下表的設(shè)計(jì)就完全違背了第二范式的設(shè)計(jì)理論。

訂單信息表

從上表來(lái)看，后面兩列雖然不是無(wú)意義的數(shù)據(jù)，但是其和主鍵列“訂單編號(hào)”毫無(wú)關(guān)系，所以第二范式認(rèn)為這種設(shè)計(jì)是不合理的。

3．第三范式

第三范式在第二范式的基礎(chǔ)上更進(jìn)一層。第三范式需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。

比如在設(shè)計(jì)一個(gè)訂單數(shù)據(jù)表的時(shí)候，可以將客戶編號(hào)作為一個(gè)外鍵和訂單表建立相應(yīng)的關(guān)系。而不可以在訂單表中添加關(guān)于客戶其它信息（比如姓名、所屬公司等）的字段。如下面這兩個(gè)表所示的設(shè)計(jì)就是一個(gè)滿足第三范式的數(shù)據(jù)庫(kù)表。

訂單信息表

客戶信息表

這樣在查詢訂單信息的時(shí)候，就可以使用客戶編號(hào)來(lái)引用客戶信息表中的記錄，也不必在訂單信息表中多次輸入客戶信息的內(nèi)容，減小了數(shù)據(jù)冗余。