들어가기 전
업무 요건을 파악하고 데이터 모델링을 통해 테이블을 도출한 뒤, JPA를 활용하기 위해 테이블을 JPA 엔티티로 맵핑시켜보자.
업무 요건 정의
구현해야할 기능 관점에서 업무 요건을 정리해보았다.
회원 관리
- 로그인
- 최초 로그인시 회원등록 및 다음 사항 기입 권유
- 결혼 날짜 등록 (선택)
- 최대 예산 범위 설정 (선택)
가계(지출/수입) 관리
- 지출 및 수입 등록, 수정, 삭제
- 원하는 기간 내의 지출/수입 내역을 엑셀파일로 다운받을 수 있다.
- 예비 지출(지출 등록 날짜가 오늘 날짜보다 이후인 경우)에 대해 다음 날짜 0시를 기준으로 이미 지출된 항목으로 변경한다.
일정 관리
- 일정 등록, 수정, 삭제
- 일정과 관련하여 사용자가 지정해놓은 날 사용자에게 알림이 간다.
- 일정 내에서 발생하는 지출에 대해 복수로 등록할 수 있다.
- 등록한 일정이 캘린더에 맵핑된다.
데이터 모델링
개념 모델링
- 회원이 반드시 있어야 지출, 일정이 있다.
- 한 명의 회원이 여러 번의 지출을 할 수 있으며, 여러 개의 일정이 있을 수 있다.
- 지출과 일정이 없을 수도 있다.
- 하나의 일정에 대해 지출이 없거나, 여러 번의 지출이 있을 수 있다.
- 드레스 투어(일정) - 피팅 비용 + 가계약 비용 + 발렛 파킹 비용 등
- 회원이 일정에 대해 알림을 신청해 놓는 경우 일정 알림에 추가된다.
- 알림을 여러 번 받기 원할 수도 있기 때문에 1:N 관계로 구성
- 추후 운영의 관점에서 생각했을 때, 알림에 대한 정상 처리 여부 등을 확인하기 위해 이력을 관리하는게 좋을 것 같다고 판단하여 일정 알림 이력 엔터티 추가.
논리 모델링
모델링 과정에서의 의식의 흐름..
email로 사용자를 식별하는 것의 타당성 ?- 물론 식별은 되지만, 추후에 OAuth가 아니라 다른 방식으로 로그인하게 되면 꼭 email이 아니게 될 수 있으므로 email 대신 user_id가 나을 것 같다.
- 일정에 ‘전체 지출’ 컬럼이 추가되는게 나을까 아니면 지출 테이블에 조인걸어서 가져오는게 나을까 ?
- JOIN 거는 것 보다는 테이블 내에서 가져올 수 있으면 좋을 것 같다.
- 페이백, 포인트 적립 등도 고려해야 하기 때문에 지출 대신 다른 엔터티 이름이 필요할 것 같다 !
- 수입/지출 내역 관리를 어떤 단어로 표현하면 좋을까 ?
- 계좌라는 의미로 많이 쓰이지만, ‘가계’라는 뜻도 가진 account 정도면 괜찮을 것 같다.
- expense, income을 따로 두는게 좋을까 ?
- 사실 지출에 비해 수입은 거의 없을 것이라고 생각하기 때문에, 굳이 테이블을 두 개로 나누지 말고 type으로 구분하면 될 것 같다.
- 일정과 관련없는 지출/수입이 있을 수 있다. (스드메 예약 비용, 페이백 등)
참고. 엔터티 간 관계에서 선 구분
- 점선 : 비식별 관계 (부모 엔터티의 식별자가 없어도 자식 엔터티의 레코드 생성 가능)
- 선 : 식별 관계 (부모의 식별자가 자식 엔터티의 레코드를 식별하는데 꼭 필요)
JPA 엔티티 설계와 맵핑
느낀점
엔터티의 이름, 속성 및 엔터티 간의 관계는 적절한지 등에 대해 먼저 생각해봄으로써, 애플리케이션을 제작하면서 고치려면 번거로울 수 있었던 것들을 미리 파악하고 정리할 수 있었던 것 같다. 또한 업무 요건이 상세하게 정의될수록 추후에 변경이 적은 테이블 설계가 가능할 것 같다.
더 공부해야할 부분
- 효율적인 쿼리 짜는 방법 (JOIN 사용할 때 성능에 미치는 영향 등)