[Database] 정규화 방법 정리 (1NF, 2NF, 3NF, BCNF, 4NF, 5NF)

정규화 방법 정리 (1NF, 2NF, 3NF, BCNF, 4NF, 5NF)

들어가며

• 데이터베이스의 정규화 방법을 정리해본다.

 

용어 정리

• 속성(Attribute) : 테이블의 컬럼(Column)
• 키(Key) : 한 행(Row)을 고유하게 식별할 수 있는 속성 (또는 속성들의 집합)
• 기본키(Primary Key) : 테이블을 대표하는 유일한 키
• 후보키(Candidate Key) : 기본키가 될 수 있는 모든 키
  
  • 기본키는 후보키 중에서 선택한 하나의 키이다.
  • 후보키는 슈퍼키 중에서 최소성을 만족하는 키이다.
• 슈퍼키(Super Key) : 유일성은 만족하지만 최소성은 만족하지 않을 수 있는 키
  
  • 유일성(Uniqueness)
    • 특정 속성(또는 속성들의 조합)이 중복되지 않고 고유한 값을 가져야 하는 성질
    • 유일성을 보장하기 위해 기본키(Primary Key)나 유니크키(Unique Key) 제약 조건을 사용한다.
    • 예) <학생> 테이블에서 학번(student_id)이 유일한 값을 가지도록 설정하면, 같은 학번을 가진 2명의 학생이 존재할 수 없다.
  • 최소성(Minimality)
    • 후보키(Candidate Key)에서 필요한 최소한의 속성만 포함해야 한다.
    • 유일성을 만족시키면서도 불필요한 속성을 포함하지 않아야 한다.
    • 예)
      • <학생> 테이블에서 {학번}과 {이름, 이메일}이 모두 유일성을 만족한다고 가정해보자.
      • {이름, 이메일}은 불필요하게 2개의 속성을 포함하므로 최소성이 없다.
      • {학번}은 유일성을 만족하면서도 최소한의 속성만 포함하므로 후보키로 적절하다.
• 함수적 종속(Functional Dependency)
  • 어떤 속성 A가 있으면, A에 의해 B가 유일하게 결정(결정자 → 종속자) 될 수 있는 관계
  • 예) 학번 → 이름
    • 학번이 같으면 이름이 동일하게 결정된다.
• 부분 종속(Partial Dependency) 
  • 복합키(2개 이상의 속성으로 이루어진 키)에서, 기본키(Primary Key)의 일부 속성에만 종속되는 속성이 존재하는 경우
• 이행적 종속(Transitive Dependency)
  • 기본키가 아닌 다른 컬럼을 통해 또 다른 컬럼이 결정되는 경우
  • 예) 학번 → 전공, 전공 → 학과사무실 ⇒ 학번 → 학과사무실

 

1차 정규형(1NF, First Norm Form)

개념

• 모든 컬럼(속성)의 값이 원자적(Atomic)이고, 각 행이 고유해야 하는 상태
• 하나의 칸(셀)에는 하나의 값만 저장되어야 하고, 중복된 행이 없어야 한다.

 

조건

• 컬럼(속성)의 값이 원자적(Atomic)이어야 한다.
  
  • 한 칸에 여러 개의 값이 들어가면 안 된다.
  • 리스트, 배열처럼 여러 개의 값이 들어간 경우 분리해야 한다.
• 각 행이 유일해야 한다.
  
  • 중복된 행(레코드)이 존재하면 안 된다.
  • 기본키(Primary Key)를 설정하여 각 행을 고유하게 식별해야 한다.

 

예제 테이블

			
			
			
		
+----------+------------+----------------+
| 주문번호   | 고객명      | 상품목록         |
+----------+------------+----------------+
| 1001     | 김철수      | TV, 세탁기       |
| 1002     | 이영희      | 냉장고           |
| 1003     | 박민준      | 노트북, 키보드    |
+----------+------------+----------------+

 

적용 이유

