[DB] 정규화

데이터베이스 정규화(normalization)란?

데이터를 연관성이 있는 속성들로만 구성되도록 분해해서, 삽입, 삭제, 갱신 이상 현상이 발생하지 않는 올바른 릴레이션(table)으로 만들어 나가는 과정

 

=> 데이터 중복을 줄이고 데이터 무결성 개선 가능

 

정규화 종류

각 정규형마다 만족시켜야 하는 제약조건이 존재하며, 정규형의 차수가 높아질수록 제약조건이 엄격해진다.

그렇지만 대부분은 BCNF정규형까지 만족시키면 이상 현상이 없어지기 때문에 그 이상 분리하지는 않는다고 한다.

이미지 출처: https://terms.naver.com/entry.naver?docId=3431248&cid=58430&categoryId=58430&expCategoryId=58430

 

제1 정규형 (1NF)

  • 릴레이션에 속한 모든 속성의 도메인이 더는 분해되지 않는 원자 값(atomic value)으로만 구성되어 있음
    => 속성이 다중값을 가지면 안됨

제2 정규형 (2NF)

  • 릴레이션이 제1정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속
    => 기본키의 부분집합이 결정자가 되어선 안됨

제3 정규형 (3NF)

  • 릴레이션이 제2정규형에 속하고, 모든 속성이 기본키에 이행적 함수종속이 되지 않음
    • 이행적 함수 종속 관계란?
      세 개의 X, Y, Z 속성 집합으로 구성된 릴레이션에 X → Y와 Y → Z라는 함수 종속 관계와,
      이로 인해 생겨난 X → Z라는 함수 종속 관계
      => X와 Y 속성 집합의 릴레이션과 Y와 Z 속성 집합의 릴레이션으로 분해하여 이행적 함수 종속 관계 제거

보이스/코드 정규형 (BCNF_Boyce/Codd Normal Form)

  • 릴레이션이 제3정규형에 속하고, 함수 종속 관계에서 모든 결정자가 후보자임
    • 후보키란? 유일성과 최소성을 만족하는 속성(또는 속성의 조합) -> 테이블 내의 모든 행을 고유하게 식별 가능
  • BCNF 적용 전 테이블
    • 후보키: 강의ID (각 강의가 유일함)
    • 함수 종속성
      • 강의ID -> 교수 ID
      • 교수 ID -> 강의실
  • 문제점: 교수ID → 강의실 이 종속성에서 교수ID가 결정자이지만 후보 키가 아님
               => 교수ID만으로 테이블의 모든 행을 고유하게 식별할 수 없기 때문
               => BCNF 위반
               => 강의 ID를 추가할 때, 만약 교수 ID가 같다면 강의실 값이 반복됨
                     & 특정 교수의 강의실을 변경하려면 반복된 행을 전부 수정해야함
  • BCNF 적용: 교수ID → 강의실 종속성을 따로 분리
    • 테이블 1: 교수ID와 강의실
    • 테이블 2: 강의ID와 교수ID

 

 

참고 자료:

https://terms.naver.com/entry.naver?docId=3431248&cid=58430&categoryId=58430&expCategoryId=58430

 

 

'CS > DB' 카테고리의 다른 글

[DB] 트랜잭션  (0) 2025.01.29
[DB] Connection & DB Session  (0) 2025.01.27
[DB] 인덱스 정의, 동작 방식, 종류 등 톺아보기(MySQL 기준)  (0) 2025.01.14
[DB] JOIN 알아보기  (0) 2025.01.09
[DB] SQL 톺아보기  (0) 2025.01.09