데이터베이스 정규화
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
데이터베이스 정규화는 데이터 중복을 줄이고 데이터 무결성을 향상시키기 위해 관계형 데이터베이스 테이블을 설계하는 기술이다. 에드거 F. 커드가 제안한 정규화는 삽입, 갱신, 삭제 이상을 방지하고 데이터베이스 구조를 유연하게 유지하는 것을 목표로 한다. 정규화는 여러 단계의 정규형으로 이루어져 있으며, 1NF, 2NF, 3NF, BCNF 등이 널리 사용된다. 실제 데이터베이스 설계에서는 성능과 복잡성을 고려하여 적절한 수준의 정규화를 적용하며, 함수 종속성, 다치 종속성, 조인 종속성 등의 개념이 정규화 과정에서 중요한 역할을 한다.
더 읽어볼만한 페이지
- 관계대수 - 제1정규형
제1정규형(1NF)은 관계형 데이터베이스에서 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위해 각 열이 원자적인 값을 가지며 행과 열의 순서가 중요하지 않은 기본적인 정규화 형태이다. - 데이터베이스 정규화 - 단일 진실 공급원
단일 진실 공급원(SSOT)은 데이터 중복을 줄이고 일관성을 유지하여 의사 결정 및 운영 효율성을 향상시키기 위해 특정 정보에 대한 단 하나의 신뢰할 수 있는 출처를 만드는 개념이다. - 데이터베이스 정규화 - 제3정규형
제3 정규형은 관계형 데이터베이스 설계 시 데이터 중복을 줄이고 무결성을 유지하기 위한 정규화 단계로, 제2 정규형을 만족하며 기본 키가 아닌 속성에 대한 전이적 종속성을 제거하는 것을 목표로 한다. - 데이터 모델링 - 빌딩 정보 모델링
빌딩 정보 모델링(BIM)은 건축물의 전 생애주기 동안 발생하는 정보를 디지털 모델로 통합 관리하는 프로세스이다. - 데이터 모델링 - 저장 프로시저
저장 프로시저는 데이터베이스 관리 시스템에서 SQL 문들을 미리 컴파일하여 저장하고, 모듈화, 보안성, 성능 향상, 유지보수 용이성과 같은 특징을 가지며, 데이터베이스 시스템마다 구현 방식과 지원하는 언어가 다를 수 있는 코드 묶음이다.
| 데이터베이스 정규화 |
|---|
2. 정규화의 목적
에드거 F. 커드는 1970년에 제 1 정규형을 정의하면서 데이터베이스 정규화의 목적을 제시했다. 이는 일차 논리에 기반한 "보편적 데이터 부언어"를 통해 데이터를 질의하고 조작할 수 있도록 하는 것이었다.[26] SQL이 이러한 데이터 부언어의 대표적인 예이지만, 에드거 F. 커드는 SQL에 심각한 결함이 있다고 생각했다.[27]
커드는 제1 정규화(1NF)의 목적을 다음과 같이 정의했다.[28]
# 삽입, 갱신, 삭제 시 발생할 수 있는 불필요한 데이터 중복 및 종속성을 제거한다.
# 새로운 자료형이 추가될 때 데이터베이스 구조 변경을 최소화하여 응용 프로그램의 수명을 연장한다.
# 관계형 모델을 사용자에게 더욱 의미있게 만든다.
# 질의 통계 변화에 중립적인 관계 집합을 만든다.
정규화된 데이터베이스 구조는 새로운 데이터 형을 추가할 때 구조 변경을 최소화하거나 아예 변경하지 않아도 되도록 한다. 이는 데이터베이스와 연동된 응용 프로그램에 미치는 영향을 줄여 응용 프로그램의 수명을 연장시킨다.
정규화된 테이블과 이들 간의 관계는 현실 세계의 개념 및 관계를 반영하여 데이터 모델을 사용자에게 더욱 의미있게 만든다. 또한, 정규화된 테이블은 일반적인 질의에 적합하며, 예측되지 않은 질의도 지원할 수 있다. 반면, 정규화되지 않은 테이블은 특정 질의를 지원하지 못할 수 있다.
예를 들어, 온라인 서점에서 고객이 원하는 책 목록을 관리하는 경우를 생각해 보자. "고객이 원하는 책은 무엇인가?"와 같은 질의는 쉽게 처리할 수 있지만, "고객들이 가장 선호하는 책은?", "어떤 고객들이 2차 세계대전에 대한 책에 관심이 있는가?"와 같은 질의는 비정규화된 테이블에서는 처리하기 어렵다. 정규화된 테이블에서는 이러한 질의도 데이터베이스 내에서 쉽게 처리할 수 있다.
고객의 신용카드 사용 내역을 나타내는 비정규화된 테이블과 정규화된 테이블을 비교하면 다음과 같다.
{| class="wikitable"
|+ 비정규화된 테이블과 정규화된 테이블 비교
! 비정규화된 테이블 !! 정규화된 테이블
|-
|
{| class="wikitable"
! 고객 !! 사용내역
|-
|홍길동
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12890 | 2010-10-14 | −87 |
| 12904 | 2010-10-15 | −50 |
|-
|최철수
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12898 | 2010-10-14 | −21 |
|-
|한영미
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12907 | 2010-10-15 | −18 |
| 14920 | 2010-11-20 | −70 |
| 15003 | 2010-11-27 | −60 |
|}
|
| 고객 | 거래번호 | 일자 | 잔고 |
|---|---|---|---|
| 홍길동 | 12890 | 2010-10-14 | −87 |
| 홍길동 | 12904 | 2010-10-15 | −50 |
| 최철수 | 12898 | 2010-10-14 | −21 |
| 한영미 | 12907 | 2010-10-15 | −18 |
| 한영미 | 14920 | 2010-11-20 | −70 |
| 한영미 | 15003 | 2010-11-27 | −60 |
|}
비정규화된 테이블의 경우, 각 고객의 거래 내역이 반복되어 나타난다. 따라서 특정 질의(예: 2010년 10월 거래 총액)를 처리하려면 각 고객의 거래 내역을 추출하고 그룹화하는 복잡한 과정이 필요하다. 하지만 정규화된 테이블에서는 각 행이 하나의 거래를 나타내므로 질의 처리가 훨씬 간단해진다. 예를 들어 DBMS는 2010년 10월에 해당하는 행을 찾아 잔고를 합산하는 간단한 방법으로 질의를 처리할 수 있다.
이처럼 정규화는 데이터 구조를 단순화하고 질의를 효율적으로 처리할 수 있도록 한다.
정규화가 충분히 이루어지지 않은 경우, 데이터를 수정(삽입, 갱신, 삭제)할 때 다음과 같은 부작용이 발생할 수 있다.
- 삽입 이상: 특정 상황에서 새로운 데이터를 삽입할 수 없는 현상. 예를 들어, 교직원과 강좌 관계에서 새로운 교직원을 추가할 때, 담당 강좌가 없으면 강좌 코드를 null로 설정해야만 추가할 수 있다.
- 갱신 이상: 동일한 정보가 여러 행에 중복되어 나타나 데이터 갱신 시 논리적 불일치가 발생할 수 있는 현상. 예를 들어, 직원 기술 관계에서 직원의 주소가 변경되면 여러 레코드를 수정해야 하며, 일부 레코드만 갱신될 경우 데이터 불일치가 발생한다.
- 삭제 이상: 특정 데이터를 삭제하면 다른 데이터까지 함께 삭제되는 현상. 예를 들어, 교직원과 강좌 관계에서 특정 교직원이 담당하는 강좌가 없어지면 해당 교직원 정보까지 삭제될 수 있다.
3. 정규화의 이상 현상
테이블 수정(삽입, 갱신, 삭제) 시, 원치 않던 부작용이 발생할 수 있는데, 이러한 부작용은 충분히 정규화되지 않은 테이블에서 발생할 수 있다.
- 삽입 이상: 특정 사실을 전혀 기록할 수 없는 상황이 발생한다. 예를 들어, "교직원과 강좌" 테이블의 각 레코드는 교직원 ID, 교직원 이름, 교직원 고용일 및 강좌 코드를 포함할 수 있다. 따라서 적어도 하나의 강좌를 가르치는 모든 교직원의 세부 사항은 기록될 수 있지만, 아직 어떤 강좌에도 배정되지 않은 새로 채용된 교직원은 강좌 코드를 null로 설정하는 경우를 제외하고는 기록할 수 없다.
- 갱신 이상: 동일한 정보가 여러 행에 표현될 수 있으므로 테이블 갱신 시 논리적 불일치가 발생할 수 있다. 예를 들어, "직원 기술" 테이블의 각 레코드는 직원 ID, 직원 주소 및 기술을 포함할 수 있다. 따라서 특정 직원의 주소 변경은 여러 레코드(각 기술당 하나씩)에 적용해야 할 수 있다. 갱신이 부분적으로만 성공하는 경우(직원의 주소가 일부 레코드에서는 갱신되지만 다른 레코드에서는 갱신되지 않는 경우), 테이블은 일관성이 없는 상태가 된다. 구체적으로, 이 테이블은 특정 직원의 주소가 무엇인지에 대한 질문에 대해 상충되는 답변을 제공한다.
- 삭제 이상: 특정 상황에서 특정 사실을 나타내는 데이터를 삭제하면 완전히 다른 사실을 나타내는 데이터도 삭제해야 한다. 앞의 예에서 설명한 "교직원과 강좌" 테이블은 이러한 이상 현상을 겪는데, 교직원이 일시적으로 어떤 강좌에도 배정되지 않으면 해당 교직원이 나타나는 마지막 레코드를 삭제해야 하며, 이는 강좌 코드 필드가 null로 설정되지 않는 한 해당 교직원을 효과적으로 삭제하는 것이 된다.
4. 정규형
코드는 1970년에 정규화의 개념과 현재 제1 정규형(1NF)으로 알려진 것을 소개했다.[4] 코드는 1971년에 제2 정규형(2NF)과 제3 정규형(3NF)을 정의했고,[5] 1974년에 레이먼드 F. 보이스(Raymond F. Boyce)와 함께 보이스-코드 정규형(BCNF)을 정의했다.[6]
로널드 페이긴(Ronald Fagin)은 1977년에 제4 정규형(4NF)을, 1979년에 제5 정규형(5NF)을 소개했다. 크리스토퍼 J. 데이트(Christopher J. Date)는 2003년에 제6 정규형(6NF)을 소개했다.
비공식적으로 관계형 데이터베이스 릴레이션은 제3 정규형을 충족하면 "정규화"된 것으로 설명되는 경우가 많다.[7] 대부분의 3NF 릴레이션은 삽입, 수정 및 삭제 이상이 없다.
정규형은 덜 정규화된 것부터 가장 정규화된 것 순으로 다음과 같다.
| 제약 조건 | UNF | 1NF | 2NF | 3NF | EKNF | BCNF | 4NF | ETNF | 5NF | DKNF | 6NF |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 고유한 행(중복 레코드 없음)[4] |  | ||||||||||
| 스칼라 열(열은 관계 또는 복합 값을 포함할 수 없음)[5] | |||||||||||
| 모든 비주요 속성은 각 후보 키에 대한 완전한 함수 종속성을 가진다(속성은 모든 키의 전체에 종속됨)[5] | |||||||||||
| 모든 비자명 함수 종속성은 슈퍼키로 시작하거나 주 속성으로 끝난다(속성은 후보 키에 만 종속됨)[5] | |||||||||||
| 모든 비자명 함수 종속성은 슈퍼키로 시작하거나 기본 주 속성으로 끝난다(3NF의 더 엄격한 형태) | |||||||||||
| 모든 비자명 함수 종속성은 슈퍼키로 시작한다(3NF의 더 엄격한 형태) | |||||||||||
| 모든 비자명 다중 값 종속성은 슈퍼키로 시작한다 | |||||||||||
| 모든 조인 종속성은 슈퍼키 구성 요소를 갖는다[8] | |||||||||||
| 모든 조인 종속성은 슈퍼키 구성 요소만 갖는다 | |||||||||||
| 모든 제약 조건은 도메인 제약 조건 및 키 제약 조건의 결과이다 | |||||||||||
| 모든 조인 종속성은 자명하다 |
데이터베이스 정규화는 더 높은 정규형으로 관계형 데이터베이스 테이블을 설계하는 데 사용되는 데이터베이스 설계 기법이다.[9] 이 과정은 점진적으로 진행되며, 이전 수준이 충족되지 않으면 더 높은 수준의 데이터베이스 정규화를 달성할 수 없다.[10]
즉, 비정규형(가장 덜 정규화된) 데이터를 가지고 가장 높은 수준의 정규화를 목표로 하는 경우, 첫 번째 단계는 제1 정규형 준수를 보장하는 것이고, 두 번째 단계는 제2 정규형이 충족되도록 하는 것이며, 데이터가 제6 정규형을 준수할 때까지 순서대로 진행된다.
그러나 4NF를 넘어서는 정규형은 주로 학문적 관심사이며, 해결하려는 문제가 실제로는 거의 나타나지 않는다.[11]
C.J. 데이트는 5NF의 데이터베이스만이 진정으로 "정규화"되었다고 주장했다.[13]
어떤 정규형이 되기 위해서는, 특정 시점에 관계(표, 테이블) 안에 있는 모든 튜플(행)의 값이 해당 정의에 부합하는 것만으로는 충분하지 않다. 과거 및 미래에 관계 내의 튜플의 증감이 있더라도 정의에서 벗어나지 않도록 속성(열, 컬럼)이 정의되어 있어야 한다.
실제 관계형 데이터베이스 관리 시스템에서는 속성의 도메인에 부합하는 한, 관계 안에 어떤 값으로 구성된 튜플이라도 넣을 수 있다. 그러나 여기서는 "관계에는 각 속성에 대응하는 현실의 사상을 나타내는 튜플로서 시스템 요건상 있을 수 있는 것만 들어간다"는 암묵적인 제약이 가정되어 있다. 다시 말해, 정규형의 정의에서는 각 속성의 값이 속성마다 일정한 의미를 가지고 있다는 것이 가정된다. 이는 정규화가 주어진 특정 요건에 대해 타당한 설계를 이끌어내기 위한 방법이기 때문이다.
지금까지 다양한 정규형이 정의되어 왔지만, 제1~제5 정규형 및 보이스-코드 정규형이 특히 널리 알려져 있다.
이하에서 나중에 제시된 정규형은 그보다 먼저 제시된 정규형의 충분 조건이 된다. 예를 들어, 제3 정규형은 항상 제2 정규형이다. 역사적으로 보면, 먼저 에드거 F. 코드에 의해 제3 정규형까지 정의되었고, 다음으로 제3 정규형의 "수정"으로서 보이스-코드 정규형이 정의된 후, 로널드 페이긴에 의해 제4 정규형 및 제5 정규형이 정의되었다.
이러한 정의에 따른 정규화는 실무에서도 자주 이루어지지만, 제3 정규형까지만 수행하고 일단 충분히 정규화되었다고 생각하는 경우가 많다.
5. 정규화의 실제
정규화된 데이터베이스 구조는 새로운 데이터 유형을 추가할 때, 구조 변경을 최소화하거나 아예 변경하지 않아도 되도록 해준다. 이는 데이터베이스와 연동되는 응용 프로그램에 미치는 영향을 줄여, 응용 프로그램의 수명을 연장시킨다.[9]
정규화된 테이블은 일반적인 목적의 질의에 적합하며, 예측되지 않은 미래의 질의도 지원한다. 반면, 정규화되지 않은 테이블은 특정 질의를 지원하지 못할 수 있다.[10] 예를 들어, 고객이 원하는 책 목록을 가진 온라인 서점의 경우, 정규화되지 않은 테이블은 "고객이 원하는 책은 무엇인가?"와 같은 단순한 질의에는 답할 수 있지만, "가장 인기 있는 책은 무엇인가?" 또는 "특정 주제에 관심 있는 고객은 누구인가?"와 같은 복잡한 질의에는 답하기 어렵다. 이러한 질의에 답하려면 데이터베이스와 별개로 작동하는 소프트웨어가 필요하며, 이 소프트웨어는 비정규화된 항목을 정규화하는 역할을 한다. 그러나 정규화된 테이블에서는 데이터베이스 내에서 이러한 질의에 쉽게 답할 수 있다.
에드거 F. 커드는 데이터 구조의 복잡성이 제거되면 질의가 사용자와 응용 프로그램에 의해 표현되고, 데이터베이스 관리 시스템(DBMS)에 의해 수행될 때 더욱 강력하고 유연해진다고 보았다.
고객들의 신용카드 사용 내역을 나타내는 테이블을 예로 들어보자.
정규화 전{| class="wikitable"
! 고객 !! 사용내역
|-
| 홍길동
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12890 | 2010-10-14 | −87 |
| 12904 | 2010-10-15 | −50 |
|-
| 최철수
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12898 | 2010-10-14 | −21 |
|-
| 한영미
||
| 거래번호 | 일자 | 잔고 |
|---|---|---|
| 12907 | 2010-10-15 | −18 |
| 14920 | 2010-11-20 | −70 |
| 15003 | 2010-11-27 | −60 |
|}
위 테이블은 제1 정규형을 만족하지 않는다. 각 고객마다 거래 내역이 반복되기 때문에, 특정 고객의 거래 내역을 조회하려면 다음과 같은 복잡한 단계를 거쳐야 한다.
1. 각 고객의 거래 내역을 추출하여 그룹화한다.
2. 그룹화된 거래 내역에서 질의 결과를 도출한다.
예를 들어, 2010년 10월에 이루어진 모든 거래의 총액을 구하려면 다음과 같은 과정을 거쳐야 한다.
1. 각 고객으로부터 거래 내역을 추출한다.
2. 추출된 거래 내역 중 일자가 2010년 10월인 거래들의 잔고를 합산한다.
정규화 후
| 고객 | 거래번호 | 일자 | 잔고 |
|---|---|---|---|
| 홍길동 | 12890 | 2010-10-14 | −87 |
| 홍길동 | 12904 | 2010-10-15 | −50 |
| 최철수 | 12898 | 2010-10-14 | −21 |
| 한영미 | 12907 | 2010-10-15 | −18 |
| 한영미 | 14920 | 2010-11-20 | −70 |
| 한영미 | 15003 | 2010-11-27 | −60 |
위와 같이 정규화된 테이블에서는 각 행이 각 거래를 나타내므로, DBMS는 2010년 10월에 해당하는 모든 행을 찾아 잔고를 합산하는 방식으로 질의를 쉽게 처리할 수 있다. 모든 값이 동등한 입장을 가지며 DBMS에 직접 반영되어 질의에 참여할 수 있게 된다.
완전 정규화된 데이터베이스는 기존 구조를 크게 변경하지 않고 새로운 유형의 데이터를 수용하도록 확장할 수 있다. 결과적으로 데이터베이스와 상호 작용하는 애플리케이션은 최소한의 영향을 받는다.
정규화된 관계와 한 정규화된 관계와 다른 관계 간의 관계는 실제 개념과 상호 관계를 반영한다. 데이터베이스 정규화는 더 높은 정규형으로 관계형 데이터베이스 테이블을 설계하는 데 사용되는 기법이다. 이 과정은 점진적으로 진행되며, 이전 수준이 충족되지 않으면 더 높은 수준의 데이터베이스 정규화를 달성할 수 없다.
즉, 비정규형 데이터를 가지고 가장 높은 수준의 정규화를 목표로 하는 경우, 첫 번째 단계는 제1 정규형 준수를 보장하는 것이고, 두 번째 단계는 제2 정규형이 충족되도록 하는 것이며, 데이터가 제6 정규형을 준수할 때까지 위에서 언급한 순서대로 진행된다.
그러나 4NF를 넘어서는 정규형은 주로 학문적 관심사이며, 해결하려는 문제가 실제로는 거의 나타나지 않는다.[11]
6. 비판
데이터베이스 정규화는 데이터의 정확성과 일관성을 높이는 유용한 기술이지만, 몇 가지 비판도 존재한다.
- 성능 저하: 지나치게 복잡한 정규화는 데이터베이스 성능 저하를 유발할 수 있다. 특히, 온라인 트랜잭션 처리(OLTP) 시스템에서는 6NF(여섯 번째 정규형)를 사용하면 단일 엔티티 정보를 얻기 위해 여러 테이블을 조인해야 하므로 성능이 저하될 수 있다.[14]
- 복잡성 증가: 정규화 단계가 높아질수록 데이터베이스 구조가 복잡해져서 이해하고 관리하기 어려워질 수 있다.
- 비정형 데이터 처리의 어려움: NoSQL 데이터베이스와 같이 비정형 데이터를 다루는 경우에는 정규화가 적합하지 않을 수 있다.
하지만, 데이터 웨어하우스 환경에서는 대량의 데이터에 대한 빠른 쿼리 처리가 중요하므로, 컬럼형 데이터 저장소와 같은 내부적인 6NF 표현을 사용하여 성능을 향상시키기도 한다.[15] Sybase IQ와 같은 일부 DBMS는 기본적으로 컬럼형 스토리지를 사용하며, Microsoft SQL Server 2012 이상에서는 "columnstore index"를 지정하여 사용할 수 있다.[15]
또한, 제4 정규형(4NF) 관계가 제5 정규형(5NF)을 만족하지 않는 경우, 데이터의 논리적 일관성을 유지하기 위해 애플리케이션 소프트웨어가 추가적인 부담을 져야 할 수도 있다.
7. 추가 설명: 함수 종속성
어떤 릴레이션 R에서 속성 집합 X의 값이 정해지면 다른 속성 집합 Y의 값이 유일하게 정해지는 관계를 '''함수 종속성'''이라고 하며, X → Y로 표기한다. 예를 들어, "직원" 테이블에 "직원 ID" 속성과 "직원 생일" 속성이 있을 때, {직원 ID}→{직원 생일} 이 성립한다. 즉, {직원 생일}은 {직원 ID}에 함수 종속된다.[4]
- 자명한 함수 종속성: 속성들의 부분집합이 함수 종속성을 가질 때 자명한 함수 종속성이라고 한다. 예를 들어, {직원 ID}→{직원 생일} 이면 {직원 ID, 직원 주소}→{직원 생일} 은 자명하다.
- 완전 함수 종속성: A, B가 각각 관계 R의 속성이고 B가 A에 함수 종속(A→B)일 때, A의 임의의 부분 집합에 대하여 B의 어떤 값도 A의 부분 집합의 값에 대응하지 않으면 B는 A에 완전 함수 종속이라고 한다.
- 이행 함수 종속성: A, B, C가 관계 R에 속하고 A가 B에 함수 종속적이 아니면 C는 A에 이행 함수 종속이라고 한다. A→B 이고 B→C 일 경우에만 A→C 이면 이행 함수 종속이다. 제2 정규형(2NF)에서 이행 함수 종속성을 제거하고 분해한 관계를 제3 정규형(3NF)이라고 한다.
A 및 B를 속성 또는 속성의 집합이라고 할 때, "A가 B에 '''함수 종속'''한다"는 것은, B의 값을 정하면 항상 A의 값이 하나로 정해지는 성질을 A가 갖는 것을 의미하며, 이를 B → A로 쓴다. 화살표의 왼쪽, 즉 여기에서의 B를 '''결정자''', 오른쪽, 즉 여기에서의 A를 '''종속자'''라고 한다. 속성의 집합은 { }로 묶는다. (A → A, {A, B} → A와 같이, 종속자와 결정자가 같거나, 종속자가 결정자에 포함된 속성만으로 구성된 경우를 '''자명한 함수 종속'''이라고 하며, 이하 설명에서는 함수 종속에서 자명한 함수 종속을 제외한다.)
{회원 번호, 회원 이름}이라는 관계의 경우, 회원 번호가 정해지면 회원 이름도 하나로 정해지므로, 회원 이름은 회원 번호에 함수 종속한다. 이 예에서 알 수 있듯이, 함수 종속하기 위해서는 종속자의 값이 단지 하나의 값에 대응하는 것만 필요하며, 종속자의 실제 값을 도출하는 데 결정자의 값만으로는 정보가 부족해도 된다. 즉, 함수 종속이란, 결정자가 종속자의 데이터를 가져오기 위한 "주소"로 사용될 수 있음을 의미한다.
여러 속성으로 구성된 결정자 중 일부 속성에도 함수 종속하는 것을 ''부분 (함수) 종속(성)''이라고 하며, 여러 속성으로 구성된 결정자에 함수 종속하지만 부분 종속은 하지 않는 것을 ''완전 (함수) 종속(성)''이라고 한다. 즉, 결정자에 "불필요한 속성"이 없는 경우가 완전 종속이다.
8. 추가 설명: 다치 종속 및 조인 종속
다치 종속성(MVD)은 어떤 레코드의 존재가 다른 레코드의 존재로 이어짐을 의미한다. 다치 종속은 `->>`으로 표시하는데, R{A,B,C}일 때 (A,C)->>{B}≡(A) ->{B}가 성립한다. A->>B이면 A->>C도 성립하고 A->>B|C이다. 페이긴 정리에 따라 R{A,B,C}에서 다치 종속 A->>B|C이면 R1{A,B}와 R2{A,C}로 무손실 분해가 가능하다. 이를 제4 정규형(4NF)의 관계에 있다고 말한다.
조인 종속(JD)은 릴레이션 R이 그의 프로젝션 A, B, ..., Z의 조인과 동일하면 R은 JD*(A, B, ..., Z)를 만족한다. 이때 A, B, ..., Z는 R의 애트리뷰트에 대한 부분집합이다. 다시 말해서 테이블 R이 R의 속성의 부분집합을 가지는 여러 개의 테이블들을 조인하여 만들어질 수 있을 때, R은 조인 종속성을 가진다고 한다. 이를 제5 정규형(5NF)이라고 한다.
9. 참고: 용어
; '''함수 종속성''' : 관계 스키마에서 어떤 속성군의 값이 정해지면 다른 속성군의 값이 정해지는 것을 의미한다. A, B가 관계 R의 속성일 때, A의 값에 따라 B의 값이 하나로 정해지면 B는 A에 함수 종속이라고 하며, A→B로 표기한다. 예를 들어, "직원" 테이블에서 "직원 ID"가 "직원 생일"을 결정하면, {직원 ID}->{직원 생일}이다.
; '''자명한 함수 종속성''' : 속성들의 부분집합이 함수 종속성을 가질 때, 이를 자명한 함수 종속성이라 한다. 예를 들어, {직원 ID}->{직원 생일}이면 {직원 ID, 직원 주소}->{직원 생일}은 자명하다.
; '''완전함수 종속성''' : A, B가 관계 R의 속성이고 B가 A에 함수 종속(A→B)일 때, A의 부분 집합에 대해 B의 어떤 값도 A의 부분 집합의 값에 대응하지 않으면 B는 A에 완전함수(적) 종속이라고 한다.
; '''이행함수 종속성''' : A, B, C가 관계 R에 상호 중복되지 않는 속성(A는 1차 키 이외의 속성)이고, A가 B에 함수 종속적이 아니면 C는 A에 이행함수 종속이라고 한다. A->B이고 B->C일 때 A->C이면 이행함수(적) 종속이다.
; '''다치 종속성''' : 어떤 레코드의 존재가 다른 레코드의 존재로 이어짐을 의미한다. MVD는 ->>으로 표시하며, R｛A,B,C｝에서 (A,C)->>｛B｝≡(A) ->｛B｝가 성립한다. A->>B이면 A->>C도 성립하고 A->>B│C이다.
; '''조인 종속''' : 릴레이션 R이 그의 프로젝션 A,B,.....,Z의 조인과 동일하면 R은 JD*(A,B,....,Z)를 만족한다. 이때 A,B,....,Z는 R의 애트리뷰트에 대한 부분집합이다. 즉, 테이블 R이 R의 속성의 부분집합을 가지는 여러 테이블들을 조인하여 만들어질 수 있을 때, R은 조인 종속성을 가진다.
; '''슈퍼 키''' : 레코드를 유일하게 식별할 수 있는 속성들의 집합이다. 한 테이블은 여러 개의 슈퍼키를 가질 수 있다.
; '''후보 키''' : 슈퍼 키에서 레코드를 유일하게 식별하는데 필요없는 속성을 제거한 부분집합이다. 예를 들어, {이름},{나이},{주민등록 번호},{전화번호} 속성을 가진 테이블에서 슈퍼키는 {주민등록 번호}, {전화번호, 이름}, {주민등록 번호, 이름} 3개이며, 이 중 {주민등록 번호}가 후보 키이다.
; '''비일차 속성''' : 어떤 후보 키에도 나타나지 않는 속성이다. {이름},{나이},{주민등록 번호},{전화번호} 속성을 가지는 테이블에서 {나이}는 비일차 속성이다.
; '''일차키''' : 관계 데이터베이스(RDB)에서 관계(데이터베이스 테이블) 내의 특정 투플(열)을 일의적으로 식별할 수 있는 키 필드이다. 주 키(major key)라고도 한다.
참조
[1]
웹사이트
A Relational Model of Data for Large Shared Data Banks
https://dl.acm.org/d[...]
2007-06-12
[2]
서적
The Relational Model for Database Management: Version 2
Addison-Wesley
1990
[3]
문서
Further Normalisation of the Data Base Relational Model
[4]
간행물
A Relational Model of Data for Large Shared Data Banks
1970-06
[5]
문서
Further Normalization of the Data Base Relational Model
IBM Research Report RJ909
1971-08-31
[6]
문서
Recent Investigations into Relational Data Base Systems
IBM Research Report RJ1385
1974-04-23
[7]
서적
An Introduction to Database Systems
Addison-Wesley
[8]
학회자료
A Normal Form for Preventing Redundant Tuples in Relational Databases
https://researcher.w[...]
Association for Computing Machinery
2018-05-22
[9]
서적
2017 4th IEEE Uttar Pradesh Section International Conference on Electrical, Computer and Electronics (UPCON)
IEEE
2017-10
[10]
웹사이트
Database normalization in MySQL: Four quick and easy steps
https://www.computer[...]
2021-03-23
[11]
웹사이트
Database Normalization: 5th Normal Form and Beyond
https://mariadb.com/[...]
2019-01-23
[12]
서적
The New Relational Database Dictionary: Terms, Concepts, and Examples
https://books.google[...]
"O'Reilly Media, Inc."
2015-12-21
[13]
서적
The New Relational Database Dictionary: Terms, Concepts, and Examples
https://books.google[...]
"O'Reilly Media, Inc."
2015-12-21
[14]
웹사이트
normalization - Would like to Understand 6NF with an Example
https://stackoverflo[...]
2019-01-23
[15]
웹사이트
Columnstore Indexes: Overview
https://docs.microso[...]
Microsoft Corporation
2020-03-23
[16]
서적
クリス・デイト
[17]
서적
[18]
서적
[19]
저널
A Relational Model of Data for Large Shared Data Banks
http://www.acm.org/c[...]
2007-06-12
[20]
문서
Further Normalization of the Data Base Relational Model
IBM Research Report RJ909
1971-08-31
[21]
문서
Recent Investigations into Relational Data Base Systems
IBM Research Report RJ1385
1974-04-23
[22]
서적
Temporal Data and the Relational Model
Morgan Kaufmann
2002
[23]
서적
An Introduction to Database Systems
Addison-Wesley
1999
[24]
서적
Database in Depth: Relational Theory for Practitioners
O'Reilly
2005
[25]
서적
The Data Warehouse Toolkit, 2nd Ed.
Wiley Computer Publishing
2002
[26]
웹사이트
A Relational Model of Data for Large Shared Data Banks
http://www.acm.org/c[...]
2007-06-12
[27]
서적
The Relational Model for Database Management: Version 2
Addison-Wesley
1990
[28]
문서
Further Normalization of the Data Base Relational Model
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com