• 데이터 중복을 방지할 수 있다.
  • 한 칸에 여러 개의 값이 들어가 있으면, 검색/수정할 때 일일이 문자열을 분석해야 한다.
  • 1NF를 적용하면 각 값이 개별 행으로 분리되므로 중복을 줄이고 검색이 쉬워진다.
• 데이터의 수정 이상(Modification Anomaly) 문제를 방지할 수 있다.
  • 예) 1001번 주문에서 세탁기를 삭제해야 하는 경우, 상품목록에서 "세탁기" 문자열을 찾아 지워야 한다.
  • 1NF를 적용하면 단순하게 해당 행을 삭제하면 끝난다. (간단하고 오류 발생 확률이 낮아진다.)
• 데이터 검색 작업을 최적화할 수 있다.
  
  • 예) "노트북을 구매한 고객"을 찾는 경우
    
    • 1NF를 적용하지 않으면 상품목록을 문자열로 검색해야 한다.
    • 1NF를 적용하면 SQL에서 WHERE 상품명 = '노트북' 조건으로 쉽게 검색 가능하다.

 

예시

잘못된 예

			
			
			
		
+----------+------------+----------------+
| 주문번호   | 고객명      | 상품목록         |
+----------+------------+----------------+
| 1001     | 김철수      | TV, 세탁기       |
| 1002     | 이영희      | 냉장고           |
| 1003     | 박민준      | 노트북, 키보드    |
+----------+------------+----------------+

 

⇒ 상품목록 컬럼에 여러 개의 상품이 쉼표(,)로 구분되어 저장되어 있어 원자적이지 않다.

⇒ 하나의 칸(셀)에 여러 개의 값이 들어가 있으면 데이터 수정, 검색, 삭제가 어렵다.

 

올바른 예

• 테이블을 쪼개거나, 여러 값을 각각 따로 저장할 수 있는 구조로 변경한다.

			
			
			
		
+----------+------------+----------+
| 주문번호   | 고객명      | 상품명    |
+----------+------------+----------+
| 1001     | 김철수      | TV       |
| 1001     | 김철수      | 세탁기     |
| 1002     | 이영희      | 냉장고     |
| 1003     | 박민준      | 노트북     |
| 1003     | 박민준      | 키보드     |
+----------+------------+----------+

 

⇒ 상품목록을 개별 상품 단위로 분리하여 각 행이 하나의 상품만 포함하도록 변환하였다.

⇒ 이제 특정 상품을 검색하거나 수정할 때 더 쉽게 관리할 수 있다.

 

2차 정규형(2NF, Second Norm Form)

개념

• 제1정규형(1NF)를 만족하면서 테이블에 복합키(기본키가 여러 컬럼으로 이루어진 경우)가 있을 때 부분 종속(Partial Dependency)을 없애는 것
• 기본키의 일부에만 종속되는 속성(Non-prime Attribute)이 없어야 한다.
  • 키가 아닌 속성들은 완전히(Fully) 기본키 또는 복합키에 종속되어야 한다.
• 만약 테이블의 기본키가 하나의 컬럼이라면, 부분 종속이 일어날 여지가 없기 때문에 2NF는 자동으로 만족된다고 본다.
• 부분 종속이 존재하면 데이터가 중복 저장될 가능성이 커져 저장 공간 낭비 뿐만 아니라 데이터 수정 시에도 문제를 일으킬 수 있다.

 

조건

• 모든 컬럼의 값이 원자적(Atomic)이어야 하고, 중복된 행이 없어야 한다. (1NF)
• 부분 종속(Partial Dependency)을 제거해야 한다.
  • 기본키가 복합키(Composite Key)일 때, 기본키의 일부에만 종속되는 속성(Non-prime Attribute)이 없어야 한다.
  • 기본키의 일부분에만 의존하는 컬럼을 다른 테이블로 분리해야 한다.

 

예제 테이블

			
			
			
		
