제1정규형

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

제1정규형(1NF)은 관계형 데이터베이스에서 테이블이 가져야 하는 기본적인 정규화 형태로, 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위한 규칙을 정의한다. 1NF는 테이블의 각 열이 원자적인 값, 즉 더 이상 분해될 수 없는 단일 값을 가져야 하며, 각 행의 순서와 열의 순서가 중요하지 않다는 조건을 충족해야 한다. 1NF를 위반하는 경우 데이터베이스 설계의 문제점을 야기하며, 데이터 일관성 유지와 쿼리 성능 저하를 초래할 수 있다. 1NF는 데이터베이스 정규화의 기본 단계이며, 2NF 및 3NF와 같은 상위 정규형으로 나아가기 위한 기반이 된다.

제1정규형
📚 더 읽어볼만한 페이지
  • 관계대수 - 데이터베이스 정규화
    데이터베이스 정규화는 데이터 중복을 최소화하고 무결성을 보장하기 위해 데이터를 관련된 테이블로 분리하는 과정으로, 커드가 정의한 여러 단계의 정규형을 통해 이상 현상을 방지하고 데이터베이스 구조 확장에 유연하게 대처하는 것을 목표로 한다.
  • 데이터베이스 정규화 - 단일 진실 공급원
    단일 진실 공급원(SSOT)은 데이터 중복을 줄이고 일관성을 유지하여 의사 결정 및 운영 효율성을 향상시키기 위해 특정 정보에 대한 단 하나의 신뢰할 수 있는 출처를 만드는 개념이다.
  • 데이터베이스 정규화 - 제3정규형
    제3 정규형은 관계형 데이터베이스 설계 시 데이터 중복을 줄이고 무결성을 유지하기 위한 정규화 단계로, 제2 정규형을 만족하며 기본 키가 아닌 속성에 대한 전이적 종속성을 제거하는 것을 목표로 한다.
  • 데이터베이스 - 지식 베이스
    지식 베이스는 특정 주제 정보를 체계적으로 저장 및 관리하며 규칙 기반 추론으로 새로운 지식 도출에 활용되고, 웹 콘텐츠 관리 및 지식 관리 시스템으로 확장되어 온톨로지를 이용, 인공지능 기술과 결합하여 문제 해결책을 제시하고 경험을 통해 학습하는 시스템이다.
  • 데이터베이스 - 화이트리스트
    화이트리스트는 특정 대상만 허용하고 나머지는 차단하는 접근 제어 목록으로, 정보보안, 무역, 금융 등 다양한 분야에서 활용되지만, 목록 선정 기준의 불명확성, 사회적 문제점 등의 위험성으로 투명하고 엄격한 관리가 필요하다.

2. 1NF의 정의

크리스토퍼 J. 데이트에 의하면 테이블은 "어떤 관계와 동일 구조"이면 1NF이다. 이는 아래의 5가지 조건을 충족한다는 의미이다:

# 열에는 위-아래의 순서가 없다.
# 행에는 좌-우의 순서가 없다.
# 중복되는 열이 없다.
# 모든 열과 행의 중복지점에는 (열과 행의)해당되는 분야에서 한 개의 값을 가진다.
# 모든 행은 규칙적이다. [즉, 열은 열ID, 오브젝트ID, 숨어있는(hidden) 타임 스탬프등과 같은 숨어있는(행)를 가지지 않는다.]

이런 조건을 충족하지 않는 테이블은 엄격히 보면 관계형이 아니라는 의미이며, 1NF가 아니다.

1NF의 정의를 충족하지 못하는 테이블(또는 뷰)의 예제들을 보자면,

