프레임워크/Spring

#13 모델 설계 1

Scala0114 2022. 5. 13. 22:56

1. ERD 작성

  • 본격적으로 게시판 개발에 들어가기 위해 데이터 모델을 설계할 필요가 있다. 위 그림은 이번 게시판 프로젝트를 위해 간단하게 작성한 ERD이다. (ERD 작성을 위한 툴은 매우 다양하지만 이번에 사용한 QuickDBD는 텍스트 코드를 작성하면 이를 파싱하여 위 처럼 깔끔하게 ERD를 그려주기 때문에 굉장히 편리했다. 앞으로도 ERD 작성은 이 사이트를 이용하게 될 것 같다.)

  • 각 엔티티들과 그 사이의 관계를 어떻게 구성했는지 하나씩 살펴보며 정리해보자(PK로 사용할 식별자(id)에 대해서는 별도로 설명하지 않기로 한다).

 

2. 회원 정보

  • member
    • 회원 정보를 저장하기 위한 엔티티
    • name
      • 회원 ID. 여기서의 ID는 PK로서의 ID가 아닌 로그인시에 입력하는 계정이름을 의미(최대 20자)

    • password
      • 회원 비밀번호. 회원 가입 시에 입력받아 로그인 시에 사용
      • 암호화된 패스워드를 저장해야 하기 때문에 넉넉하게 최대 크기를 100자로 잡음

    • email
      • 회원의 email 주소(최대 50자)

    • register_datetime
      • 회원 가입 일시

 

  • role
    • 역할(권한)을 나타내기 위한 엔티티 

    • name
      • 역할의 이름(최대 20자)

 

  • member_role
    • member와 role 을 연결해주기 위한 엔티티

    • 한 명의 member는 여러 개의 role을 가질 수 있고 하나의 role 또한 여러 멤버에게 주어질 수 있기에 두 엔티티의 관계는 다대다(N:M) 관계이다. 관계형 데이터베이스에서 다대다 관계를 나타내기 위해서는 사이를 이어줄 join table이 필요한데, 이 역할을 해주기 위해 필요한 엔티티이다.

    • member_id
      • role을 가질 member의 PK
    • role_id 
      • member가 가질 role의 PK

 

 

3. 게시글 관련 정보

  • post
    • 게시글의 정보를 저장하기 위한 엔티티

    • title
      • 게시글 제목(최대 40자)

    • content
      • 게시글 내용
      • 게시글 내용은 매우 길어질 수 있기 때문에 TEXT 타입을 사용

    • create_datetime
      • 작성 일자

    • modify_datetime
      • 최근 수정 일자

    • author_id
      • 작성자인 member의 PK

 

  • comment
    • 댓글의 정보를 저장하기 위한 엔티티

    • content
      • 댓글 내용(최대 255자 - VARCHAR 최대크기)

    • create_datetime
      • 작성 일자

    • modify_datetime
      • 수정 일자

    • author_id
      • 작성자인 member의 PK

    • post_id
      • 댓글이 달린 post의 PK

 

  • vote_info
    • 게시글의 추천(혹은 좋아요) 정보를 관리하기 위한 엔티티
    • 하나의 게시글을 여러 회원이 추천할 수도 있으며 한 명의 회원이 여러 게시글을 추천할 수도 있는 다대다 관계
    • member : role 관계때와 마찬가지로 post와 member를 연결해줄 엔티티로 사용됨

    • post_id
      • 추천받은 post의 PK

    • voter_id
      • 추천한 member의 PK

 

 

 이정도면 게시판을 개발하기 위해 필요한 기본적인 데이터 모델의 설계가 끝났다고 볼 수 있다. 다음에는 실제 프로그램상에서 사용될 클래스를 설계하기 위해 클래스 다이어그램을 작성해볼 것이다.

 

 

+ ERD 수정)

  • 기존에는 member와 role을 다대다 관계로 매핑하려 했지만 굳이 조인테이블을 두는 것보다 role은 enum 타입을 정의하여 입력을 한정하고 하나의 member가 여러개의 member_role 테이블의 레코드에 매핑되는 방식이 나을 것 같아서 구조를 조금 바꿨다. role 엔티티가 없어지고 member_role에 role의 이름이 바로 들어가도록 수정되었다.

  • post에 조회수를 나타내기 위해 view_count 속성을 추가했다.
  • member의 name에 index를 추가했다.
저작자표시 (새창열림)