+------------+-----------+---------+------------------+--------+
| 학번 (ID)   | 과목코드    |  이름    | 과목명           | 성적     |
+------------+-----------+---------+------------------+--------+
| 2023001    | CS101     | 김철수   | 컴퓨터공학개론      | A      |
| 2023001    | MA102     | 김철수   | 미적분학           | B      |
| 2023002    | CS101     | 이영희   | 컴퓨터공학개론      | A+     |
+------------+-----------+---------+------------------+--------+

 

적용 이유

• 데이터 중복을 방지할 수 있다.
  • 부분 종속이 존재하면 데이터가 중복 저장될 가능성이 커진다.
  • 따라서 저장 공간 낭비뿐만 아니라 데이터 수정 시에도 문제를 일으킬 수 있다.
• 데이터의 수정 이상(Modification Anomaly) 문제를 방지할 수 있다.
  • 부분 종속이 있는 경우 데이터 수정 시 비효율적인 문제가 발생할 수 있다.
  • 예) 기존 테이블(<Student_Grades>)에서 "김철수"의 이름을 "김민수"로 변경할 경우
    • 같은 학번을 가진 모든 행에서 이름을 일일이 변경해야 한다.
      • 만약 하나라도 빠뜨리면 데이터 불일치(Inconsistency) 문제가 발생한다.
    • 2NF를 적용하면 <Student> 테이블에서 한 번만 변경하면 된다.
• 데이터 삭제 이상(Deletion Anomaly) 문제를 방지할 수 있다.
  • 부분 종속이 존재하는 경우, 특정 데이터를 삭제할 때 원하지 않는 데이터까지 같이 삭제될 수 있다.
  • 예) 학번: 2023002인 학생이 모든 과목을 취소할 경우
    • <Student_Grades> 테이블에서 해당 학번을 가진 모든 행이 삭제된다.
    • 그러면 학생 정보(이름)도 함께 사라진다.
    •  2NF를 적용하면 <Student> 테이블과 분리되어 있어, 과목 정보만 삭제 할 수 있다.
• 데이터 삽입 이상(Insertion Anomaly) 문제를 방지할 수 있다.
  • 부분 종속이 있으면 데이터를 추가할 때 불필요한 데이터까지 같이 입력해야 하는 문제가 발생할 수 있다.
  • 예) 새로운 학생을 추가하려는 경우, 아직 수강 신청을 하지 않은 학생을 추가할 수 없다.
    
    • <Student_Grades> 테이블에 데이터를 추가해야 하는데, 과목코드도 같이 입력해야만 추가할 수 있다.
    • 즉, 수강 신청을 하지 않으면 학생 정보를 넣을 수 없다.
    • 2NF를 적용하면 <Student> 테이블에서 학번과 이름만 추가할 수 있다.

 

예시

잘못된 예

Student_Grades 테이블

			
			
			
		
+------------+-----------+---------+------------------+--------+
| 학번 (ID)   | 과목코드    |  이름    | 과목명           | 성적    |
+------------+-----------+---------+------------------+--------+
| 2023001    | CS101     | 김철수   | 컴퓨터공학개론      | A      |
| 2023001    | MA102     | 김철수   | 미적분학           | B      |
| 2023002    | CS101     | 이영희   | 컴퓨터공학개론      | A+     |
+------------+-----------+---------+------------------+--------+

 

⇒ 이름은 학번에 종속되므로 기본키((학번, 과목코드))의 일부(학번)에만 종속된다. → 부분 종속 발생
⇒ 과목명도 과목코드에 종속되므로 기본키((학번, 과목코드))의 일부(과목코드)에만 종속된다. → 부분 종속 발생
⇒ 따라서, 같은 학생의 이름이 여러 번 반복되고 같은 과목명이 여러 번 반복된다. → 데이터 중복 발생

 

올바른 예

• 테이블을 분리하여 2NF를 적용시킬 수 있다.

 

Student 테이블

			
			
			
		
+------------+---------+
| 학번 (ID)   | 이름    |
+------------+---------+
| 2023001    | 김철수  |
| 2023002    | 이영희  |
+------------+---------+

 

Subject 테이블

			
			
			
		