* 유니크 키가 없다. 이런 테이블은 열의 중복을 허용하기 때문에, 3번 조건을 위배한다.
* 뷰의 결과가 특정한 순서를 가지게 정의한 뷰. 뷰의 측면에서 열의 정렬이 본질적이고 의미가 있을 경우. 이는 1번 조건을 위배한다. 관계에서의 튜플은 서로간의 순서가 없다.
* 최소한 하나의 Null 속성을 가지는 테이블. Null 속성은 모든 행의 영역에서 꼭 한 개의 값만을 가져야 하는 4번 조건을 위배한다. 하지만 4번 조건은 논란이 많은데, 에드거 F. 커드는 최근의 관계형 모델에 관한 견해에서 Null에 대한 명시적인 조항을 만들었었다.

데이트의 정의에 따르면, 테이블이 "어떤 관계와 동형"일 경우에만 제1정규형에 속하며, 이는 구체적으로 다음과 같은 다섯 가지 조건을 충족함을 의미한다.

# 행에 상하 순서가 없다.
# 열에 좌우 순서가 없다.
# 중복된 행이 없다.
# 모든 행-열 교차 지점에는 해당 도메인에서 정확히 하나의 값만 포함된다(그 외에는 아무것도 없다).
# 모든 열은 정규적이다[예: 행에는 행 ID, 객체 ID 또는 숨겨진 타임스탬프와 같은 숨겨진 구성 요소가 없다].

이러한 조건 중 하나라도 위반하면 해당 테이블은 엄격하게 관계형이 아니며, 따라서 제1정규형에 속하지 않는다.

제1정규형의 이러한 정의를 충족하지 않는 테이블(또는 뷰)의 예는 다음과 같다.

* 고유 키 제약 조건이 없는 테이블은 조건 3을 위반하여 중복된 행을 수용할 수 있다.
* 특정 순서로 결과를 반환하도록 정의된 뷰는 행 순서가 뷰의 본질적이고 의미 있는 측면이 된다. (이러한 뷰는 SQL:2003 표준을 준수하는 SQL을 사용하여 만들 수 없다.) 이는 조건 1을 위반한다. 실제 관계의 튜플은 서로에 대해 정렬되지 않는다.
* 하나 이상의 속성이 있는 테이블은 조건 4를 위반한다. 조건 4는 모든 열이 해당 열의 도메인에서 정확히 하나의 값을 포함하도록 요구한다. 조건 4의 이 측면은 논란의 여지가 있다. 이는 코드의 이후 관계형 모델에 대한 비전에서 중요한 변화를 보여준다. 이는 널을 명시적으로 허용했다. 크리스 데이트가 정의한 제1정규형은 관계 값을 갖는 속성(테이블 내의 테이블)을 허용한다. 데이트는 테이블 내의 열이 테이블을 포함할 수 있는 관계 값을 갖는 속성이 드문 경우에 유용하다고 주장한다.

2.1. 조건

테이블이 "어떤 관계와 동형"일 경우에만 제1정규형에 속하며, 이는 구체적으로 다음과 같은 다섯 가지 조건을 충족함을 의미한다.

# 행에 상하 순서가 없다.
# 열에 좌우 순서가 없다.
# 중복된 행이 없다.
# 모든 행-열 교차 지점에는 해당 도메인에서 정확히 하나의 값만 포함된다(그 외에는 아무것도 없다).
# 모든 열은 정규적이다[예: 행에는 행 ID, 객체 ID 또는 숨겨진 타임스탬프와 같은 숨겨진 구성 요소가 없다].

이러한 조건 중 하나라도 위반하면 해당 테이블은 엄격하게 관계형이 아니며, 따라서 제1정규형에 속하지 않는다.

제1정규형의 이러한 정의를 충족하지 않는 테이블(또는 뷰)의 예는 다음과 같다.

