개요

넘블 인스타그램 프로젝트를 하면서 ERD를 짜 본 내용이다.

ERD

ERD란, Entity Relationship Diagram의 약어로 개체-관계 모델을 뜻한다. 프로젝트를 시작하기 전, 대략적인 데이터베이스의 테이블 형태를 설계하는 게 좋다. 개발과 동시에 ERD를 작업한다면, 변경 사항이 생겼을 때 대처하기 어려울 수도 있기 때문이다.

설계한 내용

설계한 ERD는 위의 그림과 같다.

User

• 유저는 닉네임과 프로필 이미지를 가지고 있다.
• 향후 유저 탈퇴 기능을 구현할 때, soft delete 방식을 활용할 것이기에 유저의 상태를 나타내는 activated를 만들었다. (soft delete: 논리적으로만 삭제 처리를 하는 것, 데이터베이스에 남아 있다.)

Post

• 글은 내용과 이미지 주소, 작성자를 가지고 있다.
• 작성자는 User이므로, User : Post = 1 : N의 관계를 설정한다.

Comment

• 댓글은 내용과 글, 작성자를 가지고 있다.
• Post : Comment = 1 : N 관계이며, User : Comment = 1 : N 관계이다.

Reply

• 답글은 댓글을 의존한다. 내용과 댓글, 작성자를 가지고 있다.
• Comment : Reply = 1 : N 관계이며, User : Reply = 1 : N 관계이다.

Follow

• Follow는 유저와 유저 간의 관계이다.
• 따라서 User와 User를 묶을 수 있는 별도의 브릿지 테이블인 Follow를 생성했다.
• 브릿지 테이블은, 참조되는 FK들이 N의 입장이어야 한다. 즉, User : Follow = 1 : N 관계가 된다.

UserAuthority

• 요구사항 중 Spring security의 whitelist에 따라 페이지를 허가하는 작업이 필요했다. 즉, 가입한 사람들에 대해서는 일종의 권한을 부여하는 작업이 필요하다.
• 때문에 Authority 테이블을 만들었고, 각 유저가 어떤 권한을 가질 수 있는지의 브릿지 테이블인 UserAuthority 테이블을 만들었다.
• User : UserAuthority = 1 : N, Authority : UserAuthority = 1 : N 관계가 된다.

Authority

• 권한을 나타낸다.

Message

• 메시지는 내용, 보낸 시각, 작성자, 방을 가지고 있다.
• User : Message = 1 : N, ChatRoom : Message = 1 : N 관계가 된다.

ChatRoom

• 방을 나타낸다.
• 1:1 대화를 가정한다. 때문에 방을 연 사람 (opener), 이후에 들어온 사람 (joiner)으로 구분된다.
• User : ChatRoom = 1 : N 관계를 가진다.

느낀 점 & 알게 된 점

• JPA에서는 객체를 참조하게끔 하지만, ERD를 설계할 때는 참조하는 객체의 id를 참조하도록 설정해야 한다. 예시로, 글에서 작성자를 참조할 때 JPA에서는 Post 클래스에서 필드로 User를 가지지만, ERD를 설계할 때는 User의 id인 long 타입을 참조해야 한다.
• 메시지, 방은 제대로 못 완수한 채 개발을 진행했었다. 앞으로는 확실히 ERD 작업이 끝난 뒤에 개발하도록 하자.

참고 자료

• dbdiagram (이 곳을 통해서 작업하였다.)
• 결과물 확인
• dbdiagram 문법 참고
• 브릿지 테이블 - IBM 문서

부족하거나 수정할 사항이 있으면 댓글 부탁드립니다 😃