빠르게 정리하는 데이터베이스 (3) Normalization

Database Normalization

 

DB 정규화: 목적

• 저장되는 데이터의 중복을 줄이고
• 불필요한 데이터 변경을 최소화하며
• 단순한 쿼리로 원하는 데이터를 얻기 위함.

 

예컨대 위와 같은 테이블 구조에서

• university 이름과 주소는 서로 의존적임. (일반적으로) 이름이 바뀌면 주소도 같이 바뀌어야 함.
• 정규화 관점에서는 이런 형태의 데이터를 Redundancy로 취급한다.

따라서, 서로 의존성을 띄고 있는 university 이름 / 주소 정보는 별도의 테이블로 만든 뒤, primary key를 Student 테이블에 매핑한다.

제1정규화 (1NF)

 

확장하기 쉬운 DB 테이블 구조여야 한다.

• 모든 DB 테이블의 value는 atomic해야 한다
• 하나의 컬럼에는 하나의 데이터 타입만 허용한다.
• 컬럼명은 unique해야 한다.
• 데이터 순서는 중요하지 않다. primary key만으로 데이터 조회가 가능함.

 

위 테이블을 예시로 들면

• Atomic하지 않은 Subject 테이블. id 4의 Adam에는 math 또는 physics 하나만 있는 게 좋다.
• primary key로 ID가 정의되어 있음. 입력이 어떻게 들어오건, primay key로 데이터 조회가 가능

제2정규화 (2NF)

 

제1정규화 원칙을 준수한 상황에서, DB 테이블 간 partial Dependency가 없어야 한다.

• 예컨대 student 테이블에서 id, name, age 컬럼이 있다고 할 때
  • id는 primary key. id로 나머지 name, age 정보를 같이 조회할 수 있다.
  • 즉, 나머지 컬럼들은 primary key에 functional dependency가 있다.
• 컬럼이 primary key에 exclusive functional dependency가 있다면, 정규화가 잘 된 것.

 

위 테이블의 경우, primary key는 id와 university id를 활용해야 한다.

• university name이라는 컬럼은 university id에만 dependency가 있고, id에는 없다.
• 반대로 name은 id에만 dependency가 있고, university id에는 dependency가 없다.

이런 경우가 partial dependency. 특정 테이블의 컬럼이 primary key에 온전히 의존하지 않는 상태를 말한다.

 

따라서, parital dependency가 있다면 테이블을 나누는 게 좋다.

제3정규화 (3NF)

 

제2정규화 원칙을 준수한 상황에서 transitive dependency가 없어야 한다.

 

 

primary key가 ID인 상황.

• teacher 정보와 subject라는 정보가 완전히 독립적인가? -> X
  • Java 가르치는 선생이라면 Teacher A일 가능성이 높고
  • Python 가르치는 선생이라면 Teacher D일 가능성이 높다

이 경우에도 테이블을 분리해야 함. student, teacher, subject.

partial Dependency와 다른 점이라면

• partial dependency: 해당 테이블의 primary key와 특정 컬럼 간 dependency 확인.
• transitive dependency: primary key와 무관하게, 컬럼 간 dependency 확인.