Skip to content

ERD

Jump to bottom
kim min seop edited this page Oct 12, 2022 · 3 revisions

ERD Model

image

ERD설계시 고려사항

  • 하루 한 줌은 사용자의 습관을 만들어 달성하는 것에 따라 알림 , 뱃지 , 달성도를 보여주며 친구들을 팔로우 , 팔로워하고 팔로우한 친구들의 습관들은 캘린더에서
    확인하여 좋아요를 누르거나 댓글을 다는 서비스로 구성하였다.
    • 때문에 해당 정보들을 관리하는 테이블들과 테이블들의 연관관계를 설정해 관리하는 것이 필요했다.

테이블을 설계할 당시 각 필드 , 테이블의 연관관계를 설정한 의도 및 구조를 설명하기 위해 글로 정리했다.

ERD 각 테이블과 해당 테이블의 필드에 대한 설계 의도

`member` 테이블
  • socialId 소셜 로그인 시 socialId를 기반으로 유저를 구분하기 위해 테이블의 필드를 생성하여 DB에 컬럼으로 등록하여 관리하기 위해 생성했다.
    • 해당 필드는 이후 친구 팔로우, 팔로워등에서 쓰이며 친구 검색 시 검색 코드를 만드는것에 사용되었다.
  • email 소셜 로그인시 가져온 email은 SMTP를 활용한 메일 발송시 사용하기 위한 필드이자 DB에 등록할 컬럼이다.
  • Authority JWT토큰을 사용하기 위한 권한으로 사용하기 위해 필드를 생성했으며 추후 관리자 Id등으로 확장할 여지가 있다고 판단하여 DB에 등록해 관리하기 위해 생성했다.
  • heartClickCnt 좋아요 관련 뱃지를 지급하기 위해 사용하는 필드이자 DB에 등록할 컬럼이다.
  • nickname 유저의 이름으로 댓글 , 마이페이지 등에서 사용하기 위한 필드이자 DB에 등록할 컬럼이다.
  • modifiedAt 유저가 정보를 수정등등의 경우 해당 시점을 파악하기 위해 필드이자 DB에 등록할 컬럼이다.
  • createdAt 유저가 회원가입한 시점을 파악하기 위한 필드이자 DB에 등록할 컬럼이다.
  • status 팔로잉, 팔로워 및 마이페이지에서 사용하는 상태메세지 필드이자 DB에 등록할 컬럼이다.
  • socialCode 유저간 검색 시 사용하기 위한 검색 코드를 발급하기 위한 필드이자 DB에 등록할 컬럼이다.
`image` 테이블
  • member_id 유저와 1:N 관계로 매핑되어 있으며 양방향 관계로 유저의 id를 가지고 관리한다.
  • modifiedAt 유저가 이미지를 수정하는 경우 해당 시점을 파악하기 위해 필드이자 DB에 등록할 컬럼이다.
  • createdAt 유저가 이미지를 생성하는 경우 해당 시점을 파악하기 위한 필드이자 DB에 등록할 컬럼이다.
  • ImgName S3에 저장할 당시 설정한 이미지의 이름이며 URL이 손상 , 변조될 시 검증 및 url 재생성을 위한 필드이자 DB에 등록할 컬럼이다.
  • ImgUrl S3에 저장한 이후 Front에 넘겨줄 Img의 Url 필드이자 DB에 등록할 컬럼이다.
`notification` 테이블
  • member_id 유저와 1:N 관계로 매핑되어 있으며 양방향 관계로 유저의 id를 가지고 관리한다.
  • isRead 알림 발송 이후 true, false값으로 알림 읽기 여부를 확인하기 위한 필드이자 DB에 등록할 컬럼이다.
  • message 알림 발송 api에 사용하며 유저에게 뿌려질 알림의 내용을 담고있는 필드이자 DB에 등록할 컬럼이다.
  • NotificationType 알림 발송 당시 알림의 유형을 식별하기 위한 Enum형식 필드이자 DB에 등록할 컬림이다.
`badge` 테이블
  • member_id 유저와 1:N 관계로 매핑되어 있으며 양방향 관계로 유저의 id를 가지고 관리한다.
  • badgeName 유저에게 부여될 각 뱃지들의 이름을 나타내는 필드이자 DB에 등록할 컬럼이다.
  • badgeNumber 유저에게 부여될 각 뱃지들의 순서를 의미하며 해당하는 순서에 따라 FrontEnd에서 뱃지들을 열거하여 보여주기 위해 사용하는 필드이자 DB에 등록할 컬럼이다.
  • createdAt 뱃지 지급 시점을 파악하기 위한 필드이자 DB에 등록할 컬럼이다.