+-----------+------------------+
| 과목코드    | 과목명           |
+-----------+------------------+
| CS101     | 컴퓨터공학개론     |
| MA102     | 미적분학          |
+-----------+------------------+

 

Student_Grades 테이블

			
			
			
		
+------------+-----------+--------+
| 학번 (ID)   | 과목코드    | 성적   |
+------------+-----------+--------+
| 2023001    | CS101     | A      |
| 2023001    | MA102     | B      |
| 2023002    | CS101     | A+     |
+------------+-----------+--------+

 

⇒ 학생 이름과 과목명이 각각 기본키의 일부 속성(학번, 과목코드)에만 종속되는 문제(부분 종속)가 해결되었다.

 

3차 정규형(3NF, Third Norm Form)

개념

• 제2정규형(2NF)을 만족하면서, 이행적 종속(Transitive Dependency)을 제거한 상태
• 기본키(Primary Key)에만 의존하도록 모든 컬럼을 정리하는 과정

 

조건

• 부분 종속(Partial Dependency)이 없어야 한다. (2NF)
  • 기본키의 일부에만 의존하는 컬럼이 없어야 한다.
• 이행적 종속(Transitive Dependency)이 없어야 한다.
  
  • 기본키가 아닌 속성이 다른 일반 속성을 결정하는 관계가 있으면 안 된다.
  • 모든 속성이 오직 기본키에만 의존해야 한다.

 

예제 테이블

			
			
			
		
+--------+--------+----------+--------------+
| 학번    | 이름    | 학과번호   | 학과명         |
+--------+--------+----------+--------------+
| 1001   | 김철수  | 10       | 컴퓨터공학과    |
| 1002   | 이영희  | 20       | 전자공학과      |
| 1003   | 박민준  | 10       | 컴퓨터공학과    |
+--------+--------+----------+--------------+

 

적용 이유

• 데이터 무결성(정확성)을 보장할 수 있다.
  
  • 예) 학과명을 수정할 때, 한곳만 수정하면 된다.
    • 기존 테이블에서는 학과명이 여러 행에 중복되어 있어 일괄 수정해야 하는 문제가 발생한다.
    • 3NF 적용 후에는 <Department> 테이블에서 한 번만 변경하면 된다.
• 데이터 중복을 최소화할 수 있다.
  
  • 예) 학과명이 여러 번 저장되는 것이 아니라, 한 곳(<Department> 테이블)에서만 관리된다.
    
    • 불필요한 데이터의 저장을 방지하고, 데이터베이스의 사용량을 절약할 수 있다.
• 데이터 수정 이상(Anomaly) 문제를 방지할 수 있다.
  • 예) 3NF를 적용하지 않으면, 학과명을 변경할 때 관련된 모든 레코드를 수정해야 한다.
    
    • 3NF 적용 후에는 <Department> 테이블에서 한 번만 수정하면 된다.

 

예시

잘못된 예

			
			
			
		
+--------+--------+----------+--------------+
| 학번    | 이름    | 학과번호   | 학과명         |
+--------+--------+----------+--------------+
| 1001   | 김철수  | 10       | 컴퓨터공학과    |
| 1002   | 이영희  | 20       | 전자공학과      |
| 1003   | 박민준  | 10       | 컴퓨터공학과    |
+--------+--------+----------+--------------+

 

⇒ 학과명은 학과번호에 의해 결정된다. (학과번호 → 학과명)
⇒ 학번이 학과번호를 결정하고, 학과번호가 학과명을 결정함 → 이행적 종속 발생 (학번 → 학과번호 → 학과명)

 

올바른 예

• 테이블을 분리하여 3NF를 적용시킬 수 있다.
  • 학과번호와 학과명의 이행적 종속을 제거하고, 학과 정보를 별도 테이블로 분리한다.

 

Student 테이블

			
			
			
		
+--------+--------+----------+
| 학번    | 이름    | 학과번호   |
+--------+--------+----------+
| 1001   | 김철수  | 10        |
| 1002   | 이영희  | 20        |
| 1003   | 박민준  | 10        |
+--------+--------+----------+

 