* 고유 키 제약 조건이 없는 테이블은 조건 3을 위반하여 중복된 행을 수용할 수 있다.
* 특정 순서로 결과를 반환하도록 정의된 뷰는 행 순서가 뷰의 본질적이고 의미 있는 측면이 된다. (이러한 뷰는 SQL:2003 표준을 준수하는 SQL을 사용하여 만들 수 없다.) 이는 조건 1을 위반한다. 실제 관계의 튜플은 서로에 대해 정렬되지 않는다.
* 하나 이상의 속성이 있는 테이블은 조건 4를 위반한다. 조건 4는 모든 열이 해당 열의 도메인에서 정확히 하나의 값을 포함하도록 요구한다. 조건 4의 이 측면은 논란의 여지가 있다. 이는 코드의 이후 관계형 모델에 대한 비전에서 중요한 변화를 보여준다. 이는 널을 명시적으로 허용했다. 크리스 데이트가 정의한 제1정규형은 관계 값을 갖는 속성(테이블 내의 테이블)을 허용한다. 데이트는 테이블 내의 열이 테이블을 포함할 수 있는 관계 값을 갖는 속성이 드문 경우에 유용하다고 주장한다.

2.2. 1NF 위반 사례

계층형 데이터베이스에서는 표현할 수 있지만 SQL은 중첩된 테이블을 지원하지 않기 때문에, 고객의 신용 카드 거래를 나타내는 다음 표는 제1정규형을 준수하지 않는다.

👆
좌우로 밀어서 보기
👆
좌우로 밀어서 보기
고객고객 ID거래
아브라함1
거래 ID날짜금액
128902003-10-14−87
129042003-10-15−50
아이작2
👆
좌우로 밀어서 보기
거래 ID날짜금액
128982003-10-14−21
야곱3
👆
좌우로 밀어서 보기
거래 ID날짜금액
129072003-10-15−18
149202003-11-20−70
150032003-11-27−60


각 고객에 해당하는 '반복 그룹'의 거래가 존재한다.

이러한 설계는 고객 거래와 관련된 모든 쿼리의 자동 평가를 복잡하게 만든다. 예를 들어, 2003년 10월에 발생한 모든 거래의 총 금액을 알아내려면 시스템은 먼저 각 고객의 거래 그룹을 풀고, 거래 날짜가 2003년 10월에 해당하는 모든 거래의 금액을 합산해야 한다.

코드(E. F. Codd)는 구조적 복잡성을 줄이면 사용자와 응용 프로그램 및 DBMS가 쿼리를 작성하고 평가하는 데 더 많은 권한과 유연성을 얻게 된다는 점을 강조했다.

3. 중복 항목

많은 사람들이 제1정규형 (1NF)을 정의하는 특성이라고 생각하는 에드거 F. 커드의 4번째 조건은 중복되는 항목에 관한 조건이다. 데이터베이스 디자인이 1NF를 위배하는 중복되는 항목을 가지는 경우는 아래와 같다.

* 1NF 위반 사례 및 해결

초보 데이터베이스 설계자가 고객의 이름과 전화번호를 기록할 때, 한 열에 여러 개의 전화번호를 저장하는 경우가 있다. 이는 한 행의 도메인에 정확히 하나의 값만 허용하는 제1정규형(1NF)을 위반하는 것이다.

예를 들어, 아래의 'Customer' 테이블은 'Telephone Number' 열에 여러 개의 전화번호 값을 저장하여 1NF를 위반한다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTelephone Number
123RobertIngram555-861-2025
456JaneWright555-403-1659
555-776-4100
789MariaFernandez555-808-9633


이러한 문제를 해결하기 위해 여러 개의 전화번호 열을 만드는 시도는 Null 값을 허용하게 되어 또 다른 문제를 야기한다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTel. No. 1Tel. No. 2Tel. No. 3
123RobertIngram555-861-2025
456JaneWright555-403-1659555-776-4100555-403-1659
789MariaFernandez555-808-9633


이 방식은 크리스토퍼 J. 데이트의 1NF 정의에 위배되며, 다음과 같은 논리적인 문제점을 야기한다.

* "어느 고객이 전화번호 X를 가지고 있는가?"와 같은 질의에 답하기 어렵다.
* 고객-전화번호의 유일성을 확보하기 어렵다.
* 전화번호 개수에 제한이 생긴다.

