[토이프로젝트] DB 설계하기 -1

📌 이 글은 Youtube 시니어코딩 - '{풀스택#22} MySQL - 데이터 모델 설계, 실무에서는 이렇게 프로젝트 시작과 설계를 한다!' 영상을 참고하여 작성하였습니다.
링크 : https://www.youtube.com/watch?v=GroeyzBNhfU

 

작은 토이 프로젝트를 진행 중이다. DB에 데이터를 넣기 전, 소위 'DB를 설계한다'는 과정에 대해 기초 개념을 잡고 그를 반영하여 프로젝트를 진행해보기 위해 포스팅을 작성하기로 했다.

 

데이터베이스의 모델링은 개념적 모델링 - 논리적 모델링 - 물리적 모델링으로 진행한다.

 

데이터베이스 모델링이 중요한 이유는, 기능 추가나 서비스의 기능 변경에 어려움을 겪는 경우가 대부분이 데이터베이스 설계를 잘못한 경우가 많기 때문이다. 실제로 코딩을 잘하는 사람은 많지만, 데이터베이스를 잘하는 사람은 매우 많은 것은 아니다. 메이저 회사 같은 경우는 DBA라고 해서 데이터베이스 직무가 따로 있는 경우가 있지만, 보통은 서버 개발자가 DB도 설계하는 경우가 많다.

DB 설계를 잘못하거나 문제가 생기는 경우는, 서비스가 명확히 정의되지 않은 경우, 혹은 서비스가 많이 변경되어 최초에 잡아둔 데이터베이스 모델이 맞지 않는 경우가 있다. 이런 경우, 데이터베이스에서 많은 문제 특히 병목이 발생한다. 이 경우 Query로 어느정도 수습은 할 수 있지만 궁극적인 해결은 아니다.

---

데이터모델 설계 과정

요구사항 분석  ➡  UseCase Diagram 작성  ➡  Entities, Functions 도출  ➡  Relationships - ERD 작성  ➡  생성 (Pysical Modeling)

 

UseCase Diagram (요구사항 분석)

이해관계자라고 부르는 user가 존재한다. 결국 이 시스템이 어떻게 사용되어진다를 보여주는 다이어그램이다. 

 

Deployment Diagram

서버 구성이 어떻게 되어 있는지 보여주는 다이어그램. 여기서 device라는 것은 물리적인 디바이스와 논리적인 디바이스 두 가지가 있다. 그래서 서버가 웹 서버가 있고, 데이터베이스 서버가 있고, 어떻게 나뉘어있는지 구성도를 그리는 다이어그램을 뜻한다.

 

Sequence Diagram

💡 인스턴스란?    : 클래스를 메모리에 올린 상태

플로우가 복잡하거나, 인스턴스들이 어떻게 살아움직이는지, 언제 생성되어서 언제 소멸되는지를 나타낸다. 즉, 인스턴스의 생명 주기와 인스턴스가 어떻게 움직이는지, 어떤 명령들이 있는지를 정의하는 다이어그램이다. 많이 쓰이지는 않지만, 인스턴스들이 어떻게 움직이는지를 알려면 Sequence Diagram을 그려두면 편하다. 예시를 들어 설명하자면, 그림을 보자. 컴퓨터가 서버에게 메일을 보내는데, 사용자가 checkEmail을 하고, 그 다음 서버에 sendUnsentEmail을 하면 그 때 인스턴스가 생기고, 서버가 활성화되고, 다 보내고 나면 종료가 되며 인스턴스가 죽게 된다. 

Class Diagram

OOP(객체지향프로그래밍)을 할 때에 가장 많이 쓰이는 프로그램. 클래스들이 어떻게 구성되는지, table들은 value object라고 해서 보통 클래스로 하나하나 떨어지게 된다. 화살표는 화살표가 가리키는 곳을 상속받음을 의미한다. 즉, 다이어그램은 클래스들의 구성을 의미한다. 그림에서는 생략되었지만 멤버 변수와 멤버 함수의 Public/Protected/Private 등의 사항도 표현되고는 한다.

 

State Diagram

상태다이어그램이다. 데이터든 변수든, 데이터의 상태가 어떻게 움직이느냐를 보여주는 다이어그램이다.

• transition : 전환 과정
• transition condition : 상태 전환하기
• entry action : 시작하는 시점의 상태

 

Flow Chart

순서도라고 불리는 많이 알려진 다이어그램이다. Base Logic이 복잡하다 싶으면 순서도를 그려보는 것이 좋다. 어떤 순서로 지나가는지. 개발자 뿐만 아니라 기획자도 많이 사용하는 다이어그램이다. 

• 원형 : 시작
• 사각형 : 하나의 task
• 마름모 : 조건절

 

---

정규화(Normal Form, NF)

데이터베이스 설계 중 모델링할 때 가장 중요한 것은 정규화이다. 제1정규화, 제2정규화 등의 용어는 실무에서는 외울 필요는 없고, 결국은 중복데이터를 최소화하는 것이다. 같은 데이터가 여러 테이블에 분산되어있으면 관리하기 어렵기 때문에 중복데이터를 없애고 관계를 단순하게 가져간다.

신입개발자 시절에는 테이블 하나에 데이터를 담는 게 단순한 것인 줄 안다. 그러나 데이터 모델링을 하다 보면, 성격이 다른 데이터는 서로 분리하는 것이 맞다. 이를테면 '학생', '수강신청' 테이블을 하나로 두면 코딩은 쉽겠지만 실제로 데이터베이스는 복잡해진다. 이는 실무에서 해보다보면 스스로 알게 되고, 따라서 이 정규화 과정은 실제로 해보면 몸에 체득이 된다. 무엇인지만 알고 있으면 자연스럽게 된다.

 

제1정규화(1NF) : 원자성

