[프로젝트 기획 및 준비작업] 기능 플로우,DB schema

첫번째 프로젝트인 SAFU를 끝내면서 Final 프로젝트때에는 처음부터 이것들을 꼭 지켜봐야지 라고 생각하며 정리해 둔 글(아래 링크)이 있었다.

10. Final Project 때는... 이렇게 더 보충해 봐야지

 

그 중 첫 번째 프로젝트때 가장 손 가는 부분이 많았으며 커뮤니케이션이 가장 많이 이루어진 부분이 DB schema와 API이었고, 이 둘은 정말 프로젝트 진행 중에도 몇 번이나 수정된다는 것을 알고 있었기에 이번에는 처음부터 훨씬 더 꼼꼼하게 짜야겠다는 생각이 있었다. 

 

이 글은 <프로젝트 기획 및 준비작업> 시기에 해당하는 주에 짠 DB schema, API 기획과  이후 피드백 및 프로젝트 진행 중 깨달은 점을 바탕으로 수정된 사항들을 포함하고 있다. 

1. 기능 플로우

초기 기획된 기능 플로우는 <더보기>를 클릭하면 볼 수 있다. (팀원이 다같이 모여 기능플로우를 짠 것을 HJ님께서 깔끔하게 정리해주셨다.)

프로젝트가 진행되면서 개인정보 관리에 해당하는 Mypage가 추가되고, 알람 삭제시에도 당일 알람 하나만 삭제 할 것인지 전체 알람을 삭제 할 것인지 물어보는 등.. 다양한 기능이 생겼지만 

 

변하지 않는 주 기능은 

📷 쉽고 빠른 복약 정보 제공 및 관리

• 촬영 한 번으로 약의 정보를 찾음
• 공공데이터를 활용하여 복약정보를 쉽고 빠르게 제공
• 촬영된 이미지 및 간단한 메모로 복용하는 약을 편하게 관리

⏰ 복용 일정 등록 및 관리

• 등록한 일정이 다가오면 예약된 푸시가 발송되어 세세한 일정 관리 가능
• 캘린더를 통한 전반적인 일정 관리 가능
• 복용여부에 따라, 각 일정의 색을 다르게 하여 편리하게 관리 가능

이다. 그리고 최종 기능 플로우는 아래와 같다. (SH님께서 정리해주셨다. 정말 감사해요👏🏻)

 

 

2. DB schema

위의 기능 플로우를 참고하여서 가장 커뮤니케이션이 많이 이루어져야 하는 부분 중 하나이다. 

초기 기획된 DB schema는 아래와 같다. 

schedules_date와 schedules_common으로 나눈 이유는 알람의 특성상 '주기' 가 있기 때문에 울리는 날짜만 다르고 나머지 정보는 중복이 가능하다. 그러므로 중복될 수 있는 정보에 해당하는 알람의 title, memo, 알람을 설정한 유저, 해당 알람의 주기 계산에 필요한 알람 시작 날짜, 끝 날짜, 주기 등을 schedules_common의 필드로 정했고, 각 알람 당 고유 정보에 해당하는 것들은 schedules_date의필들로 정했다.

 

※ schedules_date에 year, month, date 필드가 있는 이유는, 처음에 '달력'기능을 구현하기 위해서는 몇 년치의 날짜 정보를 우리 DB내에 가지고 있어야 한다고 잘 못 알았기 때문이다.ㅎㅎ 이후에 달력 기능은 라이브러리를 통해서 구현하며, 절대 이 모든 날짜 데이터를 다 가지고 있을 필요가 없다는 것을 알게 되었다. 뿐만 아니라 날짜 계산시에도 불편함이 이만저만이 아니어서 결국 이 부분은 수정되었다. 

이에 대한 내용은 [Server] Get Monthly Checked API_String type to Date type (Dec 7, 2020회고)여기에 정리해둔 바 있다. 

 

그리고 관계성은 

• user 1 - schedule_date n (schedules_udate)
• user 1 - schedule_common n (schedules_ucommon)
• schedule_common 1 - schedule_date n(schedules_codate)
• schedule_common n - medicine n
• user n - medicine n

이렇게 된다. 

 

이후 수정된 최종 DB 스키마는 아래와 같다.