어린이들을 위한 가계부 웹 어플리케이션 개발
FE 개발자가 없어서 좀 걱정을 했었는데 다행히 바라던 FE 개발자가 구해졌다! 나도 아는 동생이고, 처음에 같이 시작한 동생과도 아는 사이였기 때문에 편하고 즐겁게 개발할 수 있을 것 같다.🥰
이로써 우리의 팀은 디자이너1, 프론트1, 백1의 3인 체제가 되었다.
이제 화이팅해보자!
DB 설계
데이터베이스 설계와 API 명세서 작성
팀원들과 어떤 서비스를 개발할건지 웹 앱의 주제에 대한 부분을 기획했다. 그리고 기능들을 구체화하는 작업을 거쳤다. 논의한 내용을 토대로 Back 단에서는 DB와 API 구조를 설계하는 것이 우선순위가 될것이다. 특히, 데이터베이스를 모델링하는것은 나중에 쿼리문을 작성하거나 웹 앱의 시스템 구조를 파악하는데 있어서 근간이 되는 것이기 때문에 필수적이다.
DB 설계는 다음의 순서로 진행하였다.
- 요구사항 분석
- 개념적 설계 (ERD)
- 논리적 설계 (릴레이션 스키마)
- (물리적 설계) -> 개발 착수하면서 진행할 예정
1. 요구사항 분석
요구사항 분석이라함은 '데이터베이스에 대한 사용자들의 요구 사항을 수집하고 분석하여, 개발할 데이터베이스의 용도를 명확히 파악하는 것' 을 말한다.
쉽게 말해, 사용자들이 어떤 기능을 우리 웹 앱에 요구하는지를 파악하고, 각 내용을 정리해서 문서화하는 것이다. 이렇게 정리하면 실제 개발에 들어갔을 때, 어떤 부분을 개발해야할지 쉽게 알아볼 수 있다.
요구사항으로 봤을 때, 우리의 앱은 크게 4가지의 기능으로 동작할 것으로 보인다.
- 메인
- 용돈노트 (가계부 기능 & 내역 조회)
- 저금통 (저금을 도와주는 기능)
- 경제교실 (경제 관련 아티클 보여주는 기능. 아직 미완)
2. 개념적 설계
흔히, ERD라고 하는 개념적 데이터 모델을 설계하는 단계이다. 사실 학부생때 데이터베이스 과목을 공부하면서 많이 그려보고 설계했던 기억이 나는데, 기억속의 저편으로 사라지면서 다시금 공부해야했다.
요구사항 분석을 보면서 그려보았다. 아직 미완의 기능들이 있어서 부족한 부분들이 있지만 나름 잘 완성한 것 같다. (사실 맞게 그렸는지는 확실치 않음😅)
특이한 건, 용돈정보에 대한 Entity이다. 우리의 앱은 회원들로 하여금 용돈주기, 용돈액수, 카테고리와 같은 용돈에 관한 정보를 따로 받을 생각이다. 이는 앱에서 자동으로 특정날짜가 되면 용돈정보를 기입해주는 기능을 구현하기 위함이다. 이를 위해 용돈 정보 Entity는 따로 만들었다.
한 가지 고민인건 가계부 분석 Entity가 상당히 애매하다는 것이다. 여러 개의 가계부를 통해 파생되는 엔티티인데 가계부 분석은 차트형태(원, 막대) 와 지출 순위가 보여지고 그에 따른 피드백이 보여지는 형식인데 지출 순위 같은 경우는 계산된 필드이기 때문이다. 계산된 필드는 계산에 참여하는 필드의 값이 바뀔 때 갱신되지 않고, 이러한 갱신 작업의 책임이 응용프로그램으로 넘겨지기 때문에 피하는 것이 좋다고 되어있는데... 일단은 작성해보았다.
이후, Peter-Chen 표기법으로 나타냈던 ERD를 IE 표기법으로 다시 나타내주었다. 차수(Cardinality) 가 정확한지는 모르겠지만 각 엔티티마다 서로 어떤 연관관계를 맺고 있는지 알수 있었다.
3. 논리적 설계
ER 모델이 나왔다면 이를 통해 테이블 스키마를 만들어야한다. 그러나, ERD와 관계형 데이터베이스는 구조를 설계하는 방식과 규칙이 다르다. (패러다임 불일치) 따라서 릴레이션 스키마를 먼저 만들고 이를 참조하여 테이블 스키마를 만드는 순서를 따라야 했다. 릴레이션 스키마도 변환하는 규칙이 있기 때문에 이를 공부하면서 만들어야했다.
아직 테이블 스키마와 릴레이션 스키마가 완성이 덜 된 상태다.
팀프로젝트가 처음이다보니 요구사항을 분석하고 DB를 설계하는 일련의 과정들이 어색했지만 그동안 소홀히했던 DB 관련 내용들을 다시 공부할 수 있어서 좋았다.
팀원들과 소통하면서 Task를 정리하면서 벌써 많은 작업들을 하고 있다는 것을 느낀다.
아직 개발단계에 들어서지는 않았지만 천리길도 한걸음부터 차근차근 화이팅!