모든 속성은 하나의 값(Atomic Value)만 갖는다.

 위 테이블을 보면 추신수, 박세리는 원자성을 준수하지 않는 것을 확인할 수 있다. 이에 1정규화 과정을 거쳐 원자성을 갖도록 분해할 수 있다.

 

 

제2정규화(2NF) : 완전 함수적 종속 (부분 종속 제거)

모든 속성은 기본키에 종속되어야 한다. 즉, table에 따라 종속되는 column들만 두자는 것.

위와 같은 테이블에서 기본키는 (학생번호, 강좌이름)으로 이루어진 복합키이다. 

모든 키는 기본키에 종속되어야 하는데, 값들을 보면 '강의실' 속성의 값들은 '강좌이름'에 의해 결정될 수 있다. 즉, 강좌 이름은 기본키(학생번호, 강좌이름)의 부분키인데, '강의실' 속성은 '강좌 이름'에 종속되어있다는 것이다. 이를 부분 함수적 종속이라고 하는데, 이를 분해하는 것을 2정규화라고 한다.

 

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

기본키가 아닌 모든 속성 간에는 서로 종속될 수 없다! 

정규화는 제4,5,6.. 계속 있지만 가장 주요한 것은 3까지. 그러나 앞으로도 정규화는 필요할 때마다 꾸준히 해나가야 한다.

이행적 종속이라는 것은 A → B, B → C일 때 A → C가 성립되는 것을 의미한다. 예를 들면, 아래의 테이블에서는 '수강료'가 '학생번호' 속성에 이행 종속되어있다고 볼 수 있다.

정규화에서 이행적 종속을 제거해야 하는 이유는 다음과 같이 생각해보면 쉽다. 예를 들어, 402번 학생이 자료구조 수업으로 수강 변경을 하게 되면 수강료도 함께 변경해주어야 하는 번거로움이 생긴다. 이러한 것을 방지하기 위해 제3정규화를 하는 것이다.

제3정규화를 통해 분해한 결과는 다음과 같다.

 

BCNF(Boyce and Codd Normal Form) 정규화

모든 결정자는 후보키에 속해야 한다. 

BCNF 정규화는 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다.

위 테이블에서 문제는, '교수' 속성은 특강 이름을 결정하는 결정자임에도 후보키가 아니라는 점이다. 이를 후보키로 만들어주면 결과는 다음과 같다.

 

 

 

❗

정규화를 잘 했는데 테이블을 많이 쪼개다보니 성능이 나빠지거나, 비효율성이 발생할 수 있다. 그럴 때에는 반정규화를 한다.

 

 

반정규화 (역정규화)

정규화된 데이터 모델을 통합, 중복, 분리하는 과정. 의도적으로 정규화 원칙을 위배하는 것이다.

• 테이블 반정규화 (중복/통계/이력/부분 테이블)
• 컬럼 반정규화 (중복/파생 컬럼)
• 관계 반정규화

❗  데이터 유지 계획 必!!

반정규화는 빅데이터를 다루는, 데이터가 방대한 시스템(ex: 데이터 웨어하우스)에서는 반정규화를 많이 한다. 성능을 위해 반정규화를 한다는 것이다. 단, 한 데이터가 바뀌었을 때 다른 데이터를 어떻게 바꿀 것인지에 대한 데이터 유지 계획이 필수적이다.

 

1차 반정규화

고객에 대한 엔티티 타입에 방문을 두 번까지 가능하다고 해보자.

아래 그림을 보면, 고객번호, 고객명이 중복 속성 값을 갖기 때문에 1차 정규화의 대상이 되어 중간에 있는 고객방문 엔티티 타입으로 1차 정규화가 되었다. 그러나 최대 2회까지 방문이 가능하다는 업무 규칙을 이용하여 성능과 단순성을 고려하여 오른쪽에 있는 1차 정규화에 대한 반정규화 엔티티 타입으로 설계된 예이다.

 

최대 발생하는 값을 이용한 이와 같은 반정규화의 유형은 실전 프로젝트에서 빈번하게 사용되지만, 최대 발생 값이 변할 수 있는 경우는 정규화된 모습으로 모델링해야 확장성(flexible)이 보장된다는 것을 기억해야 한다.

 

2차 반정규화

그림의 모델은 일자별 매각 물건 엔티티 타입에서 매각 일자가 결정자가 되고, 매각 장소와 매각 시간이 의존자가 된 함수 종속성이 존재하여 2차 정규화를 적용했다가 다시 조인에 의한 성능저하 예방과 단순성을 위해 다시 일자별매각물건이라는 엔티티 타입에 반정규화를 한 경우이다.

 

3차 반정규화

그림을 보면 수납이라고 하는 엔티티 타입은 속성간의 결정자(수납확인번호)와 의존자가 존재하는 3차 정규화의 대상이 되는 모습이다. 따라서 수납확인번호를 결정자로 하고 수납확인방법, 수납확인일자, 수납확인자사번을 속성으로 하는 3차 정규화를 적용하였다.

반정규화를 하는 대상으로는 테이블, 속성, 관계에 대해 적용할 수 있으며 꼭 테이블과 속성, 관계에 대해 중복으로 가져가는 방법만이 반정규화가 아니고 테이블, 속성, 관계를 추가할 수도 있고 분할할 수도 있으며 제거할 수도 있다. 정규화에 위배되는 것은 아니지만 성능을 위해 적용하는 반정규화의 방법으로는 테이블 통합/분리, 속성 중복, 관계 중복 등 여러 가지가 있을 수 있다.

 

---

참고 자료

• https://mangkyu.tistory.com/110 [MangKyu's Diary:티스토리]
• http://keiis.co.kr/study0/600.Utility/A100.DB/E010.ERwin/100.normalization.html