"중복되는 항목이 없다"에 대한 정의는 학자마다 주장이 조금씩 달라서, 1NF를 만족하는 테이블에 대해서의 정확한 정의는 없다. 대부분의 학자들(에드거 F. 커드, Ramez Elmasri, Shamkant B. Navathe[3])은 1NF를 만족하는 테이블은 관계 값을 가지는 항목(테이블 내 테이블)을 허용하지 않으나, 일부 학자들(크리스토퍼 J. 데이트 등)은 이를 허용하기도 한다.
제1정규형은 다음 표준을 요구한다.
각 테이블에서 중복을 제거한다.
각각 관계된 데이터 모임을 위하여 분리된 테이블을 만든다.
각각 관계된 데이터 모임을 기본키로 식별한다.
관계를 의미하는 1NF 테이블
크리스토퍼 J. 데이트에 의하면 테이블은 "어떤 관계와 동일 구조"이면 1NF이다. 이는 아래의 5가지 조건을 충족한다는 의미이다:
열에는 위-아래의 순서가 없다.
행에는 좌-우의 순서가 없다.
중복되는 열이 없다.
모든 열과 행의 중복지점에는 (열과 행의)해당되는 분야에서 한 개의 값을 가진다.
모든 행은 규칙적이다. [즉, 열은 열ID, 오브젝트ID, 숨어있는(hidden) 타임 스탬프등과 같은 숨어있는 요소(행)를 가지지 않는다.]
-- Chris Date, "What First Normal Form Really Means", pp. 127–8[4]
이런 조건을 충족하지 않는 테이블은 엄격히 보면 관계형이 아니라는 의미이며, 1NF가 아니다.
뷰의 결과가 특정한 순서를 가지게 정의한 뷰. 뷰의 측면에서 열의 정렬이 본질적이고 의미가 있을 경우.[5] 이는 1번 조건을 위배한다. 관계에서의 튜플은 서로간의 순서가 없다.
최소한 하나의 Null 속성을 가지는 테이블. Null 속성은 모든 행의 영역에서 꼭 한 개의 값만을 가져야 하는 4번 조건을 위배한다. 하지만 4번 조건은 논란이 많은데, 에드거 F. 커드는 최근의 관계형 모델에 관한 견해에서 Null에 대한 명시적인 조항을 만들었었다.[6][7]
중복되는 항목
많은 사람들이 1NF를 정의하는 특성이라고 생각하는[8]에드거 F. 커드의 4번째 조건은 중복되는 항목에 관한 조건이다. 아래의 시나리오들은 데이터베이스 디자인이 1NF를 위배하는 중복되는 항목을 가지는 경우이다.
영역과 값
초보 디자이너가 고객의 이름과 전화번호를 기록하고자 한다. 그는 아래와 같이 테이블을 정의하였다:
Customer
Customer ID
First Name
Surname
Telephone Number
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659
789
Maria
Fernandez
555-808-9633
디자이너는 이후에 어떤 고객들은 전화번호를 여러개 가지고 있다는 사실을 알게 되었다. 그는 아래와 같이 단순히 가장 간단한 방법을 생각하여 "전화번호"항목에 여러 개의 값을 두었다:
Customer
Customer ID
First Name
Surname
Telephone Number
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659 555-776-4100
789
Maria
Fernandez
555-808-9633
하지만 전화번호 행에는 전화번호가 아닌 전화번호와 유사한 도메인(12개의 길이를 가지는 문자열)이 정의되게 된다. 1NF(그 점에 있어서 관계형 데이터베이스도 마찬가지로)는 행 도메인에서 정확하게 한 개의 값만을 허용하기 때문에 위의 테이블은 1NF가 아니다.
행을 가로지르며 중복되는 항목
그래서 이 디자이너는 이번에는 이 제한을 충족하기 위해 여러개의 전화번호 행을 두었다:
Customer
Customer ID
First Name
Surname
Tel. No. 1
Tel. No. 2
Tel. No. 3
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659
555-776-4100
555-403-1659
789
Maria
Fernandez
555-808-9633
하지만 이 디자인 역시 Null값을 가지는 행이 있기 때문에 크리스토퍼 J. 데이트의 1NF정의에 위배된다. 뷰가 Null 행을 허용하여도 이 디자인은 엄격히 보자면 1NF가 아니다. Tel. No. 1, Tel. No. 2., Tel. No. 3. 행은 완전히 동일한 도메인과 의미를 가진다. 위와 같이 전화번호 행을 3개로 인위적으로 나누게 된다면 아래와 같은 논리적인 문제들을 낳게 된다:
테이블 질의시 어려움. "어느 고객이 전화번호 X를 가지고 있는가?", "어떤 고객들끼리 같은 전화번호를 공유하는가?" 질의들은 답하기 어렵다.
RDBMS에서 고객-전화번호의 유일성을 확보하기 어렵다. 고객 789가 실수로 Tel. No. 2값이 Tel. No. 1값과 동일한 값이 들어갈 수 있다.
전화번호 개수의 제한. 어떤 고객이 4개의 전화번호를 가진다면 4번째 전화번호는 기록될 수 없다.이는 데이터베이스 디자인이 비즈니스 프로세스를 제한하고 있다는 의미인데, 사실 이상적으로는 반대가 되어야 한다.
행 내에서의 중복되는 항목
그래서 이 디자이너는 이번에는 이 제한을 충족하기 위해 한개의 전화번호 행을 두면서 전화번호 행 길이를 여러개의 전화번호를 기록하기 충분한 길이로 변경하였다 :
Customer
Customer ID
First Name
Surname
Telephone Numbers
123
Robert
Ingram
555-861-2025
456
Jane
Wright
555-403-1659, 555-776-4100
789
Maria
Fernandez
555-808-9633
이 디자인은 1NF와 일치하지만, 디자인상의 문제점이 여러개 있다.전화번호는 의미상으로 모호해져서 전화번호를 표현할 수도, 전화번호들의 리스트를 표현할 수도, 심지어는 아무거나 표현할 수도 있다."어떤 고객들이 같은 전화번호를 공유하는가?" 질의는 답하기 더욱 어려워 졌으며, 전화번호와 전화번호들의 리스트를 수집해야 할 필요성이 생겼다. RDBMS 내에서 전화번호에 대한 의미적인 제한을 정의하는 것 또한 어려워 졌다.
1NF를 충족하는 디자인
1NF 측면에서 모호하지 않은 디자인은 2개의 테이블을 이용하는 것이다: 고객 명 테이블과 고객 전화번호 테이블이다.
Customer Name
Customer ID
First Name
Surname
123
Robert
Ingram
456
Jane
Wright
789
Maria
Fernandez
Customer Telephone Number
Customer ID
Telephone Number
123
555-861-2025
456
555-403-1659
456
555-776-4100
789
555-808-9633
이 디자인에서는 전화번호들의 중복되는 항목은 나오지 않는다. 대신 고객 대 전화번호의 연결이 레코드에 나온다. 고객 ID가 키 항목으로, "부모-자식" 또는 "일대 다(1:M)" 관계가 2개의 테이블사이에 존재하게 되는데, 이는 ("부모" 테이블에 있는) 고객 열이 ("자식" 테이블에 있는) 전화번호 열을 여러개 가질 수 있기 때문이다. 참고로 이 디자인은 제 2 정규형과 제 3 정규형을 충족하기도 한다.
원자성(Atomicity)
에드거 F. 커드는 1NF의 정의에서 원자성에 대해서 언급하고 있다.에드거 F. 커드는 "관계가 정의된 도메인의 값은 DBMS에 대하여 원자성을 가져야 한다."[9] 고 하였다. 에드거 F. 커드는 원자성을 갖는 값은 "(특수한 어떤 함수를 제외하고) DBMS에 의해서 더 작은 값으로 쪼개 지지 않는다"[10] 고 하였다. 이는 한 항목이 하나 이상의 자료형으로 나뉘면서 DBMS가 분리된 다른 부분에 대해서 의존적이지 않아야 한다는 의미이다.
허그 다윈과 크리스토퍼 J. 데이트는 에드거 F. 커드의 "원자성을 갖는 값"의 정의가 모호하며, 이런 모호성이 1NF를 이해하는데 크게 방해된다고 제안하였다.[11][12] "값이 나뉘지 않아야 한다"라는 정의에 해당하는 데이터형이 아래와 같은 이유로 거의 존재하지 않기 때문에 문제가 많다:
문자열도 원자성이 없다. RDMS가 일반적으로 작은 문자열로 나눌 수 있는 연산자를 제공하기 때문이다.
고정 소수점 수자도 원자성이 없다. RDBS가 일반적으로 이를 정수와 나머지 부분으로 나눌 수 있는 연산자를 제공하기 때문이다.
크리스토퍼 J. 데이트는 "원자성이란 절대적인 정의가 없다":[13] 고 하였다. 값은 목적에 따라서 원자성을 가질 수 도 있으며, 다른 목적을 위해서 나뉠 수도 있다. 이런 의견을 받아들이면 1NF의 정의에 원자성은 관련이 없어진다. 임의의 편한 자료형(문자열, 숫자형, 배열, 테이블 등)으로 정의된 행이라도 1NF 테이블일 수 있지만, 항상 그런 것은 아니다(예를 들어서, 고객 이름을 성과 이름으로 나누어야 할 때가 있다.) 크리스토퍼 J. 데이트는 심지어 관계 값을 갖는 속성, 즉 항목 안에 테이블이 있는 경우도 드문 경우에 유용하다고 하였다.[14]
1NF 이상의 정규화
어떤 테이블이 제 2 정규형(2NF)이거나 그 이상이면 정의에 따라서 1NF이기도 하다.(어떤 정규형이라도 그 이전 정규형의 충분조건이 된다.) 반대로 어떤 테이블이 1NF이면 2NF가 아닐수도 있다. 2NF이면 제 3 정규형일 수도 있고, 아닐 수도 있다.
1NF 이상의 정규형은 디자인 문제로 인하여 그 안의 데이터의 완전성을 절충해야 하는 상황을 고려하여야 한다. 예를 들어 아래의 테이블은 1NF이지만 2NF가 아니며, 이에 따라서 논리적 불일치에 있어서 취약하다:
Carol Robertson이 결혼을 해서 성을 바꾼다면, 2개의 열을 변경하여야 한다. 1개의 열만 변경할 경우, 모순이 생긴다: "고객 252의 이름은 무엇인가?"에 대한 질문에 2개의 혼란스러운 답변이 생긴다. 2NF는 이 문제를 해결한다. Carol Robertson의 레코드는 그녀가 1개 이상의 이메일 주소를 사용함에 따라서 테이블에서 2개로 나타나는 것을 주목하기 바란다.
1NF 이상의 정규화에 대해서 생각해볼 수 있는 실질적인 방법은 레코드(행)들과 엔티티(테이블) 또는 속성(열)의 관계에 대해서 끊임없이 질문해 보는 것이다. 예를 들어, 이용자 레코드가 많은 이메일 주소 레코드와 관계가 있는가? 하나의 이메일 주소가 많은 이용자들과 관계가 있는가? 위의 테이블에서는 Carol Robertson이 하나 이상의 이메일 주소를 가지고 있었다. 하나의 이용자는 다수의 이메일 주소를 가질수 있고, 다수의 이메일 주소는 하나의 이용자를 가질수 있으므로 위의 테이블운 이용자와 이메일 주소간에 일대다(1:M) 관계가 있다고 답할 수 있다. 이제 ID, 성, 이름을 가지고 ID를 주 키로 하는 "이용자 테이블" 과 ID, 이메일을 가지고 ID를 주 키로 하는 "이용자 이메일 테이블"이라는 두 테이블이 있다면 ID를 주 키로 하는 "이용자 테이블" 과 ID를 외래 키로 하는 "이용자 이메일 테이블" 간에 1대 다 관계가 생기며, 이 테이블들도 1NF이게 된다.
↑"[T]he overriding requirement, to the effect that the table must directly and faithfully represent a relation, follows from the fact that 1NF was originally defined as a property of relations, not tables." Date, C. J. "What First Normal Form Really Means" in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 128.
↑Such views cannot be created using SQL that conforms to the SQL:2003 standard.
↑"Codd first defined the relational model in 1969 and didn't introduce nulls until 1979" Date, C. J. SQL and Relational Theory (O'Reilly, 2009), Appendix A.2.
↑The third of Codd's 12 rules states that "Null values ... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type." Codd, E. F. "Is Your DBMS Really Relational?" Computerworld, October 14, 1985.
↑Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
↑Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
↑Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
↑"[F]or many years," writes Date, "I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations." Date, C. J. "What First Normal Form Really Means" in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 108
