제1정규형
제1정규형(1NF 또는 최소형)은 데이터베이스 정규화에서 사용하는 정규형중 하나이다. 관계형 데이터베이스의 테이블이 1NF이면 최소한 테이블은 관계 이며, 중복되는 항목이 없어야 한다 이다.
"중복되는 항목이 없다"에 대한 정의는 학자마다 주장이 조금씩 달라서, 1NF를 만족하는 테이블에 대해서의 정확한 정의는 없다. 대부분의 학자들(에드거 F. 커드, Ramez Elmasri, Shamkant B. Navathe)은 1NF를 만족하는 테이블은 관계 값을 가지는 항목(테이블 내 테이블)을 허용하지 않으나, 일부 학자들(크리스토퍼 J. 데이트 등)은 이를 허용하기도 한다.
제1정규형은 다음 표준을 요구한다.
크리스토퍼 J. 데이트에 의하면 테이블은 "어떤 관계와 동일 구조"이면 1NF 이다. 이는 아래의 5가지 조건을 충족한다는 의미이다:
-- Chris Date, "What First Normal Form Really Means", pp. 127–8
이런 조건을 충족하지 않는 테이블은 엄격히 보면 관계형이 아니라는 의미이며, 1NF가 아니다.
1NF의 정의를 충족하지 못하는 테이블(또는 뷰)의 예제들을 보자면,많은 사람들이 1NF를 정의하는 특성이라고 생각하는 에드거 F. 커드의 4번째 조건은 중복되는 항목에 관한 조건이다. 아래의 시나리오들은 데이터베이스 디자인이 1NF를 위배하는 중복되는 항목을 가지는 경우이다.
초보 디자이너가 고객의 이름과 전화번호를 기록하고자 한다. 그는 아래와 같이 테이블을 정의하였다:
디자이너는 이후에 어떤 고객들은 전화번호를 여러개 가지고 있다는 사실을 알게 되었다. 그는 아래와 같이 단순히 가장 간단한 방법을 생각하여 "전화번호"항목에 여러 개의 값을 두었다:
하지만 전화번호 행에는 전화번호가 아닌 전화번호와 유사한 도메인(12개의 길이를 가지는 문자열)이 정의되게 된다. 1NF(그 점에 있어서 관계형 데이터베이스도 마찬가지로)는 행 도메인에서 정확하게 한 개의 값만을 허용하기 때문에 위의 테이블은 1NF가 아니다.
그래서 이 디자이너는 이번에는 이 제한을 충족하기 위해 여러개의 전화번호 행을 두었다:
하지만 이 디자인 역시 Null값을 가지는 행이 있기 때문에 크리스토퍼 J. 데이트의 1NF정의에 위배된다. 뷰가 Null 행을 허용하여도 이 디자인은 엄격히 보자면 1NF가 아니다. Tel. No. 1, Tel. No. 2., Tel. No. 3. 행은 완전히 동일한 도메인과 의미를 가진다. 위와 같이 전화번호 행을 3개로 인위적으로 나누게 된다면 아래와 같은 논리적인 문제들을 낳게 된다:그래서 이 디자이너는 이번에는 이 제한을 충족하기 위해 한개의 전화번호 행을 두면서 전화번호 행 길이를 여러개의 전화번호를 기록하기 충분한 길이로 변경하였다 :
이 디자인은 1NF와 일치하지만, 디자인상의 문제점이 여러개 있다.전화번호는 의미상으로 모호해져서 전화번호를 표현할 수도, 전화번호들의 리스트를 표현할 수도, 심지어는 아무거나 표현할 수도 있다."어떤 고객들이 같은 전화번호를 공유하는가?" 질의는 답하기 더욱 어려워 졌으며, 전화번호와 전화번호들의 리스트를 수집해야 할 필요성이 생겼다. RDBMS 내에서 전화번호에 대한 의미적인 제한을 정의하는 것 또한 어려워 졌다.
1NF 측면에서 모호하지 않은 디자인은 2개의 테이블을 이용하는 것이다: 고객 명 테이블과 고객 전화번호 테이블이다.
이 디자인에서는 전화번호들의 중복되는 항목은 나오지 않는다. 대신 고객 대 전화번호의 연결이 레코드에 나온다. 고객 ID가 키 항목으로, "부모-자식" 또는 "일대 다(1:M)" 관계가 2개의 테이블사이에 존재하게 되는데, 이는 ("부모" 테이블에 있는) 고객 열이 ("자식" 테이블에 있는) 전화번호 열을 여러개 가질 수 있기 때문이다. 참고로 이 디자인은 제 2 정규형과 제 3 정규형을 충족하기도 한다.
에드거 F. 커드는 1NF의 정의에서 원자성에 대해서 언급하고 있다.에드거 F. 커드는 "관계가 정의된 도메인의 값은 DBMS에 대하여 원자성을 가져야 한다." 고 하였다. 에드거 F. 커드는 원자성을 갖는 값은 "(특수한 어떤 함수를 제외하고) DBMS에 의해서 더 작은 값으로 쪼개 지지 않는다" 고 하였다. 이는 한 항목이 하나 이상의 자료형으로 나뉘면서 DBMS가 분리된 다른 부분에 대해서 의존적이지 않아야 한다는 의미이다.
허그 다윈과 크리스토퍼 J. 데이트는 에드거 F. 커드의 "원자성을 갖는 값"의 정의가 모호하며, 이런 모호성이 1NF를 이해하는데 크게 방해된다고 제안하였다. "값이 나뉘지 않아야 한다"라는 정의에 해당하는 데이터형이 아래와 같은 이유로 거의 존재하지 않기 때문에 문제가 많다:크리스토퍼 J. 데이트는 "원자성이란 "절대적인 정의가 없다"": 고 하였다. 값은 목적에 따라서 원자성을 가질 수 도 있으며, 다른 목적을 위해서 나뉠 수도 있다. 이런 의견을 받아들이면 1NF의 정의에 원자성은 관련이 없어진다. 임의의 편한 자료형(문자열, 숫자형, 배열, 테이블 등)으로 정의된 행이라도 1NF 테이블일 수 있지만, 항상 그런 것은 아니다(예를 들어서, 고객 이름을 성과 이름으로 나누어야 할 때가 있다.) 크리스토퍼 J. 데이트는 심지어 관계 값을 갖는 속성, 즉 항목 안에 테이블이 있는 경우도 드문 경우에 유용하다고 하였다.
어떤 테이블이 제 2 정규형(2NF)이거나 그 이상이면 정의에 따라서 1NF이기도 하다.(어떤 정규형이라도 그 이전 정규형의 충분조건이 된다.) 반대로 어떤 테이블이 1NF이면 2NF가 아닐수도 있다. 2NF이면 제 3 정규형일 수도 있고, 아닐 수도 있다.
1NF 이상의 정규형은 디자인 문제로 인하여 그 안의 데이터의 완전성을 절충해야 하는 상황을 고려하여야 한다. 예를 들어 아래의 테이블은 1NF이지만 2NF가 아니며, 이에 따라서 논리적 불일치에 있어서 취약하다:
이 테이블의 키 는 {Subscriber ID, Email Address} 이다.
Carol Robertson이 결혼을 해서 성을 바꾼다면, 2개의 열을 변경하여야 한다. 1개의 열만 변경할 경우, 모순이 생긴다 : "고객 252의 이름은 무엇인가?"에 대한 질문에 2개의 혼란스러운 답변이 생긴다. 2NF는 이 문제를 해결한다. Carol Robertson의 레코드는 그녀가 1개 이상의 이메일 주소를 사용함에 따라서 테이블에서 2개로 나타나는 것을 주목하기 바란다.
1NF 이상의 정규화에 대해서 생각해볼 수 있는 실질적인 방법은 레코드(행)들과 엔티티(테이블) 또는 속성(열)의 관계에 대해서 끊임없이 질문해 보는 것이다. 예를 들어, 이용자 레코드가 많은 이메일 주소 레코드와 관계가 있는가? 하나의 이메일 주소가 많은 이용자들과 관계가 있는가? 위의 테이블에서는 Carol Robertson이 하나 이상의 이메일 주소를 가지고 있었다. 하나의 이용자는 다수의 이메일 주소를 가질수 있고, 다수의 이메일 주소는 하나의 이용자를 가질수 있으므로 위의 테이블운 이용자와 이메일 주소간에 일대다(1:M) 관계가 있다고 답할 수 있다. 이제 ID, 성, 이름을 가지고 ID를 주 키로 하는 "이용자 테이블" 과 ID, 이메일을 가지고 ID를 주 키로 하는 "이용자 이메일 테이블" 이라는 두 테이블이 있다면 ID를 주 키로 하는 "이용자 테이블" 과 ID를 외래 키로 하는 "이용자 이메일 테이블" 간에 1대 다 관계가 생기며, 이 테이블들도 1NF이게 된다.