⇒ <Student> 테이블에서는 오직 기본키인 학번만을 이용하여 데이터를 관리한다.

 

Department 테이블 (분리된 테이블)

			
			
			
		
+----------+--------------+
| 학과번호   | 학과명        |
+----------+--------------+
| 10       | 컴퓨터공학과    |
| 20       | 전자공학과     |
+----------+--------------+

 

⇒ <Department> 테이블을 통해 학과번호를 기준으로 학과명을 관리한다.

 

BCNF(Boyce-Codd Normal Form)

개념

• 3차 정규형(3NF)을 강화한 정규형으로, 모든 결정자(Determinant)가 후보키여야 한다는 조건을 만족하는 정규형
  • 결정자(Determinant)
    • 어떤 속성의 값을 알면 다른 속성의 값을 유일하게 결정할 수 있는 속성
    • 예) 학생ID가 이름을 결정한다면 학생ID는 이름의 결정자이다.
  • 후보키가 아닌 속성이 결정자인 경우가 존재하면 BCNF를 만족하지 않는다.
• 모든 함수 종속 관계에 대해 기본키만이 결정자 역할을 해야 한다는 매우 강력한 조건이 요구된다.

 

조건

• 모든 컬럼의 값이 원자적(Atomic)이어야 하고, 중복된 행이 없어야 한다. (1NF)
• 부분 종속(Partial Dependency)을 제거한 상태여야 한다. (2NF)
• 모든 결정자(Determinant)는 후보키(Candidate Key)이어야 한다.
  
  • 결정자가 후보키가 아닌 경우, BCNF를 만족하지 않는다.
  • 이 조건에 의해 이행적 종속 문제(Transitive Dependency)도 자연스럽게 해결된다.

 

예제 테이블

			
			
			
		
+--------+----------+------------+----------+
| 학번    | 과목ID    | 교수명     | 교수연락처  |
+--------+----------+------------+----------+
| 1001   | MATH101  | 김철수     | 010-1234  |
| 1002   | CS102    | 이영희     | 010-5678  |
| 1001   | CS102    | 이영희     | 010-5678  |
+--------+----------+------------+----------+

 

적용 이유

• 데이터 무결성(정확성)을 강화할 수 있다.
  
  • BCNF는 모든 결정자가 후보키여야 하므로, 테이블 내에 불필요한 중복이나 잘못된 관계를 제거할 수 있다.
• 데이터 중복을 최소화할 수 있다.
  
  • BCNF를 적용하면 중복된 데이터를 더 쉽게 제거할 수 있고, 불필요한 데이터의 중복을 방지할 수 있다.
• 데이터 수정 이상(Anomaly) 문제를 방지할 수 있다.
  • BCNF는 모든 속성이 기본키에 의존하도록 하여, 데이터의 삽입, 삭제, 갱신 시 발생할 수 있는 수정 이상 문제를 방지해준다.

 

예시

잘못된 예

			
			
			
		
+--------+----------+------------+----------+
| 학번    | 과목ID    | 교수명     | 교수연락처  |
+--------+----------+------------+----------+
| 1001   | MATH101  | 김철수     | 010-1234  |
| 1002   | CS102    | 이영희     | 010-5678  |
| 1001   | CS102    | 이영희     | 010-5678  |
+--------+----------+------------+----------+

 

⇒ 과목ID가 교수명을 결정하는데, 과목ID는 기본키가 아닌 속성이다.
⇒ 과목ID가 교수명을 결정한다면, 과목ID가 결정자(Determinant)가 되지만 후보키가 아니므로 BCNF를 만족하지 않는다.

 

올바른 예

• 결정자가 후보키가 되도록 테이블을 분리하여 BCNF를 적용시킬 수 있다.

 

Enrollment 테이블

			
			
			
		
+--------+----------+-----------+
| 학번    | 과목ID    | 학점      |
+--------+----------+-----------+
| 1001   | MATH101  | A         |
| 1002   | CS102    | B         |
| 1001   | CS102    | A         |
+--------+----------+-----------+

 

