(Chapter 7) Relational Database Design

( 출처 : 연세대학교 데이터베이스 시스템 수업 (CSI6541) 강의자료 )

Chapter 7. Relational Database Design

(1) 이상 (anomaly) 현상

• 이상 (anomaly) 현상 :

  • 불필요한 데이터의 중복으로 인해,

    (데이터 삽입/수정/삭제 연산 등을 수행할 때) 발생할 수 있는 부작용

• 정규화 :

  • 이상 현상을 제거 & DB를 올바르게 설계

이상 현상 example )

(2) 함수 종속성

• 정규화 :

  • 이상 현상이 발생하지 않도록,

    relation을 관련 있는 속성들로만 구성하기 위해 릴레이션을 분해하는 과정

  • 함수적 종속성을 판단하여, 정규화를 수행!

• 함수 종속 (FD, Functional Dependency)

  • 속성들 간의 관련성

  • “X가 Y를 함수적으로 결정한다”

    ( = “Y가 X에 함수적으로 종속되어 있다” )

    ( X -> Y … X : 결정자 & Y : 종속자 )

    • relation 내의 모든 튜플에서, 하나의 X값에 대한 Y값은 항상 한개

Example)

함수 종속 다이어그램

• 함수 종속 관계를 도식화
• 표현 :
  • relation의 속성 : “직사각형”
  • 속성 간의 함수 종속성 : “화살표”

함수 종속 관계 판단 시 유의 사항

• 속성 자체의 특성 & 의미를 기반으로, 함수 종속성을 판단해야!
• (일반적으로) 기본키 & 후보키 : relation의 다른 모든 속성들을 함수적으로 결정한다!
  • (기본키, 후보키가 아니어도 가능할 수 있긴함 ㅇㅇ)

완전 함수 종속 & 부분 함수 종속

( let 속성집합 X & 속성집합Y -> X & Y )

• (1) 완전 함수 종속 (Full FD)

  • Y가 “X 전체”에 함수적으로 종속되어 있지만,

    “X의 일부분”에는 종속되어 있지는 않음

  • 일반적으로, 함수종속 = 완전함수종속

  • ex) 당첨여부 : {고객 아이디, 이벤트 번호}에 FFD

• (2) 부분 함수 종속 (Partial FD)

  • Y가 “X 전체”뿐만 아니라, “X의 일부분”에도 함수적으로 종속
  • ex) 고객 이름 : {고객 아이디, 이벤트 번호}에 PFD

도식화

• relation의 속성 : “직사각형”
• 속성 간의 함수 종속성 : “화살표”
• 복합 속성 : “직사각형”

( 결정자 = 종속자 /// 결정자가 종속자를 포함 등 …. -> 고려할 필요가 없음! )

함수 종속 규칙

함수 종속과 기본키

• relation의 함수 종속을 파악하기 위해서, 우선 기본키를 찾아야

• 기본키가 “함수 종속에서 어떠한 역할”을 하는지 알면,

  (이상 현상을 제거하는) 정규화 과정을 쉽게 이해할 수 있음!

relation R(K,A1,...AN)에서 K가 기본키이면, K -> R 성립
즉, K는 relation의 모든 속성에 대해 "결정자(Determinant)"이다.

(3) 이상 현상과 결정자

이상현상은, 1개의 relation에 2개 이상의 정보가 포함 되어 있을 떄 발생!

• “기본키가 아니면서”, 결정자인 속성이 있는 경우 발생!

  • ex) 학생 수강 성적 relation

    • 학생 정보 ( 학생 번호, 학생 이름, 주소 학과 )

    • 강좌 정보 ( 강좌 이름, 강의실 )

    • 학생 정보 & 강좌 정보가 1개의 relation에 포함되어서 이상 현상이 나타남!

      ( 학과, 학생번호, 강좌 이름 = 기본키가 아니면서, 결정자이다! )

이상 현상을 없애기 위해 …. relation을 분해 하자!

• ex) (학과, 학과사무실) 속성을 학생 수강성적 relation에서 분리!

분해한 결과 :

(4) 정규화 (normalization)

정규화

• 함수 종속성을 이용해서, relation을 “연관성이 있는 속성들로만” 구성되도록 분해

