회의 정보

  • 주제 : 데이터베이스 구조 설계
  • 일시 : 2024.07.31, 13:00 ~ 14:30
  • 장소 : 비대면
  • 참여자 : 조장 신동현, 조원 석종수, 이승언, 조석원 (4명)


회의 안건

  1. 데이터베이스 구조 설계 해보기


회의 내용

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) 데이터베이스 다이어그램 그리기

위의 내용을 바탕으로 그림을 그린다. 종수님이 맡아주셨다, 계속 수정중. KakaoTalk_20240806_143058077


흐름 메모

우리 모두 데이터베이스 설계를 처음 해봐서 확실하지 않은 부분이 꽤 있었다. 그래도 요구사항 도출 > 테이블과 속성 목록 생성 > 도형으로 표현의 과정을 밟으려고 노력했다.
우리가 원하는 앱의 기능과 모습을 이미 정해놨기에 요구사항 도출은 어렵지 않았다. 하지만 그 과정에서 우리가 기존에 만든 앱의 모습에 오류를 몇 개 발견하긴 했다. 예를 들어 메모나 캘린더 일정의 삭제 버튼이 없어서 삭제할 방법이 없다. 그룹 일정을 생성자만 삭제할 수 있는지, 그룹의 모두가 삭제할 수 있는지도 정했다. 이건 기존에 생성자만 삭제할 수 있는 걸로 내가 임의로 정했지만 모두 삭제하는 쪽으로 합의했다.
테이블 생성 과정에서는 약간의 혼란이 생겼었다. 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 모바일앱개발조합 회의 참석 (멘토님, 디자이너님, 팀원)
    • 앱 외형에 대한 추가 피드백 및 수정사항 전달
    • 지금까지 과정에 대한 피드백
    • 아키텍쳐 디자인 도움 요청

댓글남기기