제1정규형
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
제1정규형(1NF)은 관계형 데이터베이스에서 테이블이 가져야 하는 기본적인 정규화 형태로, 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위한 규칙을 정의한다. 1NF는 테이블의 각 열이 원자적인 값, 즉 더 이상 분해될 수 없는 단일 값을 가져야 하며, 각 행의 순서와 열의 순서가 중요하지 않다는 조건을 충족해야 한다. 1NF를 위반하는 경우 데이터베이스 설계의 문제점을 야기하며, 데이터 일관성 유지와 쿼리 성능 저하를 초래할 수 있다. 1NF는 데이터베이스 정규화의 기본 단계이며, 2NF 및 3NF와 같은 상위 정규형으로 나아가기 위한 기반이 된다.
더 읽어볼만한 페이지
- 관계대수 - 데이터베이스 정규화
데이터베이스 정규화는 데이터 중복을 최소화하고 무결성을 보장하기 위해 데이터를 관련된 테이블로 분리하는 과정으로, 커드가 정의한 여러 단계의 정규형을 통해 이상 현상을 방지하고 데이터베이스 구조 확장에 유연하게 대처하는 것을 목표로 한다. - 데이터베이스 정규화 - 단일 진실 공급원
단일 진실 공급원(SSOT)은 데이터 중복을 줄이고 일관성을 유지하여 의사 결정 및 운영 효율성을 향상시키기 위해 특정 정보에 대한 단 하나의 신뢰할 수 있는 출처를 만드는 개념이다. - 데이터베이스 정규화 - 제3정규형
제3 정규형은 관계형 데이터베이스 설계 시 데이터 중복을 줄이고 무결성을 유지하기 위한 정규화 단계로, 제2 정규형을 만족하며 기본 키가 아닌 속성에 대한 전이적 종속성을 제거하는 것을 목표로 한다. - 데이터 모델링 - 빌딩 정보 모델링
빌딩 정보 모델링(BIM)은 건축물의 전 생애주기 동안 발생하는 정보를 디지털 모델로 통합 관리하는 프로세스이다. - 데이터 모델링 - 저장 프로시저
저장 프로시저는 데이터베이스 관리 시스템에서 SQL 문들을 미리 컴파일하여 저장하고, 모듈화, 보안성, 성능 향상, 유지보수 용이성과 같은 특징을 가지며, 데이터베이스 시스템마다 구현 방식과 지원하는 언어가 다를 수 있는 코드 묶음이다.
| 제1정규형 |
|---|
2. 1NF의 정의
크리스토퍼 J. 데이트에 의하면 테이블은 "어떤 관계와 동일 구조"이면 1NF이다. 이는 아래의 5가지 조건을 충족한다는 의미이다:[18]
# 열에는 위-아래의 순서가 없다.
# 행에는 좌-우의 순서가 없다.
# 중복되는 열이 없다.
# 모든 열과 행의 중복지점에는 (열과 행의)해당되는 분야에서 한 개의 값을 가진다.
# 모든 행은 규칙적이다. [즉, 열은 열ID, 오브젝트ID, 숨어있는(hidden) 타임 스탬프등과 같은 숨어있는(행)를 가지지 않는다.]
이런 조건을 충족하지 않는 테이블은 엄격히 보면 관계형이 아니라는 의미이며, 1NF가 아니다.
1NF의 정의를 충족하지 못하는 테이블(또는 뷰)의 예제들을 보자면,
- 유니크 키가 없다. 이런 테이블은 열의 중복을 허용하기 때문에, 3번 조건을 위배한다.
- 뷰의 결과가 특정한 순서를 가지게 정의한 뷰. 뷰의 측면에서 열의 정렬이 본질적이고 의미가 있을 경우.[19] 이는 1번 조건을 위배한다. 관계에서의 튜플은 서로간의 순서가 없다.
- 최소한 하나의 Null 속성을 가지는 테이블. Null 속성은 모든 행의 영역에서 꼭 한 개의 값만을 가져야 하는 4번 조건을 위배한다. 하지만 4번 조건은 논란이 많은데, 에드거 F. 커드는 최근의 관계형 모델에 관한 견해에서 Null에 대한 명시적인 조항을 만들었었다.[20][21]
데이트의 정의에 따르면, 테이블이 "어떤 관계와 동형"일 경우에만 제1정규형에 속하며, 이는 구체적으로 다음과 같은 다섯 가지 조건을 충족함을 의미한다.[11]
# 행에 상하 순서가 없다.
# 열에 좌우 순서가 없다.
# 중복된 행이 없다.
# 모든 행-열 교차 지점에는 해당 도메인에서 정확히 하나의 값만 포함된다(그 외에는 아무것도 없다).
# 모든 열은 정규적이다[예: 행에는 행 ID, 객체 ID 또는 숨겨진 타임스탬프와 같은 숨겨진 구성 요소가 없다].
이러한 조건 중 하나라도 위반하면 해당 테이블은 엄격하게 관계형이 아니며, 따라서 제1정규형에 속하지 않는다.
제1정규형의 이러한 정의를 충족하지 않는 테이블(또는 뷰)의 예는 다음과 같다.
- 고유 키 제약 조건이 없는 테이블은 조건 3을 위반하여 중복된 행을 수용할 수 있다.
- 특정 순서로 결과를 반환하도록 정의된 뷰는 행 순서가 뷰의 본질적이고 의미 있는 측면이 된다. (이러한 뷰는 SQL:2003 표준을 준수하는 SQL을 사용하여 만들 수 없다.) 이는 조건 1을 위반한다. 실제 관계의 튜플은 서로에 대해 정렬되지 않는다.
- 하나 이상의 널 속성이 있는 테이블은 조건 4를 위반한다. 조건 4는 모든 열이 해당 열의 도메인에서 정확히 하나의 값을 포함하도록 요구한다. 조건 4의 이 측면은 논란의 여지가 있다. 이는 코드의 이후 관계형 모델에 대한 비전에서 중요한 변화를 보여준다.[12] 이는 널을 명시적으로 허용했다.[13] 크리스 데이트가 정의한 제1정규형은 관계 값을 갖는 속성(테이블 내의 테이블)을 허용한다. 데이트는 테이블 내의 열이 테이블을 포함할 수 있는 관계 값을 갖는 속성이 드문 경우에 유용하다고 주장한다.[14]
2. 1. 조건
테이블이 "어떤 관계와 동형"일 경우에만 제1정규형에 속하며, 이는 구체적으로 다음과 같은 다섯 가지 조건을 충족함을 의미한다.[11]# 행에 상하 순서가 없다.
# 열에 좌우 순서가 없다.
# 중복된 행이 없다.
# 모든 행-열 교차 지점에는 해당 도메인에서 정확히 하나의 값만 포함된다(그 외에는 아무것도 없다).
# 모든 열은 정규적이다[예: 행에는 행 ID, 객체 ID 또는 숨겨진 타임스탬프와 같은 숨겨진 구성 요소가 없다].
이러한 조건 중 하나라도 위반하면 해당 테이블은 엄격하게 관계형이 아니며, 따라서 제1정규형에 속하지 않는다.
제1정규형의 이러한 정의를 충족하지 않는 테이블(또는 뷰)의 예는 다음과 같다.
- 고유 키 제약 조건이 없는 테이블은 조건 3을 위반하여 중복된 행을 수용할 수 있다.
- 특정 순서로 결과를 반환하도록 정의된 뷰는 행 순서가 뷰의 본질적이고 의미 있는 측면이 된다. (이러한 뷰는 SQL:2003 표준을 준수하는 SQL을 사용하여 만들 수 없다.) 이는 조건 1을 위반한다. 실제 관계의 튜플은 서로에 대해 정렬되지 않는다.
- 하나 이상의 널 속성이 있는 테이블은 조건 4를 위반한다. 조건 4는 모든 열이 해당 열의 도메인에서 정확히 하나의 값을 포함하도록 요구한다. 조건 4의 이 측면은 논란의 여지가 있다. 이는 코드의 이후 관계형 모델에 대한 비전에서 중요한 변화를 보여준다.[12] 이는 널을 명시적으로 허용했다.[13] 크리스 데이트가 정의한 제1정규형은 관계 값을 갖는 속성(테이블 내의 테이블)을 허용한다. 데이트는 테이블 내의 열이 테이블을 포함할 수 있는 관계 값을 갖는 속성이 드문 경우에 유용하다고 주장한다.[14]
2. 2. 1NF 위반 사례
계층형 데이터베이스에서는 표현할 수 있지만 SQL은 중첩된 테이블을 지원하지 않기 때문에, 고객의 신용 카드 거래를 나타내는 다음 표는 제1정규형을 준수하지 않는다.{| class="wikitable"
! 고객 !! 고객 ID !! 거래
|-
| 아브라함 || 1
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12890 | 2003-10-14 | −87 |
| 12904 | 2003-10-15 | −50 |
|-
| 아이작 || 2
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12898 | 2003-10-14 | −21 |
|-
| 야곱 || 3
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12907 | 2003-10-15 | −18 |
| 14920 | 2003-11-20 | −70 |
| 15003 | 2003-11-27 | −60 |
많은 사람들이 제1정규형 (1NF)을 정의하는 특성이라고 생각하는[22] 에드거 F. 커드의 4번째 조건은 중복되는 항목에 관한 조건이다. 데이터베이스 디자인이 1NF를 위배하는 중복되는 항목을 가지는 경우는 아래와 같다.
|}
각 고객에 해당하는 '반복 그룹'의 거래가 존재한다.
이러한 설계는 고객 거래와 관련된 모든 쿼리의 자동 평가를 복잡하게 만든다. 예를 들어, 2003년 10월에 발생한 모든 거래의 총 금액을 알아내려면 시스템은 먼저 각 고객의 ''거래'' 그룹을 풀고, 거래 ''날짜''가 2003년 10월에 해당하는 모든 거래의 ''금액''을 합산해야 한다.
코드(E. F. Codd)는 구조적 복잡성을 줄이면 사용자와 응용 프로그램 및 DBMS가 쿼리를 작성하고 평가하는 데 더 많은 권한과 유연성을 얻게 된다는 점을 강조했다.
3. 중복 항목
초보 데이터베이스 설계자가 고객의 이름과 전화번호를 기록할 때, 한 열에 여러 개의 전화번호를 저장하는 경우가 있다. 이는 한 행의 도메인에 정확히 하나의 값만 허용하는 제1정규형(1NF)을 위반하는 것이다.
예를 들어, 아래의 'Customer' 테이블은 'Telephone Number' 열에 여러 개의 전화번호 값을 저장하여 1NF를 위반한다.
| 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 |
이러한 문제를 해결하기 위해 여러 개의 전화번호 열을 만드는 시도는 Null 값을 허용하게 되어 또 다른 문제를 야기한다.
| 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 |
이 방식은 크리스토퍼 J. 데이트의 1NF 정의에 위배되며, 다음과 같은 논리적인 문제점을 야기한다.
- "어느 고객이 전화번호 '''X'''를 가지고 있는가?"와 같은 질의에 답하기 어렵다.
- 고객-전화번호의 유일성을 확보하기 어렵다.
- 전화번호 개수에 제한이 생긴다.
또 다른 방법으로, 전화번호 열의 길이를 늘려 여러 번호를 기록하는 방식이 있다.
| 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를 충족하지만, 데이터 의미가 모호해지고 질의가 어려워지는 단점이 있다.
1NF를 충족하는 올바른 설계는 고객 정보 테이블과 고객 전화번호 테이블로 분리하여 1:M (일대다) 관계를 설정하는 것이다.
| Customer ID | First Name | Surname |
|---|---|---|
| 123 | Robert | Ingram |
| 456 | Jane | Wright |
| 789 | Maria | Fernandez |
| Customer ID | Telephone Number |
|---|---|
| 123 | 555-861-2025 |
| 456 | 555-403-1659 |
| 456 | 555-776-4100 |
| 789 | 555-808-9633 |
이 디자인은 제2 정규형과 제3 정규형도 충족한다.
고객의 신용 카드 거래를 나타내는 다음의 예시 또한 제1정규형의 위반 사례 및 해결을 보여준다.
제1정규형을 위반하는 데이터 구조는 다음과 같다.
{| class="wikitable"
! 고객 !! 고객 ID !! 거래
|-
| 아브라함 || 1 ||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12890 | 2003-10-14 | −87 |
| 12904 | 2003-10-15 | −50 |
|-
| 아이작 || 2 ||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12898 | 2003-10-14 | −21 |
|-
| 야곱 || 3 ||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12907 | 2003-10-15 | −18 |
| 14920 | 2003-11-20 | −70 |
| 15003 | 2003-11-27 | −60 |
|}
위의 표는 각 고객에 해당하는 '반복 그룹'의 거래를 포함하여 제1정규형을 위반한다.
제1 정규형으로 정규화한 데이터 구조는 다음과 같다.[4]
| 고객 | 고객 ID |
|---|---|
| 아브라함 | 1 |
| 아이작 | 2 |
| 야곱 | 3 |
| 고객 ID | 거래 ID | 날짜 | 금액 |
|---|---|---|---|
| 1 | 12890 | 2003-10-14 | −87 |
| 1 | 12904 | 2003-10-15 | −50 |
| 2 | 12898 | 2003-10-14 | −21 |
| 3 | 12907 | 2003-10-15 | −18 |
| 3 | 14920 | 2003-11-20 | −70 |
| 3 | 15003 | 2003-11-27 | −60 |
수정된 구조에서는 기본 키가 첫 번째 관계에서는 {고객 ID}이고, 두 번째 관계에서는 {고객 ID, 거래 ID}가 된다.
3. 1. 1NF 위반 사례 및 해결
초보 데이터베이스 설계자가 고객의 이름과 전화번호를 기록할 때, 한 열에 여러 개의 전화번호를 저장하는 경우가 있다. 이는 한 행의 도메인에 정확히 하나의 값만 허용하는 제1정규형(1NF)을 위반하는 것이다.예를 들어, 아래의 'Customer' 테이블은 'Telephone Number' 열에 여러 개의 전화번호 값을 저장하여 1NF를 위반한다.
| 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 |
이러한 문제를 해결하기 위해 여러 개의 전화번호 열을 만드는 시도는 Null 값을 허용하게 되어 또 다른 문제를 야기한다.
| 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 | ||
이 방식은 크리스토퍼 J. 데이트의 1NF 정의에 위배되며, 다음과 같은 논리적인 문제점을 야기한다.
- "어느 고객이 전화번호 '''X'''를 가지고 있는가?"와 같은 질의에 답하기 어렵다.
- 고객-전화번호의 유일성을 확보하기 어렵다.
- 전화번호 개수에 제한이 생긴다.
또 다른 방법으로, 전화번호 열의 길이를 늘려 여러 번호를 기록하는 방식이 있다.
| 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를 충족하지만, 데이터 의미가 모호해지고 질의가 어려워지는 단점이 있다.
1NF를 충족하는 올바른 설계는 고객 정보 테이블과 고객 전화번호 테이블로 분리하여 1:M (일대다) 관계를 설정하는 것이다.
| Customer ID | First Name | Surname |
|---|---|---|
| 123 | Robert | Ingram |
| 456 | Jane | Wright |
| 789 | Maria | Fernandez |
| Customer ID | Telephone Number |
|---|---|
| 123 | 555-861-2025 |
| 456 | 555-403-1659 |
| 456 | 555-776-4100 |
| 789 | 555-808-9633 |
이 디자인은 제2 정규형과 제3 정규형도 충족한다.
고객의 신용 카드 거래를 나타내는 다음의 예시 또한 제1정규형의 위반 사례 및 해결을 보여준다.
제1정규형을 위반하는 데이터 구조는 다음과 같다.
{| class="wikitable"
! 고객 !! 고객 ID !! 거래
|-
| 아브라함 || 1
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12890 | 2003-10-14 | −87 |
| 12904 | 2003-10-15 | −50 |
|-
| 아이작 || 2
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12898 | 2003-10-14 | −21 |
|-
| 야곱 || 3
||
| 거래 ID | 날짜 | 금액 |
|---|---|---|
| 12907 | 2003-10-15 | −18 |
| 14920 | 2003-11-20 | −70 |
| 15003 | 2003-11-27 | −60 |
|}
위의 표는 각 고객에 해당하는 '반복 그룹'의 거래를 포함하여 제1정규형을 위반한다.
제1 정규형으로 정규화한 데이터 구조는 다음과 같다.[4]
| 고객 | 고객 ID |
|---|---|
| 아브라함 | 1 |
| 아이작 | 2 |
| 야곱 | 3 |
| 고객 ID | 거래 ID | 날짜 | 금액 |
|---|---|---|---|
| 1 | 12890 | 2003-10-14 | −87 |
| 1 | 12904 | 2003-10-15 | −50 |
| 2 | 12898 | 2003-10-14 | −21 |
| 3 | 12907 | 2003-10-15 | −18 |
| 3 | 14920 | 2003-11-20 | −70 |
| 3 | 15003 | 2003-11-27 | −60 |
수정된 구조에서는 기본 키가 첫 번째 관계에서는 {고객 ID}이고, 두 번째 관계에서는 {고객 ID, 거래 ID}가 된다.
4. 원자성 (Atomicity)
에드거 F. 커드는 1NF의 정의에서 '''원자성'''에 대해서 언급하고 있다. 커드는 "관계가 정의된 도메인의 값은 DBMS에 대하여 원자성을 가져야 한다."[23] 고 하였다. 커드는 원자성을 갖는 값은 "(특수한 어떤 함수를 제외하고) DBMS에 의해서 더 작은 값으로 쪼개 지지 않는다"[24] 고 하였다. 이는 한 항목이 하나 이상의 자료형으로 나뉘면서 DBMS가 분리된 다른 부분에 대해서 의존적이지 않아야 한다는 의미이다.[5][6]
휴 다윈과 크리스토퍼 J. 데이트는 커드의 "원자성을 갖는 값"의 정의가 모호하며, 이런 모호성이 1NF를 이해하는데 크게 방해된다고 제안하였다.[25][26][7][8] "값이 나뉘지 않아야 한다"라는 정의에 해당하는 데이터형이 아래와 같은 이유로 거의 존재하지 않기 때문에 문제가 많다.
- 문자열은 RDBMS가 일반적으로 문자열을 부분 문자열로 분해하는 연산자를 제공하므로 원자적이지 않은 것으로 보인다.
- 고정 소수점 숫자는 RDBMS가 일반적으로 정수 및 소수 부분으로 분해하는 연산자를 제공하므로 원자적이지 않은 것으로 보인다.
- ISBN은 언어 및 출판사 식별자를 포함하므로 원자적이지 않은 것으로 보인다.
크리스토퍼 J. 데이트는 "원자성이란 ''절대적인 정의가 없다''":[27] 고 하였다. 값은 목적에 따라서 원자성을 가질 수 도 있으며, 다른 목적을 위해서 나뉠 수도 있다. 이 입장이 받아들여지면 제1정규형은 원자성을 참조하여 정의될 수 없다.[9][10] 크리스토퍼 J. 데이트는 심지어 관계 값을 갖는 속성, 즉 항목 안에 테이블이 있는 경우도 드문 경우에 유용하다고 하였다.[28] 문자열 유형과 숫자 유형부터 배열 자료 구조 유형 및 테이블 유형에 이르기까지 모든 가능한 데이터 유형의 열은 제1정규형 테이블에서 허용된다(항상 바람직하지는 않을 수 있지만).
5. 1NF 이상의 정규화
어떤 테이블이 제 2 정규형(2NF)이거나 그 이상이면 정의에 따라서 1NF이기도 하다. 반대로 어떤 테이블이 1NF이면 2NF가 아닐수도 있다. 2NF이면 제 3 정규형일 수도 있고, 아닐 수도 있다.
1NF 이상의 정규형은 디자인 문제로 인하여 그 안의 데이터의 완전성을 절충해야 하는 상황을 고려하여야 한다. 예를 들어, 다음의 테이블은 1NF이지만 2NF가 아니며, 이에 따라서 논리적 불일치에 있어서 취약하다.
| Subscriber ID | Email Address | Subscriber First Name | Subscriber Surname |
|---|---|---|---|
| 108 | steve@aardvarkmail.net | Steve | Wallace |
| 252 | carol@mongoosemail.org | Carol | Robertson |
| 252 | crobertson@aardvarkmail.net | Carol | Robertson |
| 360 | hclark@antelopemail.com | Harriet | Clark |
이 테이블의 키는 {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) 라이브러리가 해결하려고 한다.
참조
[1]
논문
A Relational Model of Data for Large Shared Data Banks
1970
[2]
논문
A Relational Model of Data for Large Shared Data Banks
1970
[3]
논문
Further Normalization of the Relational Model
1971
[4]
논문
A Relational Model of Data for Large Shared Data Banks
1970
[5]
서적
The Relational Model for Database Management Version 2
Addison-Wesley
1990
[6]
서적
The Relational Model for Database Management Version 2
Addison-Wesley
1990
[7]
서적
Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?
Addison-Wesley
1992
[8]
서적
What First Normal Form Really Means
Apress
2007
[9]
서적
What First Normal Form Really Means
Apress
2007
[10]
서적
SQL and Relational Theory: How to Write Accurate SQL Code
https://books.google[...]
O'Reilly Media
2018-10-31
[11]
서적
What First Normal Form Really Means
Apress
2007
[12]
서적
SQL and Relational Theory
O'Reilly
[13]
간행물
Is Your DBMS Really Relational?
1985-10-14
[14]
서적
What First Normal Form Really Means
Apress
2007
[15]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
Springer-Verlag
2006
[16]
논문
A Simple Guide to Five Normal Forms in Relational Database Theory
http://www.bkent.net[...]
1983-02
[17]
서적
Fundamentals of Database Systems, Fourth Edition
Addison-Wesley
2003
[18]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
[19]
문서
[20]
서적
SQL and Relational Theory
O'Reilly
2009
[21]
간행물
Is Your DBMS Really Relational?
1985-10-14
[22]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
[23]
서적
The Relational Model for Database Management Version 2
Addison-Wesley
1990
[24]
서적
The Relational Model for Database Management Version 2
Addison-Wesley
1990
[25]
서적
Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?
Addison-Wesley
1992
[26]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
Springer-Verlag
2006
[27]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
[28]
웹사이트
What First Normal Form Really Means
http://www.dbdebunk.[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com