Professor 테이블

			
			
			
		
+----------+------------+----------+
| 과목ID    | 교수명      | 교수연락처 |
+----------+------------+----------+
| MATH101  | 김철수      | 010-1234 |
| CS102    | 이영희      | 010-5678 |
+----------+------------+----------+

 

⇒ 과목ID가 교수명을 결정하는 관계를 <Professor> 테이블로 분리하여 과목ID가 후보키로 유지되도록 한다.

⇒ 이제 과목ID는 <Enrollment> 테이블에서만 관리되고, <Professor> 테이블에서는 과목ID가 기본키로서 교수명을 결정하므로 BCNF를 만족시킨다.

 

4차 정규형(4NF, Fourth Norm Form)

개념

• 다중값 종속(Multi-valued Dependency)을 제거하는 정규형
  • 다중값 종속 (Multi-valued Dependency)
    • 하나의 속성이 여러 개의 값을 가질 수 있는 경우
    • 하나의 속성이 다른 두 속성에 독립적으로 여러 값을 결정할 수 있을 때 발생한다.
• 하나의 속성이 독립적으로 여러 값을 가질 수 있는 관계를 분리한다.

 

예시

잘못된 예

			
			
			
		
+--------+----------+---------+-----------+
| 학생ID  | 과목      | 전화번호  | 취미      |
+--------+----------+---------+-----------+
| 1001   | 수학      | 010-1234 | 독서      |
| 1001   | 물리      | 010-1234 | 운동      |
| 1001   | 화학      | 010-1234 | 음악      |
| 1002   | 수학      | 010-5678 | 영화      |
| 1002   | 물리      | 010-5678 | 독서      |
+--------+----------+----------+-----------+

 

⇒ 학생ID가 과목, 전화번호, 취미를 결정하는데, 전화번호와 취미는 독립적이다.

⇒ 즉, 한 학생이 여러 과목을 수강한다고 해서 그 학생의 전화번호나 취미가 영향을 받지 않는다. → 다중값 종속 발생

 

올바른 예

• 학생ID가 과목을 결정하고, 학생ID가 전화번호와 취미를 독립적으로 결정하는 구조이므로, 이를 2개의 테이블로 분리한다.

테이블 1

			
			
			
		
+--------+----------+
| 학생ID  | 과목     |
+--------+----------+
| 1001   | 수학     |
| 1001   | 물리     |
| 1001   | 화학     |
| 1002   | 수학     |
| 1002   | 물리     |
+--------+----------+

 

테이블 2

			
			
			
		
+--------+---------+------+
| 학생ID  | 전화번호  | 취미 |
+--------+---------+------+
| 1001   | 010-1234 | 독서 |
| 1001   | 010-1234 | 운동 |
| 1001   | 010-1234 | 음악 |
| 1002   | 010-5678 | 영화 |
| 1002   | 010-5678 | 독서 |
+--------+---------+------+

 

 

5차 정규형(5NF, Fourth Norm Form, PJ/NF)

개념

• 조인 종속(Join Dependency)을 제거하는 정규형
  • 조인 종속 (Join Dependency)
    
    • 여러 테이블을 조인할 때, 그 조인이 필수적이지 않거나 불필요한 중복 데이터를 만들 수 있는 경우에 발생
• 모든 테이블이 최소한의 정보를 가질 수 있도록 분리한다.
  • 테이블을 나누고, 모든 정보를 조인하여 원래 데이터를 복원할 수 있도록 해야한다.
    • 테이블을 더 쪼갰다가(Projection) 다시 조인(Join)했을 때 정보가 제대로 복원되지 않으면 안 된다.
• 불필요한 중복을 방지하고 필요한 정보를 각 테이블에 적절하게 나누어 저장한다.
• 모든 조인 종속(Join Dependency)은 후보키에서만 유도되어야 하며, 이를 만족하지 않을 경우 5NF를 만족시키지 않는다.
• PJNF(Project-Join Normal Form)라고도 한다.

 

예시

잘못된 예

			
			
			
		