• 이상현상이 발생하지 않는 relation으로 만들기!

  ( 즉, “관련이 없는 함수 종속성은 별개의 relation으로 표현하기” )

• 주의 사항

  • 무손실 분해 (non-loss decomposition)이 되어야! ( no 정보 손실 )

    ( 즉, 정규화 이전으로 복원 가능해야! )

정규형 (NF, Normal Form)

• relation이 정규화된 정도
• 각 정규형마다 제약조건이 존재
  • 정규형의 차수가 높아질 수록, 요구되는 제약조건 UP
• relation의 특성을 고려해서, 적절한 정규형을 선택해야함

정규화 과정

제 1 정규형 (1NF)

• relation의 모든 속성이 더는 분해 되지 않는 원자값 (atomic value) 만을 가질 경우!

• 이를 만족해야, 관계 DB의 relation이 될 자격이 있음

• ex) 제 1 정규형을 “만족하지 않는” relation

• ex) 제 1 정규형을 “만족하는” relation

  

  

• 제 1정규형을 만족하지만, 데이터 중복으로 인한 이상 현상 발생!

  

  • 발생 이유 : 기본키 ({고객 아이디, 이벤트 번호})에 완전 함수 종속되지 못하고,

    일부분 {고객 아이디} 에 종속되는 “등급” & “할인율” 속성이 존재하기 떄문!

  • 해결 방지 : 부분 함수 종속이 제거 되도록, 이벤트 참여 릴레이션을 분해!

    -> 분해된 릴레이션은 제 2정규형에 속하게 됨.

제 2 정규형 (2NF)

• 릴레이션이 제 1정규형에 속하고,

  (기본키가 아닌) 모든 속성이 기본키에 완전 함수 종속되는 경우!

• 제 1정규형이 제 2정규형을 만족하게 하려면?

  • 부분 함수 종속을 제거 !!

• ex) 제 1정규형을 만족 O & 제 2정규형은 만족 X

• ex) 분해 하기

• 제 2정규형을 만족하지만, 이상 현상 발생!

  • 이유 : 이행적 함수 종속이 존재하므로

  • 이행적 함수 종속 (transitive FD)

    • relation을 구성하는 3개의 속성 집합 X,Y,Z에 대해,

      함수 종속 관계 X->Y & Y->Z가 존재하면, X->Z도 성립!

    • 이때, Z가 X에 이행적으로 함수 종속 되었다!고 말한다

  • 해결 방법 : 이행적 함수 종속이 제거되도록 분해하기!

    -> 분해된 릴레이션들은 제 3정규형에 속하게 된다.

제 3 정규형 (3NF)

• relation이 제 2 정규형에 속하고,

  (기본키가 아닌) 모든 속성이 기본키에 이행적 함수 종속이 되지 않는 경우

• 제 2정규형 -> 제 3정규형 위해…

  • 모든 속성이 기본키에 “이행적 함수 종속이 되지 않도록” 분해 해야!

• ex) 제 2정규형은 만족 O, 제 3정규형은 만족 X

• 이행 함수 종속 제거 위한 분해

  

  

보이스/코드 정규형 (Boyce/Codd NF, BCNF)

• BCNF = 강한 제 3 정규형

• 제 3정규형보다 “더 엄격한 “ 제약 조건

• 하나의 relation에 “여러 개의 후보키”가 존재하는 경우,

  제 3정규형을 만족해도 이상 현상이 발생할 수 있음!

• 정의 : relation의 함수 종속관계에서, 모든 결정자가 후보키이면 BCNF 정규형에 속한다

• ex) BCNF을 만족 X는 예시

  

  

  

• 해결 : 후보키가 아닌 결정자를 제거하기 위한 분해

  

  

기타

• 제 4 정규형 :
  • relation이 BCNF을 만족하면서,
  • 함수 종속이 아닌 다치 종속(Multi Valued Dependency)를 제거할 경우 만족
• 제 5 정규형 :
  • relation이 제 4정규형을 만족하면서,
  • 후보키를 통하지 않은 조인 종속 (Join Dependency)를 제거할 경우 만족
• 정규화 시 주의 사항 :
  • 모든 relation이 제 5정규형에 속해야만 좋은것은 아님!!
  • 일반적으로, 제 3정규형 / BC 정규형 에 속하도록 분해!