또 다른 방법으로, 전화번호 열의 길이를 늘려 여러 번호를 기록하는 방식이 있다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTelephone Numbers
123RobertIngram555-861-2025
456JaneWright555-403-1659, 555-776-4100
789MariaFernandez555-808-9633


이 방식은 1NF를 충족하지만, 데이터 의미가 모호해지고 질의가 어려워지는 단점이 있다.

1NF를 충족하는 올바른 설계는 고객 정보 테이블과 고객 전화번호 테이블로 분리하여 1:M (일대다) 관계를 설정하는 것이다.

👆
좌우로 밀어서 보기
Customer Name
Customer IDFirst NameSurname
123RobertIngram
456JaneWright
789MariaFernandez

👆
좌우로 밀어서 보기
Customer Telephone Number
Customer IDTelephone Number
123555-861-2025
456555-403-1659
456555-776-4100
789555-808-9633


이 디자인은 제2 정규형과 제3 정규형도 충족한다.

고객의 신용 카드 거래를 나타내는 다음의 예시 또한 제1정규형의 위반 사례 및 해결을 보여준다.

제1정규형을 위반하는 데이터 구조는 다음과 같다.

👆
좌우로 밀어서 보기
👆
좌우로 밀어서 보기
고객고객 ID거래
아브라함1
거래 ID날짜금액
128902003-10-14−87
129042003-10-15−50
아이작2
👆
좌우로 밀어서 보기
거래 ID날짜금액
128982003-10-14−21
야곱3
👆
좌우로 밀어서 보기
거래 ID날짜금액
129072003-10-15−18
149202003-11-20−70
150032003-11-27−60


위의 표는 각 고객에 해당하는 '반복 그룹'의 거래를 포함하여 제1정규형을 위반한다.

제1 정규형으로 정규화한 데이터 구조는 다음과 같다.

👆
좌우로 밀어서 보기
고객고객 ID
아브라함1
아이작2
야곱3


👆
좌우로 밀어서 보기
고객 ID거래 ID날짜금액
1128902003-10-14−87
1129042003-10-15−50
2128982003-10-14−21
3129072003-10-15−18
3149202003-11-20−70
3150032003-11-27−60


수정된 구조에서는 기본 키가 첫 번째 관계에서는 {고객 ID}이고, 두 번째 관계에서는 {고객 ID, 거래 ID}가 된다.

3.1. 1NF 위반 사례 및 해결

초보 데이터베이스 설계자가 고객의 이름과 전화번호를 기록할 때, 한 열에 여러 개의 전화번호를 저장하는 경우가 있다. 이는 한 행의 도메인에 정확히 하나의 값만 허용하는 제1정규형(1NF)을 위반하는 것이다.

예를 들어, 아래의 'Customer' 테이블은 'Telephone Number' 열에 여러 개의 전화번호 값을 저장하여 1NF를 위반한다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTelephone Number
123RobertIngram555-861-2025
456JaneWright555-403-1659
555-776-4100
789MariaFernandez555-808-9633


이러한 문제를 해결하기 위해 여러 개의 전화번호 열을 만드는 시도는 Null 값을 허용하게 되어 또 다른 문제를 야기한다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTel. No. 1Tel. No. 2Tel. No. 3
123RobertIngram555-861-2025
456JaneWright555-403-1659555-776-4100555-403-1659
789MariaFernandez555-808-9633


이 방식은 크리스토퍼 J. 데이트의 1NF 정의에 위배되며, 다음과 같은 논리적인 문제점을 야기한다.

* "어느 고객이 전화번호 X를 가지고 있는가?"와 같은 질의에 답하기 어렵다.
* 고객-전화번호의 유일성을 확보하기 어렵다.
* 전화번호 개수에 제한이 생긴다.

또 다른 방법으로, 전화번호 열의 길이를 늘려 여러 번호를 기록하는 방식이 있다.

👆
좌우로 밀어서 보기
Customer
Customer IDFirst NameSurnameTelephone Numbers
123RobertIngram555-861-2025
456JaneWright555-403-1659, 555-776-4100
789MariaFernandez555-808-9633


