[CS] ERD와 정규화 과정

1. ERD

• 데이터 베이스를 만들기 전에 데이터 구조와 관계를 시각적으로 정리하는 단계
• 릴레이션 간의 관계들을 정의한 것
• 시스템의 요구 사항을 기반으로 작성됨
• 디버깅 또는 재설계가 필요한 경우에도 설계도 역할 담당
• 관계형 구조로 표현할 수 있는 데이터를 구성하는 데 유용
• But, 비정형 데이터는 충분히 표현할 수 없음
  🌱 비정형 데이터: 미리 정의된 데이터 모델이나 정의된 방식이 없는 정보 

 

---

2. 정규화 과정

• 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나서, 이를 해결하거나 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정
• 데이터베이스 이상 현상
  • 삽입 이상 : 불필요한 정보를 함께 저장하지 않으면 어떤 정보를 저장하는 것이 불가능하다.
  • 갱신 이상 : 반복된 데이터 중에 일부를 수정할 경우 데이터 불일치가 발생한다.
  • 삭제 이상 : 어떤 정보를 삭제할때 필요한 정보가 같이 삭제된다.
  • 예시학생명 학과 과목 교수

    보니	컴공	DB	김교수
    보니	컴공	OS	이교수

    1. 삽입 이상 → 아직 과목이 없으면 학생 정보 저장 불가
    2. 갱신 이상 → 학과명을 “컴퓨터공학과”로 바꿀 때 모든 행 수정 필요
    3. 삭제 이상 → OS 과목 삭제 시 학생 정보까지 함께 사라질 위험
• 테이블 내의 데이터들이 불필요하게 중복되어 테이블을 조작할 때 발생되는 데이터 불일치 현상
• 정규화 원칙

1. 같은 의미를 표현하는 릴레이션이지만 좀 더 좋은 구조로 만들기
2. 자료의 중복성은 감소시키기
3. 독립적인 관계는 별개의 릴레이션으로 표현하기

 

1) 제1정규형 (1NF)

• 릴레이션에 속하는 속성 값이 모두 원자값(Atomic Value)만으로 구성되어야 한다.
• 즉, 하나의 칸에는 하나의 값만 리스트, 배열, 묶음 형태 ❌

❌ 잘못된 예시

학생명	수강과목
보니	DB, OS

✅ 1NF 만족

학생명	수강과목
보니	DB
보니	OS

 

2) 제2정규형 (2NF)

• 릴레이션이 제1정규형이면서, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속인 형태
• 릴레이션을 분해할 때 동등한 릴레이션으로 분해되어야 함
• 정보 손실이 발생하지 않는 무손실 분해로 분해되어야 함
• 예시

  학생ID	과목ID	학생이름	과목명	학과	학점
  S1	C1	보니	컴공	DB	3
  S1	C2	보니	컴공	OS	3
  S2	C1	귤	소프트	DB	3

  • 기본키(PK): (학생ID, 과목ID) ← 복합키
  • 학생ID → 학생이름, 학과 / 과목ID → 과목명, 학점학생이름
  • 학과 ❌ PK 전체가 아니라 학생ID 일부에만 의존→ 이것이 바로 부분 함수 종속
  • 과목명, 학점 ❌ 과목ID 일부에만 의존
  • 그런데 현재 PK는 (학생ID, 과목ID)
  • 데이터 이상현상
    1. 갱신 이상 : 보니의 학과를 “컴퓨터공학과”로 변경 → S1이 포함된 모든 행 수정 필요
    2. 삽입 이상 : 아직 수강하지 않은 학생은 저장 불가 → 과목ID 없으면 PK 구성 불가
    3. 삭제 이상 : S2가 DB 과목을 취소하면 DB 과목 정보 자체가 사라질 위험
  • 해결방법 → 부분 함수 종속을 분리시키기 💡

2NF 만족

 

3) 제3정규형 (3NF)

• 제2정규형이면서, 기본키에 속하지 않은 모든 속성이 기본키에 이행적 함수 종속이 아닌 정규형
  🌱 이행적 함수 종속 : A → B, B → C 이면, A → C 가 성립하는 관계. 이 때 C가 A에 이행적으로 함수 종속이 되었다고 한다.
• 예시
  
  

  과목ID	교수ID	교수이름	교수연락처
  C101	P01	김교수	010-1111
  C102	P01	김교수	010-1111
  C201	P02	이교수	010-2222

• 기본키(PK): 과목ID → 모든 일반 컬럼은 과목ID 전체에 종속
• 즉 교수ID → 과목ID에 의해 결정되고, 교수이름, 교수연락처 → 과목ID에 의해 결정됨.
  따라서 부분 함수 종속은 없음 (기본키가 단일 컬럼이기 때문에 2NF 조건은 자동 충족)
• 단, 기본키(과목ID)가 교수ID를 거쳐 교수 정보(이름, 연락처)를 간접적으로 결정 👉 이행적 함수 종속 발생
• 데이터 이상 현상
  1. 갱신 이상
     
     1. 김교수의 연락처가 바뀜
     2. 김교수가 담당한 모든 과목 행을 다 수정해야 함
  2. 삽입 이상
     
     1. 새 교수(P03)를 미리 등록하고 싶음
     2. 하지만 과목ID가 없으면 삽입 불가
  3. 삭제 이상
     
     1. 과목 C201 삭제
     2. 이교수가 해당 과목 하나만 담당했다면? → 과목 삭제와 함께 교수 정보 자체가 통째로 사라짐
• 해결방법 → 이행 관계 끊기(=테이블 분리)💡

 

• •  

4) 보이스/코드 정규형

• 제3정규형이고, 결정자가 후보키가 아닌 함수 종속 관계를 제거
• 모든 결정자가 후보키인 상태
• 정규형 과정을 거쳐 테이블을 나눈다고 해서 성능이 100% 좋아지는 것은 X
  → 조인을 많아져 오히려 느려질 수도 있으므로 서비스에 따라 정규화 또는 비정규화 선택
• 3NF로도 해결되지 않는 특수한 종속 관계 제거
• 실무에서는 3NF까지만 적용하는 경우가 많음