ERD 설계 과정

TripDream 프로젝트를 시작하고 DB구조를 짜는 것이 먼저라고 판단이 들었다.

ERD를 설계해보려 한다.

 

기능 정의서는 다음과 같다.

https://www.notion.so/8e62f0fe168245a28c20576c9bbd2894?pvs=4

기능 정의

 

기능별 요구사항에 맞춰 ERD를 설계해볼 예정이다.

 

회원가입

먼저 회원정보 테이블이 필요하다.

MEMBER 테이블을 생성.

안에 회원가입 시 받고싶은 정보를 필수/선택을 기준으로 NULL, NOTNULL로 정했다.

회원 테이블의 PK값은 유일무이하고 특별한 값으로 하고 싶어 uuid 자동생성으로 정했다.

 

또한 row의 생성시간, 수정시간은 모든 테이블에서 받을 예정이다.

추후 접속자의 ip도 받을 설정이 완료되면 생성ip, 수정ip 컬럼 추가 예정이다.

이는 모든 테이블에 넣을 값이기에 별도의 클래스로 생성해 상속시킬 것이다.

 

회의 중에 회원가입 시에 프로필 이미지를 저장할 수 있게 하자는 의견이 나왔다.

이미지 테이블도 만들어 회원과 1:1 (회원 : 이미지)로 설계했다.

(프로필 이미지는 자원 소모의 이유로 하나만 저장할 수 있도록 한다.)

 

 

로그인

로그인을 하기위해서는 회원가입 시 저장된 회원테이블에 대한 조회와 

회원 토큰을 저장할 테이블이 필요하다.

 

로그인은 JWT 방식을 선택해 구현할 예정이다.

왜 JWT를 선택했는지는 추후 다른 게시글에 작성하겠다.

 

MEMBER_TOKEN 테이블을 생성했다. 

JWT를 안정적으로 구현하기 위해서는 

만료시간이 짧은 ACCESS_TOKEN, ACCESS_TOKEN을 연장시키는 용도인 REFRESH_TOKEN이 기본적으로 필요하다.

카테고리의 목적은 추후 소셜로그인까지 확장했을 때를 위함이다.

소셜로그인 API호출은 ACCESS_TOKEN과 REFRESH_TOKEN을 반환값에 넣어주고 이를 활용하기 때문이다.

자체적인 카테고리값은 TRIPDREAM, 네이버는 NAVER, 카카오는 KAKAO를 넣는 식으로 구현할 예정이다.

 

 

여행계획

계획에도 마찬가지로 원하는 내용들을 넣었다.

표 형태까지 저장해야하는 의문이 아직 있지만 일단 넣어두었다.

추후 변경될 수 있다.

 

동행 부분도 고민이 많이 됐는데 

계획에 0...1의 관계를 가져 혼자 여행일 수도 있고 함께하는 여행일 수도 있게 했다.

동행 테이블은 회원 테이블을 단방향으로 1:N 참조해 추후 리스트 형태로 뽑아쓸 수 있도록 설계했다.

 

예산관리

장소별 예산으로 관리하는 것이 가장 효율적이라고 생각이 됐다.

각 장소별로 예산이 존재하되 기본값은 0으로 해 추후 합산 시에 값을 포함시키지 않도록 했다.

카테고리는 항공, 숙박, 음식, 교통 등을 넣을 수 있을 듯 하다.

 

 

아래는 최종본이다.

일단 전부 단방향 매핑으로 설계했다.

정말 필요시에만 양방향 매핑으로 변경 예정이다.

(무한 참조 등의 예외 발생이 쉽기 때문이다.)

 

ERDCLOUD사이트는 1:1 매핑 시에 대상테이블이 외래키를 가지고 있는 형태로 된다.

하지만 나는 JPA를 사용할 것이기 때문에 주테이블이 외래키를 가지는 형태로 설계할 것이다.

외래키에 NULL값을 허용할 수 있는 위험성이 있지만, JPA매핑이 편리하다는 편의성이 있다.

(객체 자체로 컬럼에 들어가있는 듯 보이기 때문)