이 방식은 1NF를 충족하지만, 데이터 의미가 모호해지고 질의가 어려워지는 단점이 있다.

1NF를 충족하는 올바른 설계는 고객 정보 테이블과 고객 전화번호 테이블로 분리하여 1:M (일대다) 관계를 설정하는 것이다.

👆
좌우로 밀어서 보기
Customer Name
Customer IDFirst NameSurname
123RobertIngram
456JaneWright
789MariaFernandez

👆
좌우로 밀어서 보기
Customer Telephone Number
Customer IDTelephone Number
123555-861-2025
456555-403-1659
456555-776-4100
789555-808-9633




이 디자인은 제2 정규형과 제3 정규형도 충족한다.

고객의 신용 카드 거래를 나타내는 다음의 예시 또한 제1정규형의 위반 사례 및 해결을 보여준다.

제1정규형을 위반하는 데이터 구조는 다음과 같다.

👆
좌우로 밀어서 보기
👆
좌우로 밀어서 보기
고객고객 ID거래
아브라함1
거래 ID날짜금액
128902003-10-14−87
129042003-10-15−50
아이작2
👆
좌우로 밀어서 보기
거래 ID날짜금액
128982003-10-14−21
야곱3
👆
좌우로 밀어서 보기
거래 ID날짜금액
129072003-10-15−18
149202003-11-20−70
150032003-11-27−60


위의 표는 각 고객에 해당하는 '반복 그룹'의 거래를 포함하여 제1정규형을 위반한다.

제1 정규형으로 정규화한 데이터 구조는 다음과 같다.

👆
좌우로 밀어서 보기
고객고객 ID
아브라함1
아이작2
야곱3


👆
좌우로 밀어서 보기
고객 ID거래 ID날짜금액
1128902003-10-14−87
1129042003-10-15−50
2128982003-10-14−21
3129072003-10-15−18
3149202003-11-20−70
3150032003-11-27−60


수정된 구조에서는 기본 키가 첫 번째 관계에서는 {고객 ID}이고, 두 번째 관계에서는 {고객 ID, 거래 ID}가 된다.

4. 원자성 (Atomicity)

에드거 F. 커드는 1NF의 정의에서 원자성에 대해서 언급하고 있다. 커드는 "관계가 정의된 도메인의 값은 DBMS에 대하여 원자성을 가져야 한다." 고 하였다. 커드는 원자성을 갖는 값은 "(특수한 어떤 함수를 제외하고) DBMS에 의해서 더 작은 값으로 쪼개 지지 않는다" 고 하였다. 이는 한 항목이 하나 이상의 자료형으로 나뉘면서 DBMS가 분리된 다른 부분에 대해서 의존적이지 않아야 한다는 의미이다.

휴 다윈과 크리스토퍼 J. 데이트는 커드의 "원자성을 갖는 값"의 정의가 모호하며, 이런 모호성이 1NF를 이해하는데 크게 방해된다고 제안하였다. "값이 나뉘지 않아야 한다"라는 정의에 해당하는 데이터형이 아래와 같은 이유로 거의 존재하지 않기 때문에 문제가 많다.

* 문자열은 RDBMS가 일반적으로 문자열을 부분 문자열로 분해하는 연산자를 제공하므로 원자적이지 않은 것으로 보인다.
* 고정 소수점 숫자는 RDBMS가 일반적으로 정수 및 소수 부분으로 분해하는 연산자를 제공하므로 원자적이지 않은 것으로 보인다.
* ISBN은 언어 및 출판사 식별자를 포함하므로 원자적이지 않은 것으로 보인다.

