database computer_science cs Database DBMS RDBMS ER 정규화 역정규화 정규형

[CS/Computer Science][데이터베이스 / Database] 데이터베이스 설계(ER 다이어그램, 정규화)

Kwangjin Park

May 08, 2025 · 4 min read

Follow

1. ER 다이어그램(ERD)

  • 데이터베이스를 구성하는 요소들의 관계를 나타내는 그림
    • 즉, 엔티티 관계를 표현하는 그림(ERD, Entity Relationship Diagram)
  • 목적 : 데이터베이스 내 저장되는 엔티티 구조 모델링
    • 데이터베이스로 표현할 대상을 시각적으로 설계
    • 데이터베이스 설계 초기단계에서 매우 중요 → 추후 DB 확장 및 수정 시 영향 받는 부분 쉽게 파악 가능
  • 예시 by 표기법
    • 피터 첸 표기법
      • 장 : 개념적으로 모델링하기에는 유용
      • 단 : 엔티티가 많아질 경우에는 다소 복잡해짐 / RDBMS 상에서 어떻게 테이블의 형태로 표현되는지 파악이 어려움 image1
    • IE 표기법(새 발 표기법, 까마귀 발 표기법)
      • 피터 첸 표기법의 한계점을 극복하기 위해 개선된 표기법
        • 사각형 하나가 테이블 하나
        • 상단에는 테이블 이름
        • 내부에는 속성(필드) 이름
        • 기본 키 : 밑줄 표기, PK라 표기하기도 (외래 키는 FK라 따로 표기하기도) image2
      • 테이블 간 관계를 나타내는 표기
        • 새 발, 까마귀 발과 닮은 표기로 테이블 간 관계 표현 image3
      • 식별/비식별 관계
        • 식별 관계 : 참조되는 엔티티(엔티티 A)가 존재해야만 참조하는 엔티티(엔티티 B)가 존재할 수 있는 관계
        • 비식별 관계 : 참조되는 엔티티(엔티티 A)가 존재하지 않아도 참조하는 엔티티(엔티티 B)가 존재할 수 있는 관계 image4

2. 정규화

  • 하나의 테이블을 구성하는 필드들은 어떻게 구성해야 하는지, 이를 결정하기 위한 작업
  • 잠재적인 문제가 발생하지 않도록 테이블의 필드를 구성하는 작업, 필요에 따라 테이블을 나누어줌

  • 정규형 : 정규화된 테이블, NF(Normal Form)
    • 정규형의 종류 : 제1 정규형, 제2 정규형, 제3 정규형, 보이스/코드 정규형, 제4 정규형, 제5 정규형
    • 대부분의 경우, 제3 정규형 혹은 보이스/코드 정규형

제1 정규형

  • 필요충분조건 → “모든 속성이 원자 값을 가진다.”
    • 제1 정규형은 필드 데이터가 더 이상 쪼개질 수 없는 값을 가져야 한다는 조건
  • ex) 아래 테이블은 제1 정규형을 만족하지 못함 → ‘수강과목’ 필드의 데이터는 단일한 값이 아닌 더 많은 데이터로 쪼개질 수 있기 때문 image5
    • 제1 정규형을 만족시키기 위한 두가지 방법
      • 중복되는 레코드를 감수하고 하나의 테이블로 설계하는 방법 image6
      • 테이블을 2개로 쪼개는 것 image7

제2 정규형

  • 제1 정규형 조건 만족 + 기본키 제외한 모든 필드들이 모든 기본키에 완전히 종속
  • 기본 키가 2개 이상의 필드로 구성시 고려
    • 핵심(요지) → 기본 키의 일부에만 종속되는 필드가 존재한다면, 이를 제거하여 기본 키 전체에 종속하도록 필드 구성
  • 즉, 제2 정규형은 아래 두 가지 조건을 만족하는 정규형
    1. 부분 함수 종속성이 없는 상태
      • 부분 함수 종속성: 기본 키가 아닌 필드가 기본 키의 일부에 종속되어 있는 경우
    2. 후보 키에 속하지 않는 모든 필드가 기본 키에 완전 함수 종속인 상태
      • 완전 함수 종속성: 기본 키가 아닌 필드가 기본 키 전체에 완전하게 종속되어 있는 경우
  • ex) 아래 테이블에서, 레코드 식별을 위해 필요한 정보는 ‘회원ID’와 ‘구매 항목’이라 하면
    • 기본 키 이외의 필드가 기본 키에 완전히 종속되어 있나? → 아님
    • 기본 키 이외의 필드가 기본 키에 일부 종속되어 있나? → 맞음(‘가격’ 항목)
      • ‘가격’ → ‘구매 항목’과의 종속성 있음 / ‘회원 ID’와의 종속성은 없음
      • ‘이름’ → ‘회원 ID’와의 종속성 있음 / ‘구매 항목’과의 종속성은 없음
    • 결론: 아래 테이블은 제2 정규형을 만족하지 못함 image8

