[미래일경험 프로젝트] 비공식 4회차 : 데이터베이스 구조 설계
회의 정보
- 주제 : 데이터베이스 구조 설계
- 일시 : 2024.07.31, 13:00 ~ 14:30
- 장소 : 비대면
- 참여자 : 조장 신동현, 조원 석종수, 이승언, 조석원 (4명)
회의 안건
- 데이터베이스 구조 설계 해보기
회의 내용
1. 데이터베이스 구조 설계 해보기
1) 요구사항 정리
일단 우리 앱의 기능을 정리해본다.
- 사용자는 구글 계정과 연동되어 있는 자신만의 id와 자신이 직접 만들 수 있는 닉네임 정보를 가진다
- 사용자는 두 가지의 기능을 사용할 수 있는데 메모장과 캘린더이다.
- 메모장은 제목과 메모 내용 정보를 가진다.
- 캘린더는 개인 캘린더와 그룹 캘린더로 나뉜다. (앱상에서는 하나의 달력에 보여줄 거지만 데이터베이스상에선 별개다.)
- 개인 캘린더는 날짜 정보와 해당 날짜에 수행해야 할 일에 대한 정보, 해당 날짜에 수행해야 할 일을 수행했는지에 대한 여부를 나타내는 정보를 가진다.
- 그룹 캘린더는 사용자가 속해 있는 그룹의 정보와 날짜 정보, 해당 날짜에 수행해야 할 일, 해당 날짜에 수행해야 할 일을 수행했는지에 대한 여부를 나타내는 정보를 가진다.
- 각 일정엔 알림과 관련된 정보가 있다.
2) 데이터베이스 테이블 설계
위의 요구 사항과, 지금 우리가 가지고 있는 앱의 외형을 기반으로 데이터베이스엔 어떤 테이블과 데이터가 필요할지 구상해본다.
User (사용자)
- user_id (PK): 사용자의 고유 ID (구글 계정 연동 ID)
- nickname: 닉네임
Memo (메모장)
- memo_id (PK): 메모의 고유 ID
- user_id (FK): 사용자의 고유 ID
- title: 제목
- content: 메모 내용
CalendarEvent (일정)
- event_id (PK): 일정의 고유 ID
- date: 날짜
- task: 수행해야 할 일
- start_time: 일정 시작 시간
- end_time: 일정 종료 시간
- notification: 알림 정보
- repeat: 알림 반복 정보
- is_completed: 수행 여부
PersonalCalendar (개인 캘린더)
- personal_calendar_id (PK): 개인 캘린더 항목의 고유 ID
- user_id (FK): 사용자의 고유 ID
- event_id (FK): 일정의 고유 ID
Group (그룹)
- group_id (PK): 그룹의 고유 ID
- group_name: 그룹 이름
UserGroup (사용자-그룹)
- user_group_id (PK): 사용자-그룹 관계의 고유 ID
- user_id (FK): 사용자의 고유 ID
- group_id (FK): 그룹의 고유 ID
GroupCalendar (그룹 캘린더)
- group_calendar_id (PK): 그룹 캘린더 항목의 고유 ID
- group_id (FK): 그룹의 고유 ID
- event_id (FK): 일정의 고유 ID
- is_public: 그룹 일정 표시 여부
3) 데이터베이스 다이어그램 그리기
위의 내용을 바탕으로 그림을 그린다. 종수님이 맡아주셨다, 계속 수정중.
흐름 메모
우리 모두 데이터베이스 설계를 처음 해봐서 확실하지 않은 부분이 꽤 있었다. 그래도 요구사항 도출 > 테이블과 속성 목록 생성 > 도형으로 표현의 과정을 밟으려고 노력했다.
우리가 원하는 앱의 기능과 모습을 이미 정해놨기에 요구사항 도출은 어렵지 않았다. 하지만 그 과정에서 우리가 기존에 만든 앱의 모습에 오류를 몇 개 발견하긴 했다. 예를 들어 메모나 캘린더 일정의 삭제 버튼이 없어서 삭제할 방법이 없다. 그룹 일정을 생성자만 삭제할 수 있는지, 그룹의 모두가 삭제할 수 있는지도 정했다. 이건 기존에 생성자만 삭제할 수 있는 걸로 내가 임의로 정했지만 모두 삭제하는 쪽으로 합의했다.
테이블 생성 과정에서는 약간의 혼란이 생겼었다. UserGroup 테이블의 기본키로 사용하는 user_group_id가 꼭 필요한 값인가에 대한 혼란이 있었다. 내 답은 당연히 필요하다는 거다. 한 사람이 여러 그룹에 있는 경우 user_id 속성은 중복가능하며, 한 그룹에 사람이 여러 명인 경우 groupd_id 속성도 중복되게 된다. 그렇기에 각 데이터를 유일하게 구분해줄 속성이 없고, 그 역할을 해줄 user_group_id가 필요하다. 이건 auto increment로 처리하면 될 거라고 생각된다.
기본키를 인조키로 하냐 자연키로 하냐의 문제라고 생각해서 해결에 시간이 더 걸렸다. 내가 헷갈렸는데, user_group_id가 인조키, user_id가 자연키의 예시라고 생각했다. 하지만 user_id는 중복가능하기 때문에 자연키의 예시가 아니다. 참고로 자연키는 원래 해당 테이블에 있는 속성을 기본키로 쓰는 거고, 인조키는 인위적으로 데이터 구분만을 위한 속성을 추가해서 기본키로 쓰는 거다. 즉 user_group_id는 인조키가 맞다.
이후 할 일
- 데이터베이스 다이어그램 수정
- 2024.8.8, 16:00 모바일앱개발조합 회의 참석 (멘토님, 디자이너님, 팀원)
- 앱 외형에 대한 추가 피드백 및 수정사항 전달
- 지금까지 과정에 대한 피드백
- 아키텍쳐 디자인 도움 요청
댓글남기기