[도트타이머] 1. ERD모델 만들기(aka. 처음 설계할 때 잘하자)

평소 사용하던 도트타이머라는 어플을 만들어보고자 한다. 겉으로는 간단해보이지만 DB설계나 쿼리 작성에 도움이 될 것 같았고 다이어리 어플 안에 내부적으로 돌아가는 원리가 궁금했다.

도트타이머 튜토리얼 – 한글

1. ERD모델

https://www.erdcloud.com/d/g5AyQBakXYHyB3jng

dotetimer

 

위의 사이트에서 ERD모델을 만들었다. 처음에는 Type이 안보여서 당황했는데,  오른쪽 위 환경설정에서 DISPLAY의 Type 체크박스가 하얀색이라 그런 것을 알게되었다. 배경이 검정이라 선택이 하얀색인 줄 알았는데 그 반대였다.

테이블을 어떻게 나눌까... 고민고민

 

1) Entity Type(개체 타입)

• 테이블 이름을 회원 user, 그룹 group, 그룹 입장 group_join, 팔로우 follow, 하루세줄 review, 하루세줄 좋아요 review_like, 할일 plan, 한일 record, 디데이 decimal_day, 기부 donate으로 구성하였다.

2) Attribute(속성)

• 테이블 컬럼을 기본키, 이름, 비밀번호, 날짜, 게시글, 시작시간, 종료시간 등의 항목으로 구성하였다.

3) Data Type(데이터 타입)

4) 카디날리티 유형(테이블 관계) 및 기본키, 외래키 설정, 상속 전략 선택

• 테이블 관계에는 1:1, 1:n, n:m으로 나뉜다. 1:n은 내가 너를 선택한다, n:m은 내가 너를, 너가 나를 서로 선택한다는 의미로 이해했다. 좋아요는 1:n으로, 팔로우는 n:m으로 설계했다. 상속은 일단 외래키를 이용하기로 했다.

 

아래 두 가지를 주의해서 만들자!!

- 1:n 각각 테이블 만들기

- n:m 관계는 각각 테이블에 1:n으로 새로 관계 테이블 만들기

- 1:n에서 n의 테이블에 1의 테이블의 기본키를 외래키로 넣기

 

• user : group = 1 : n, user 부분 참여, group 전체 참여
• user : group_join = 1 : n, user 부분 참여, group_join 전체 참여
• user : review = 1 : n, user 부분 참여, review 전체 참여
• user : review_like = 1 : n (내가 너를), user 부분 참여, review_like 전체 참여
• user : coin = 1 : n, user 부분 참여, coin 전체 참여
• user : follow = n : m (내가 너를, 너가 나를), user 부분 참여, follow 전체 참여
• user : donate = 1 : n, user 부분 참여, donate 전체 참여
• group : group_join = 1 : n, group 부분 참여, group_join 전체 참여
• review : review_like = 1 : n, review 부분 참여, review_like 전체 참여
• coin : plan = 1 : n, coin 전체 참여, plan 전체 참여
• plan_info : plan = 1 : n, plan_info 부분 참여, plan 전체 참여

5) 딜레마(저장해서 쓸 것인가, 찾아서 계산할 것인가...)

10분당 1개씩 누적되는 코인 개수, 기록순위를 위한 총 누적시간, 요일별 누적시간, 시간대별 누적시간, 출석부, 카테고리별 순위, 할일별 시간 순위, 그룹인원 등은 어떻게 할지 고민했는데 일단 저장한 정보를 필요할 때 계산해서 사용하기로 했다.

 

1차

이대로 만들면 어떻게든 되겠지...했지만

만들다 뒤늦게 정규화를 확인해보니 중복이 너무 많았다. 이론을 배우면 뭐하나 실전에서 써먹어야지

DB 설계를 제대로 해보고 싶었기 때문에 다시 설계하기로 했다.

 

2차

6) 정규화 확인 및 상속 전략 수정

한일과 할일의 관계를 조인 전략에서 싱글 테이블 전략으로 변경했다. 잘못 그은 관계선들도 많아서 수정했다.

Defaul/Null은 JPA 작성하면서 생각하자..고 했지만 1인 개발이라 그런지 걍 맘가는 대로 해버리는 이 나쁜 버릇이 튀어나오는 것 같다. 설계부터 명확히 하자.

 

3차

7) Default/Null 지정

• NOT NULL
• DEFAULT CURRENT_TIMESTAMP()
• AUTO_INCREMENT

추가로 기부내역과 기부한금액에 차이가 있을 수 있다는 사실을 뒤늦게 발견했다. 그래서 Coin 테이블을 따로 생성했다. 한일을 기록 후, 삭제할 수 있기 때문에 한일의 시간에 따라 날짜별로 코인을 추가 및 삭제하는 방식으로 하기로 했다.

최종

할일에 따라 코인을 추가 및 삭제할 수 있기 때문에 코인과 할일을 연관매핑했다. 정규화를 재확인하고, 중복되는 회원정보 관계선을 삭제했다.

배운 점

• 이 간단한 어플에 DB설계가 이렇게 까다롭다니 실제 대규모 서비스에서 데이터베이스 설계를 어떻게 하는지 궁금해졌다.
• 새삼스럽지만 개발은 설계가 전부다..라는 걸 느꼈다. 설계를 잘하고 프로그래밍에 들어가자