캡스톤 디자인 PART.DB 모델링 변경사항

서론

캡스톤을 진행할 때 설계를 모두 마치고 구현을 하던 도중 처음에 설계했던 ERD 모델에서 변경되었던 부분을 기록합니다.

 

본론

- 학생과 졸업

처음에는 졸업 신청과 학생을 1:n 관계로 설계했었습니다. 1명의 학생이 1번의 졸업을 하고 졸업은 여러 명의 학생에게 신청 받을 수 있기 때문에 이렇게 설계했었습니다.

 

디벨롭 전 학과 홈페이지

하지만 졸업을 신청할 때 여러가지 단계가 존재하였습니다. 예를 들어 한 명의 학생이 졸업을 하기 위해서는 신청서를 제출하고 > 제안서를 제출하고 > 중간보고서를 제출하고 > 최종 보고서를 제출해야 하며 이 모든 단계가 졸업 신청의 요소로 들어가야 했습니다.

 

그러면 이를 어떻게 ERD에 적용해야 할까요? ✅

이렇게 되면 한 명의 학생이 1번의 신청을 하는 것이 아닌 여러번의 신청을 하게 되어 M:N 관계가 됩니다. 중간 매핑 테이블에 학생 키와 졸업 신청 키를 넣어서 어떤 학생이 어떤 신청을 했는지 목록화하게 하면 됩니다.

 

그럼 이제 신청한 폼들을 저장할 테이블이 필요합니다. 각 테이블에 저장될 데이터는 학생이 졸업 신청을 할 때 제출할 폼에 있는 항목들입니다. 

 

매핑 테이블과 폼 테이블을 연결할 방법이 필요한데, 그것을 위해 먼저 매핑 테이블의 키였던 (학생 키 + 졸업 신청 키)를 pk로 하지 말고 apply_id라는 유일한 pk를 만들었습니다. 

 

그러면 이 키를 폼 테이블들이 가지는게 좋을까요? 아니면 폼 테이블 들의 키를 매핑 테이블이 가지는게 좋을까요?✅

 

신청 폼과 졸업 목록의 관계를 봤을 때 1대 1 같기도 하고 폼이 N, 졸업이 1인 거 같기도 해서 확실치가 않았지만 학생에 폼 id가 들어가는 것 보단 폼에 졸업 신청 id가 들어가는게 맞다고 판단되어 폼 테이블에 apply_id를 넣었습니다.

 

결론

개발을 진행하면서 여러가지 변경 사항들이 발생했습니다. 이는 초반에 요구사항과 설계를 제대로 하지 못 한 문제점에서 발생했다고 생각합니다. 역시 좋은 설계가 좋은 결과물을 만듬을 실감합니다.