[Beyond SW / 7일차 복습 - 2] 정규형, DB Dump 실습

정규화

정규화란 관계형 스키마를 더 좋은 구조로 정제해 나가는 과정입니다.
이 포스트에서는 1, 2, 3차 정규형에 대해서만 다뤄보고자 합니다.

 

 

1차 정규화(도메인 분해)

• 모든 컬럼이 하나의 값만 갖도록 데이터베이스가 설계되어 있다면, 그 설계는 1차 정규형이라고 합니다.

즉 아래와 같은 설계는 1차 정규화가 되지 않은 것입니다.

사진 출처: https://www.youtube.com/watch?v=FYDHJbIwm5Y

이런 경우, topic 테이블과 tag 테이블을 따로 분리하고, topic과 tag 사이에 정션 테이블(교차 테이블)을 추가해줌으로써 하나의 컬럼이 하나의 값만 가지도록 풀어줄 수 있습니다.

 

 

2차 정규화(부분 종속 제거)

• 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속된 상태를 의미합니다.

즉, 2차 정규형을 만족하기 위해서는 기본키가 아닌 속성들은 모두 기본키에 완전 함수 종속 되어야하며,
기본키가 복합키인 경우 그 복합키들 중 하나에만 종속적이라면 2차 정규형 위반입니다.

위의 테이블이 2차 정규형을 위반하는 테이블입니다.
위 테이블은 'title'과 'type'을 복합키로 쓰고 있습니다.
위 테이블을 보면 뭔가 이상한데, 'description', 'created', 'author_id', 'author_name', 'author_profile' 등의 컬럼에서 자꾸 중복이 발생합니다.
그 이유는, 그 컬럼들이 복합키 전체에 의존적인 것이 아니라, 복합키의 일부인 'title'에만 의존하고 있기 때문입니다.
그런 경우 테이블을 아래와 같이 분리 시켜줌으로써 해결할 수 있습니다.

'title'에만 의존적인 정보들은 'topic'테이블에 남기고, 'title', 'type'에 모두 의존적인 'price'를 'topic_type' 테이블로 분리하였습니다.

 

 

3차 정규화 (이행 종속 제거)

• X -> Y이고 Y->Z이면 X->Z 성립하여 Z가 X에 이행적으로 함수 종속을 가지면 그 테이블은 3차 정규형 위반입니다.
• 모든 속성이 기본키에 이행적 함수 종속이 되지 않아야 3차 정규형입니다.
• 기본키에 대한 이행적 함수 종속이 생기는 이유는 어떤 속성이 기본키 속성이 아닌 다른 속성에 의존하고 있기 때문입니다. 이런 의존성이 생기지 않도록 테이블을 분리합니다.

위 테이블을 보면, 노란색으로 표시된 부분인 'author_id', 'author_name', 'author_profile'의 내용이 계속 중복되는 것을 확인할 수 있습니다.
이런 중복이 발생하는 이유는 'author_name', 'author_profile' 이 두 속성이 'author_id'에 의존하고 있고, 'author_id'는 'title'에 의존하고 있기 때문입니다.

이런 경우 author 테이블을 따로 분리하여 이행적 종속을 제거하면 3차 정규형이 완성됩니다.

 

 

그 외의 정규형들

그 외 정규형들은 실효성이 조금 떨어지기도 하고, 이해가 완전히 되지 않는 부분도 있기에 간단한 설명을 덧붙이고 넘어가겠습니다.

BCNF(Boyce and Codd Normal Form)

• 결정자이면서 후보키가 아닌 것들을 제거한 정규형입니다.
• 갱신 이상이 발생하지 않도록 하기 위함입니다.

4NF(다치 종속 제거)

• 다치 종속성이란 하나의 릴레이션에서 여러 속성과의 관계가 1:N인 관계를 의미합니다.

5NF(조인 종속성 제거)

• 조인 종속성이란 하나의 릴레이션을 여러 릴레이션으로 분해했다가 다시 조인했을 때 데이터 손실이 없고 필요없는 데이터가 생기는 것을 의미합니다.

 

 

반정규화

• 조인이 너무 많아지는 쿼리는 요청을 처리하는 시간을 증가시킵니다.
• DB의 전반적인 성능을 향상 시킬 수 있도록 중복을 허용하며, 엔티티를 다시 통합시키거나 정규화된 테이블의 구조를 변형하는 과정을 의미합니다.

예를 들어, 아래와 같은 쇼핑몰 ERD가 있다고 하겠습니다.
쇼핑몰에서는 보통 상품을 누르면 디테일 정보와 후기도 같이 보이기 때문에 상품 정보와 후기 정보를 함께 보여주는 작업이 매우 빈번합니다.
그런데 아래와 같은 구조에선 상품 정보와 후기 정보를 함께 보여주려면 저렇게 최소 4개의 테이블이 조인되어야 합니다.

이럴 때, 이행적 종속이 생기더라도 후기 테이블에 product_id를 fk로 걸어주면, product와 review 테이블만 조인하고도 후기 정보를 찾아올 수 있습니다.

 

 

 

---

DB Dump

• 데이터베이스의 구조와 데이터를 SQL 형식으로 추출하는 데 사용되는 방식입니다.
• 주로 특정 DB에서 다른 DB로 데이터와 DB 구조를 이전, 복사, 백업할 때 사용합니다.

MariaDB 데이터베이스 덤프 파일을 생성하는 명령어

mysqldump -u [username] -p --default-character-set=utf8mb4 [database name] > dumpfile.sql

예시: board 테이블의 덤프 파일 만들기

mysqldump -u test -p --default-character-set=utf8mb4 board > dumpfile.sql

덤프파일의 내용은 아래처럼 생겼습니다. (테이블을 만드는 DDL와 기존 DB의 데이터들을 넣는 insert문이 들어가 있습니다.)

 

 

덤프 파일의 내용을 다른 DB로 옮기기

mysql -u [new_username] -p[new_password] [new_database_name] < dumpfile.sql

• 참고: MariaDB는 mysql의 fork이므로 덤프 과정에서 mysql 명령어가 사용됩니다.

---

Reference

• Beyond SW 7기 강의와 강의 자료
• 정규형 사진 출처: 생활 코딩 유튜브