데이타베이스

정규형

1NF

릴레이션에 속한 속성들은 원자값(하나의 값)을 갖도록 한다.

2NF

1NF를 만족하면서, 기본키가 아닌 속성들은 기본키의 일부가 아닌 기본키 전체에 함수적 종속해야 한다.

말이 좀 어려우니 표를 보면서 이해해보자.

여기서 기본키는 Studentcode + Course로 정의할 수 있다.

StudentCode를 기본키로 했을 때 특정할 수 있는 정보는 다음과 같다.

• Name, Town, Province

StudentCode와 Course를 조합해야 특정할 수 있는 정보는 다음과 같다.

• DateRegisted

StudentCode + Course가 기본키인데도, StudentCode만으로도 식별이 되는 정보가 있다. 기본키 전체에 함수적 종속이 아닌 기본 키의 부분적 종속성을 갖고 있는 것이다.

그렇기 때문에 StudentCode, Name, Town, Province 테이블 (StudentCode에만 종속적인 컬럼)과 StudentCode, Course, DateRegisted 테이블 (StudentCode 뿐만 아니라 Course에도 종속적인 컬럼)로

쪼개는 것이다.

3NF

2NF를 만족한 상태에서 이행적 종속(Transitive Dependency)이 없어야 한다. 즉, 함수적 종속 관계가 슈퍼 키에서 시작하거나 prime attribute로 끝나야 한다.

이행적 종속이란 무엇인가?

2NF의 Student 테이블을 보자. StudentCode를 통해서 알 수 있는 건 Name, Town, Province 총 3가지 컬럼이다.

여기서 StudentCode를 가지고 알 수 있는 사항은 Name과 Town이다. 그 말은 StudentCode가 Name, Town, Province를 결정한다는 것과 같다.

그런데, Province를 StudentCode가 결정한다고 할 수 있을까? 맞는 말이다. 그러나 Province는 Town만으로도 결정될 수 있다.

Student → Name → Town까지는 결정 요소가 정립되지만, Province를 결정짓는 컬럼은 Town이지 StudentCode가 아니다.

이렇게 A → B를 결정하고 B→ C를 결정한다고 할 때, A → C를 결정하게 되는 사항들을 끊어서 별도의 테이블로 분리하는 과정이 이행 종속성을 없애는 것이다.

보통 3NF 정도 정규화가 되었다면 웬만큼 정규화가 되었다고 한다. 또한 정규화 수준이 높을수록 분석용 쿼리(join이 많고 조회가 잦은 쿼리)에서 성능이 떨어질 수 있기 때문에 무조건 정규화를 4NF, 5NF까지 하는 것이 좋은 것도 아니다.

BCNF

3NF이면서 모든 결정자가 후보키인 경우 BCNF를 만족한다. 반대로 말하면, 후보 키에 속하지 않는데도 row를 결정할 수 있다면 BCNF를 만족하지 못하게 된다.

이 테이블은

• Jack이 강사인 Python Programming 수업이 개설되어도 학생이 없으면 수업을 추가할 수 없다.
• Java Programming 수업의 강사가 바뀔 경우 Student 숫자만큼 데이터를 갱신해줘야 한다.
• 모찌가 수업에서 빠지는 경우 Alan Turing의 Computer Architecture 수업도 사라질 위험이 있다.

이 테이블의 기본키는 STUDENT + COURSE가 될 수도 있고, STUDENT + INSTRUCTOR가 될수도 있다. 이 경우 2개의 릴레이션으로 분리한다면, 모든 결정자가 후보키가 될 수 있으므로 BCNF를 만족하게 된다.

---

https://bit.ly/3FVdhDa
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.