+--------+--------+---------+----------+
| 학생ID  | 과목    | 교수명   | 학점      |
+--------+----------+---------+--------+
| 1001   | 수학    | 김철수   | A        |
| 1001   | 물리    | 이영희   | B        |
| 1002   | 화학    | 김철수   | C        |
| 1002   | 물리    | 이영희   | B        |
+--------+--------+---------+----------+

 

⇒ 학생ID, 과목, 교수명, 학점이 모두 연결되어 있지만, 실제로 학생ID, 과목, 교수명, 학점을 모두 하나의 테이블에 묶을 필요는 없다. → 조인 종속 발생

 

올바른 예

• 각 속성들을 별개의 테이블로 나누고, 필요에 따라 조인하여 원래의 정보를 얻을 수 있게 한다.

 

테이블 1

			
			
			
		
+--------+----------+
| 학생ID  | 과목     |
+--------+----------+
| 1001   | 수학     |
| 1001   | 물리     |
| 1002   | 화학     |
| 1002   | 물리     |
+--------+----------+

 

테이블 2

			
			
			
		
+----------+---------+
| 과목      | 교수명   |
+----------+---------+
| 수학      | 김철수   |
| 물리      | 이영희   |
| 화학      | 김철수   |
+----------+---------+

 

테이블 3

			
			
			
		
+--------+----------+------+
| 학생ID  | 과목     | 학점   |
+--------+----------+------+
| 1001   | 수학     | A     |
| 1001   | 물리     | B     |
| 1002   | 화학     | C     |
| 1002   | 물리     | B     |
+--------+----------+------+

 

4NF, 5NF는 다중 값 종속(Multi-valued Dependency), 조인 종속(Join Dependency) 등 고급 종속성을 다루기 때문에 실제 현업에서 이 단계까지 엄격히 구분해 설계하는 경우는 드물다. 하지만, 복잡한 N:N:N 관계나 조인 종속 문제가 우려되는 대규모 시스템에서는 4NF, 5NF까지 고려하기도 한다. 

 

정리

정규형	전제	정의	목적
1차 정규형(1NF)	-	모든 컬럼(속성)은 원자값(Atomic value)만 가져야 한다.	- 컬럼에 여러 값이 들어가지 않도록 테이블 구조 분할 - 중복·반복을 막고 검색, 수정 용이성 확보
2차 정규형(2NF)	- 1NF 만족 - 테이블에 복합키(Composite Key)가 존재하는 경우	- 1NF 만족 - 부분 종속(Partial Dependency) 제거	복합키가 있는 테이블에서 각 속성이 기본키 전체에 완전 종속되도록 테이블 구조 분할
3차 정규형(3NF)	2NF 만족	- 2NF 만족 - 이행적 종속(Transitive Dependency) 제거 (A→B→C)	기본키가 아닌 컬럼들은 직접적으로 기본키에만 종속되도록 하여 이상 현상 방지
BCNF	3NF 만족	- 3NF 만족 - 모든 결정자(Determinant)는 후보키(Candidate Key)여야 함.	3NF에서 해결되지 않을 수 있는 복잡한 이상 현상(Anomalies)과 종속성 문제까지 제거
4차 정규형(4NF)	3NF(또는 BCNF) 만족	- 3NF(또는 BCNF) 만족 - 다중 값 종속(Multi-valued Dependency) 제거	다중 값 종속에 의해 불필요하거나 잘못된 정보(조합)가 생기지 않도록 테이블 분리
5차 정규형(5NF)	4NF 만족	조인 종속(Join Dependency) 제거 (테이블을 여러 조각으로 분해했다가 다시 조인하더라도 정보 손실 없이 정확히 재구성되도록 함.)	복잡한 N:N:N 관계(프로젝트-직원-역할 등)에서 발생할 수 있는 조인 종속 문제까지 제거

 

 

참고 사이트

Database normalization - Wikipedia

Normal Forms in DBMS - GeeksforGeeks

Database Normalization – Normal Forms 1nf 2nf 3nf Table Examples