크리스토퍼 J. 데이트는 "원자성이란 절대적인 정의가 없다": 고 하였다. 값은 목적에 따라서 원자성을 가질 수 도 있으며, 다른 목적을 위해서 나뉠 수도 있다. 이 입장이 받아들여지면 제1정규형은 원자성을 참조하여 정의될 수 없다. 크리스토퍼 J. 데이트는 심지어 관계 값을 갖는 속성, 즉 항목 안에 테이블이 있는 경우도 드문 경우에 유용하다고 하였다. 문자열 유형과 숫자 유형부터 배열 자료 구조 유형 및 테이블 유형에 이르기까지 모든 가능한 데이터 유형의 열은 제1정규형 테이블에서 허용된다(항상 바람직하지는 않을 수 있지만).

5. 1NF 이상의 정규화

어떤 테이블이 제 2 정규형(2NF)이거나 그 이상이면 정의에 따라서 1NF이기도 하다. 반대로 어떤 테이블이 1NF이면 2NF가 아닐수도 있다. 2NF이면 제 3 정규형일 수도 있고, 아닐 수도 있다.

1NF 이상의 정규형은 디자인 문제로 인하여 그 안의 데이터의 완전성을 절충해야 하는 상황을 고려하여야 한다. 예를 들어, 다음의 테이블은 1NF이지만 2NF가 아니며, 이에 따라서 논리적 불일치에 있어서 취약하다.

👆
좌우로 밀어서 보기
Subscriber Email Addresses
Subscriber IDEmail AddressSubscriber First NameSubscriber Surname
108[email protected]SteveWallace
252[email protected]CarolRobertson
252[email protected]CarolRobertson
360[email protected]HarrietClark


이 테이블의 는 {Subscriber ID, Email Address}이다.

Carol Robertson이 결혼을 해서 성을 바꾼다면, 2개의 열을 변경하여야 한다. 1개의 열만 변경할 경우, 모순이 생긴다. "고객 252의 이름은 무엇인가?"에 대한 질문에 2개의 혼란스러운 답변이 생긴다. 2NF는 이 문제를 해결한다.

1NF 이상의 정규화에 대해서 생각해볼 수 있는 실질적인 방법은 레코드(행)들과 엔티티(테이블) 또는 속성(열)의 관계에 대해서 끊임없이 질문해 보는 것이다. 예를 들어, 이용자 레코드가 많은 이메일 주소 레코드와 관계가 있는지, 하나의 이메일 주소가 많은 이용자들과 관계가 있는지 질문해 볼 수 있다. 위의 테이블에서는 Carol Robertson이 하나 이상의 이메일 주소를 가지고 있었다. 하나의 이용자는 다수의 이메일 주소를 가질수 있고, 다수의 이메일 주소는 하나의 이용자를 가질수 있으므로 위의 테이블은 이용자와 이메일 주소간에 일대다(1:M) 관계가 있다고 답할 수 있다. 이제 ID, 성, 이름을 가지고 ID를 주 키로 하는 "이용자 테이블" 과 ID, 이메일을 가지고 ID를 주 키로 하는 "이용자 이메일 테이블"이라는 두 테이블이 있다면 ID를 주 키로 하는 "이용자 테이블" 과 ID를 외래 키로 하는 "이용자 이메일 테이블" 간에 1대 다 관계가 생기며, 이 테이블들도 1NF이게 된다.

6. 비판 및 한계

제1정규형은 특정 작업에서 성능 저하를 유발할 수 있다. 계층적 모델에서는 중첩된 레코드가 상위 레코드 다음에 물리적으로 저장되어 단일 읽기 작업으로 전체 하위 트리를 검색할 수 있지만, 제1정규형에서는 레코드 유형별로 조인 연산이 필요하며, 이는 특히 복잡한 트리에서 비용이 많이 들 수 있다. 이러한 이유로 문서 데이터베이스는 제1정규형을 피하기도 한다.

객체 지향 언어는 런타임 상태를 포인터 또는 참조로 연결된 객체의 트리 또는 방향 그래프로 나타낸다. 이는 제1정규형 관계형 데이터베이스에 깔끔하게 매핑되지 않으며, 이는 때때로 객체-관계형 임피던스 불일치라고 불리는 문제이며, 객체 관계형 매퍼 (ORM) 라이브러리가 해결하려고 한다.