`comment` 테이블
  • member_id 유저와 1:N 관계로 매핑되어 있으며 양방향 관계로 유저의 id를 가지고 관리한다.
  • goal_id 습관과 1:N 관계로 매핑되어 있으며 양방향 관계로 습관의 id를 가지고 관리한다.
  • modifiedAt 유저가 댓글을 수정하는 경우 해당 시점을 파악하기 위해 필드이자 DB에 등록할 컬럼이다.
  • createdAt 유저가 댓글을 생성하는 경우 해당 시점을 파악하기 위한 필드이자 DB에 등록할 컬럼이다.
  • content 유저가 댓글을 다는 경우 등록하는 내용을 담고있는 필드이며 DB에 등록할 컬럼이다.
  • nickname 유저가 댓글 입력 후 댓글 작성자의 이름을 표출하기 위해 이름을 저장하는 필드이자 DB에 등록할 컬럼이다.
  • profileImage 유저가 댓글 입력 후 댓글 표출 시 이미지를 표출하기 위해 url을 저장하는 필드이자 DB에 등록할 컬럼이다.
  • socialId 댓글의 작성자를 식별하기 위해 유저에게 고유하게 부여되는 socialId를 저장하는 필드이자 DB에 등록할 컬럼이다.
    • 실제 socialId로 작성자를 구분하며 관계가 복잡하게 얽혀있어 JWT claim의 socialId, goal의 socialId와 비교하기 위한 것이다.
    • member_id를 사용하려고 하였으나 추가적인 DB조회가 필요한 경우가 있어 추가적으로 socialId를 생성하여 사용했다.
`heart` 테이블
  • goal_id 습관과 1:N 관계로 매핑되어 있으며 양방향 관계로 습관의 id를 가지고 관리한다.
  • socialId 좋아요의 작성자를 식별하기 위해 유저에게 고유하게 부여되는 socialId를 저장하는 필드이자 DB에 등록할 컬럼이다.
    • 설정당시 습관과 1:N 관계로 매핑하여 유저정보는 socialId로 등록해 jwt의 토큰정보를 기반으로 비교하기 위해 등록했었다.
`goal` 테이블
  • member_id 유저와 1:N 관계로 매핑되어 있으며 양방향 관계로 유저의 id를 가지고 관리한다.
  • socialId 좋아요의 작성자를 식별하기 위해 유저에게 고유하게 부여되는 socialId를 저장하는 필드이자 DB에 등록할 컬럼이다.
  • achievementCheck 습관의 달성여부를 식별하기 위해 boolean값으로 설정한 필드이자 DB에 등록할 컬럼이다.
  • category 습관 달성시 설정할 목표의 날짜이며 해당 날짜에 따라 습관을 자동적으로 생성시키도록 만드는 필드이자 DB에 등록할 컬럼이다.
    • 해당 필드는 이후 뱃지 지급 검증 로직에서 사용되고 있다.
  • charactorId 습관 달성 시 선택한 캐릭터를 식별하기 위한 id이며 해당 id에 따라 전역 메소드에서 url로 바꾸기 위해 사용하는 식별자 필드이자 DB에 등록할 컬럼이다.
    • Front와 약속하여 습관 달성시 주고받는 api에서 1~5값을 설정하여 request로 사용하고 이후 response는 약속된값에 따라 변경하여 응답한다.
  • currentDate 습관 생성 시 현재 날짜를 기준으로 목표 날짜까지 생성하게 됐을 때 해당 습관이 생성될 날짜를 의미하는 필드이자 DB에 등록할 컬럼이다.
  • endDate 습관 생성 시 선택한 목표 날짜에 따라 이후 서비스에서 습관의 목표 날짜를 보여주기 위해 사용하는 필드이자 DB에 등록할 컬럼이다.
  • startDate 한 습관 생성 시 서비스에서 습관의 생성 날짜를 보여주기 위해 사용하는 필드이자 DB에 등록할 컬럼이다.
  • goalFlag 습관 생성 시 목표 날짜까지는 한 묶음으로 계산하기 위해 사용되는 필드이자 DB에 등록할 컬럼이다.
    • 이후 습관 삭제 시 한 묶음으로 삭제 , 한 묶음으로 권한 수정 시 사용되고있다.
      • 목표 날짜까지는 동일한 습관으로 취급하여 하나를 삭제해도 전부 삭제하기 위해 사용되어지고 있다.(권한의 경우도 동일하다.)
    • 뱃지 로직에도 사용되고 있는데 목표 날짜까지 지키기 위한 습관은 일수 , 습관의 개수와 상관없이 하나로 판단하여 검증하기 위해 사용되어지고 있다.
  • privateCheck 습관의 경우 친구와 상호작용하여 표출시키게 되는데 이 때 선택한 권한여부에 따라 true,false로 판단하여 Front에 응답하기 위해 식별하는 필드이자 DB에 등록할 컬럼이다.
    • 이후 뱃지 로직, 캘린더 페이지에서 습관 표출에 있어 검증의 경우 사용되고 있다.
  • time 하루 한 줌 서비스에서 습관의 달성 여부를 타이머 완료 여부로 설정하고 있어 각 습관마다 설정한 시간을 가지는 필드이자 DB에 등록할 컬럼이다.
    • 하루를 넘어가면 달성률 체크에 동일하게 체크할 수 없어 입력한 time별로 검증을 거쳐 예외처리를 발생시키기도 한다.
    • 이후 모든 습관 data를 front에 반환할때 time은 초도 생성한 뒤 string값으로 반환시킨다.(front와 약속한 형태로 반환 hh:mm:ss)
  • title 습관 생성 시 유저가 입력 한 습관의 제목이자 front에 응답할 data의 하나인 필드이자 DB에 등록할 컬럼이다.
