第一範式的關係
規定關係
第一範式規定關係的每一個屬性必須是一個不可分的數據項。
非第一範式的例子如表5-5，可以轉換為第一範式如表5-6。
表5-5
| 導師 | 專業 | 研究生 |
| 第一個研究生 第二個研究生 |
表5-6
| 導師 | 專業 | 第一個研究生 第二個研究生 |
幾乎所有的商用關係DBMS都要求關係為第一範式，現在流行的關係資料庫語言，如SQL，也都只支持第一範式。
如果關係僅僅滿足第一範式的條件是不夠的，可能會存在更新異常。為了消除這些異常，需要進行關係的規範化。
關係模式實例
下面是滿足第一範式的(不好的)關係模式的例子。例如：設有一關係模式R(S#，C#，G，TN，D)，其中(S#)為學號，C#為課程號，G為成績，TN為任課教師姓名，D為教師所在系名，這些數據具有下列語義：
(1) 學號是一個學生的標識，課程號是一門課程的標識。
(2) 一位學生所修的每門課程都有一個成績。
(3) 每門課程只有一位任課教師，但一位教師可以教多門課。
(4) 教師中沒有重名，每位教師只屬於一個系。
下面是一個具體關係實例的數據，如表5-7：
表5-7
| 學號 S# | 課程號 C# | 成績 G | 教師 TN | 系名 D |
| s1 | c1 | g1 | t1 | d1 |
| s1 | c2 | g2 | t2 | d2 |
| s2 | c1 | g3 | t1 | d1 |
| s2 | c2 | g4 | t2 | d2 |
| s3 | c2 | g5 | t2 | d2 |
| s3 | c3 | g6 | t2 | d2 |
雖然上述的關係模式只有四個屬性，但它是一個不好的關係模式，因為該模式在使用過程中有以下幾個問題：
(1) 數據冗餘。例如，教師所在系名對選該教師所開課的所有學生都重複輸入一次。
(2) 插入異常。由於關係的主鍵{S#, C#} 不能為空值，如果一個教師不教課，則這位教師的姓名及所屬的系名就不能插入表中。
(3) 刪除異常。如果所有學生都退選某一門課，則有關該門課的其它數據(任課教師名及所在系名)也將被刪除。
(4) 修改異常。如果改變一門課的任課教師，則需要修改表中選修該門課程的多行記錄，如果部分修改，部分不修改，則會導致數據的不一致。
上述關係模式之所以是一個不好的關係模式，是因為模式中存在部分函式依賴和傳遞函式依賴。消除這些部分函式依賴和傳遞函式依賴，就可以得到一個比較好的關係模式。
根據上述示例說明的語義，找出有下面的函式依賴集合F：
F = { {S#, C#}→ G，C#→TN，TN → D}
圖 5－2
針對函式依賴集合，運用關係資料庫設計理論，可以對上述關係進行分解，得到3個關係模式如下：
SCG(S#, C#, G)
CTN(C#, TN)
TND(TN, D)
上述3個關係可以消除數據冗餘，插入異常，刪除異常和修改異常等現象。是一個比較好的關係模式。把原來一個關係表的數據分解為三個關係表存放。
具體的關係實例的數據如表5-8：
表5-8
| S# | C# | G |
| s1 s1 s2 s2 s3 s3 | c1 c2 c1 c2 c2 c3 | g1 g2 g3 g4 g5 g6 |
對於上述示例，是滿足第一範式的關係模式，但它不是一個好的關係模式，存在數據冗餘和操作異常現象。通過分析模式屬性間的函式依賴關係，把一個模式分解為三個關係模式後，消除了數據冗餘和操作異常。對於任一給定的模式，如何判斷是一個好的還是不好的關係模式呢？又如何把一個不好的關係模式分解轉換為好的關係模式呢？這就是在下面要討論的問題，對關係模式中X→Y的函式依賴關係，給出不同程度的限制，得到滿足不同範式要求的模式。
指導原則
第一範式包括下列指導原則：
關係中每個記錄的每個屬性只能包含一個值；
關係中的每個記錄必須包含相同數量的值；
關係中的每個記錄一定不能相同。
第一範式是對關係模式的最起碼的要求。不滿足第一範式的資料庫模式不能稱為關係資料庫。
但是滿足第一範式的關係模式並不一定是一個好的關係模式。
例：如職工號，姓名，電話號碼組成一個表（一個人可能有一個辦公室電話 和一個家裡電話號碼） 規範成為1NF有三種方法：
一是重複存儲職工號和姓名。這樣，關鍵字只能是電話號碼。
二是職工號為關鍵字，電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字，但強制每條記錄只能有一個電話號碼。
以上三個方法，第一種方法最不可取，按實際情況選取後兩種情況。
