M:N 관계의 연관 엔티티 설계 순서

Question

이런 식으로 실무적으로 접근했을 때 이 강의에서 예시를 들어주셨던 것처럼 (학생, 과목, 수강), (사용자, 영화, 평가) 엔티티를 개념적 모델링 단계에서 먼저 설계를 할텐데, 이때 설계 순서가 궁금합니다.   (학생, 과목), (사용자, 영화) 와 같은 기본 엔티티를 먼저 만든 다음에 M:N 다대다 관계인 것을 확인하고 이것을 풀어내면서 동시에 비즈니스적 의미를 넣기 위해 중심(연관) 엔티티를 만드는 게 일반적인가요? 아니면 처음부터 학생 -> 수강 -> 과목 or 사용자 -> 평가 -> 영화 로 이어지도록 설계하는 게 일반적인가요?

David · Answer

안녕하세요. 박동규님, 공식 서포터즈 David입니다. 제 개인적인 경험에 빗대어보면, 도메인과 요구사항이 익숙하다면 연관 엔터티를 포함하여 설계할 수 있으나 그렇지 않다면 엔터티 간 관계를 생각하며 설계하는 과정에 연관 엔터티가 추가됩니다. 감사합니다.

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 박동규님. 다대다(M:N) 관계를 처리하는 방법은 데이터를 어떻게 관리하고 조회할 것인지에 따라 다르게 접근할 수 있습니다. 보통 실무에서는 아래 두 가지 방법 중 하나를 선택하게 됩니다: 기본 엔티티 먼저 설계 후 중심(연관) 엔티티 생성 : 먼저 학생과 과목, 사용자와 영화 같이 기본 엔티티를 설계한 후, 이들 간의 M:N 관계를 확인합니다. 그런 다음, 비즈니스적인 의미를 담은 중심 엔티티(예: 수강, 평가)를 추가하여 이를 해소합니다. 이는 더 직관적이고 쉽게 접근할 수 있는 방법이며 설계의 유연성을 제공합니다. 처음부터 중심(연관) 엔티티와 함께 설계 : 초기 설계단계에서부터 학생 -> 수강 -> 과목, 사용자 -> 평가 -> 영화와 같이 중심 엔티티를 염두에 두고 설계하는 방법입니다. 이 접근은 초기 설계 단계에서 명확한 비즈니스 로직을 기반으로 할 때 용이하지만, 추후 변경이나 확장이 필요할 경우 어려울 수 있습니다. 각 방법은 사용자의 요구 사항, 데이터 처리 방식, 시스템 요구와 제약 사항에 따라 선택하게 됩니다. 실무에서는 요구 사항을 기반으로 두 방법을 혼합하여 사용하는 경우도 많습니다. 좀 더 깊이 있는 내용을 원하신다면, 다음의 유사한 질문과 답변 내용을 참고해 보세요: 주문과 배송의 1:1 관계가 아닌 1:N 관계의 요구사항에 대해 여쭙습니다. 다대다 관계 매핑 설계에 대해 질문드립니다! 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.