제3 정규형

  • 제2 정규형 조건 만족 + 기본 키가 아닌 모든 필드가 기본 키에 이행적 종속성이 없는 상태
  • 제3 정규형의 핵심은 “이행적 종속관계”
  • 이행적 종속 관계(Transitive dependency)
    • 삼단 논법과 유사
    • 임의의 테이블 A, B, C가 있을 때, A가 B를 결정하고 B가 C를 결정한다면 → A도 C를 결정하게 됨(종속 관계 형성)
      • 이 때, A와 C는 “이행적 종속 관계가 있다”고 표현함(또는 이행 함수 종속성이 있다)
    • ex)아래 테이블의 기본 키는 ‘학번’이라 하면
      • 한 학생은 한 학과에만 속하고, 하나의 학과는 학과 사무실이 한 곳만 있다면
      • 학번이 학과를 결정하고, 학과가 학과 사무실 위치를 결정함 ⇒ ‘학번’과 ‘학과 사무실 위치’는 이행 종속적인 관계 image9
  • 제3 정규형의 조건
    1. 기본 키가 아닌 나머지 모든 필드들이 간접적으로라도 종속되면 안됨
    2. 기본 키가 아닌 나머지 모든 필드들은 서로를 유추하거나 결정할 수 없어야 함
      • ex) 앞서 살펴본 학번-학과-학과 사무실 위치 테이블에 대해,
      • 제3 정규형을 만족하나? → 아님(이행적 종속관계를 만족하니까)
      • 그렇다면 제3 정규형의 조건을 만족시키기 위해서는? → 이행적 종속관계 제거
      • 이행적 종속관계를 없애기 위해서는? → 테이블을 쪼개 주어야 함 → 제3 정규형 조건 만족 image10

보이스/코드 정규형(BCNF, Boyce-Codd Normal Form)

  • 제3 정규형 조건 만족 + 모든 결정자가 후보 키여야 함
    • 결정자: 특정 필드를 식별할 수 있는 필드
      • ex) 필드 B가 필드 A에 종속적일 경우 → A는 B의 결정자
  • ex) 아래 테이블에서, 한 교수는 한 과목만 담당한다고 하면
    • 이행적 종속 관계를 만족하는 필드는 없음 → 제3 정규형 조건 만족
    • ‘담당 교수’는 ‘과목 코드’의 결정자 역할을 함 → BCNF 만족 X image11

테이블의 정규화 과정 및 역정규화

  • 제1 정규형 → BCNF까지 테이블 정규화과정 흐름 정리 image12
  • 역정규화
    • 정규화 단계를 거듭하면, 데이터는 깔끔하게 정돈 + DB 작업 시 이상현상 감소
    • 그러나, 정규화를 지속적으로 거치면 성능에 악영향을 미침
      • 정규화를 많이 하면 → 테이블이 지속적으로 쪼개지는 경향
      • 테이블이 많이 쪼개지면 → 조인 연산이 빈번해지며 다른 테이블 참조를 위한 성능상 비용 증가
    • 성능상의 이점을 최대한 활용하기 위해서는, 어느 정도의 번거로움을 감소하더라도 가급적 하나의 테이블로 관리하기도 함
      • 검색의 속도를 높이기 위해 분할된 테이블을 하나로 합치는 과정이 역정규화
      • 상황에 따라 정규화를 안하거나 정규화된 테이블을 역정규화 해줌
      • NoSQL은 기본적으로 정규화 X
chat_bubble 0

chat_bubble 댓글남기기

댓글남기기