`refreshtoken` 테이블
  • rt_key 토큰 재발급 시 db의 유저정보와 대조하기 위해 사용되는 pk값이며 유저의 고유한 socialId를 저장하여 사용하기 위한 필드이자 DB에 등록할 컬럼이다.
  • rt_value 토큰 생성 시 refreshtoken을 등록하며 이후 재발급에 사용하기 위해 front에 건네주기 위한 필드이자 DB에 등록할 컬럼이다.
    • 이후 토큰 재발급 시 Front에서 요청으로 건넨 refreshtoken과 검증하기 위해 사용되고 있다.
`deletedUrlPath` 테이블
  • deletedUrlPath 유저가 사진을 변경할 시 기존 유저가 저장했던 이미지의 URL을 담고있는 필드이자 DB에 등록할 컬럼이다.
    • 매번 유저가 사진을 변경할때 기존 사진을 매번 삭제하는 것은 성능을 저하시킨다고 판단했고 한번에 스케쥴러로 지우기 위해 사용되고 있다.
`friend` 테이블
  • followerid 친구 검색 이후 팔로잉을 선택할 당시 친구의 socialId를 넣어 친구를 기점으로 내가 팔로잉 하는 것이기 때문에 follower에 등록하는 필드이자 DB에 등록할 컬럼이다.
  • followingid 친구 검색 이후 팔로잉을 선택할 당시 자신의 socialId를 넣어 친구를 기점으로 내가 팔로잉 하는 것이기 때문에 following에 자신의 정보를 넣는 필드이자 DB에 등록할 컬럼이다.

테이블간 관계 설정

  • 1:1 관계 (member-image)

    • 유저가 회원가입 할 당시 소셜로그인에서 메인 사진을 가져와 하나씩 생성하게 되지만 이후 서비스가 유지보수 함에 따라 여러개의 image를 가질 수 있다고 생각했다.
      • 유지보수를 원활히 하기 위해 초기 설계 당시 양방향관계를 설정하여 N으로 변할 수 있는 image를 1:1 양방향 관계로 설정하였다.

  • 1:N 관계(member-goal)

    • 한 유저는 습관을 여러개 생성할 수 있어 N관계로 관리되며 이후 서비스 로직에서 양방향 관계로 되어있을 경우 관리가 편할 거라 판단되어 설정했다.
    • 지연로딩으로 설정하여 성능 최적화를 이뤄냈고 이후 member,goal에서 연관된 데이터를 조회하여 사용하고있다.

  • 1:N 관계(member-badge)

    • 한 유저는 뱃지를 여러개 가질 수 있어 N관계로 관리되며 이후 서비스 로직에서 양방향 관계로 되어있을 경우 관리가 편할 거라 판단되어 설정했다.
    • 지연로딩으로 설정하여 성능 최적화를 이뤄냈고 이후 member,badge에서 연관된 데이터를 조회하여 사용하고있다.

  • 1:N 관계(goal-heart)

    • 한 습관은 좋아요를 여러개 가질 수 있어 N관계로 관리되며 이후 서비스 로직에서 양방향 관계로 되어있을 경우 관리가 편할 거라 판단되어 설정했다.
    • 지연로딩으로 설정하여 성능 최적화를 이뤄냈고 이후 goal,heart에서 연관된 데이터를 조회하여 사용하고있다.

  • 1:N 관계(goal-comment)

    • 한 습관은 댓글을 여러개 가질 수 있어 N관계로 관리되며 이후 서비스 로직에서 양방향 관계로 되어있을 경우 관리가 편할 거라 판단되어 설정했다.
    • 지연로딩으로 설정하여 성능 최적화를 이뤄냈고 이후 goal,comment에서 연관된 데이터를 조회하여 사용하고있다.

  • N:1 관계(comment-member)

    • 다수의 댓글은 한 작성자에 귀속되며 N:1관계로 설정하여 주입하는 것이 관리가 편할 거라 판단되어 설정했다.
    • 지연로딩을 설정하여 성능 최적화를 이뤄냈고 이후 comment에서 연관된 데이터를 조회하여 사용하고있다.

Clone this wiki locally