M:N 관계의 연관 엔티티 설계 순서
67
15 asked
이런 식으로 실무적으로 접근했을 때 이 강의에서 예시를 들어주셨던 것처럼 (학생, 과목, 수강), (사용자, 영화, 평가) 엔티티를 개념적 모델링 단계에서 먼저 설계를 할텐데, 이때 설계 순서가 궁금합니다.
(학생, 과목), (사용자, 영화) 와 같은 기본 엔티티를 먼저 만든 다음에 M:N 다대다 관계인 것을 확인하고 이것을 풀어내면서 동시에 비즈니스적 의미를 넣기 위해 중심(연관) 엔티티를 만드는 게 일반적인가요? 아니면 처음부터 학생 -> 수강 -> 과목 or 사용자 -> 평가 -> 영화 로 이어지도록 설계하는 게 일반적인가요?
Answer 2
0
안녕하세요. 박동규님, 공식 서포터즈 David입니다.
제 개인적인 경험에 빗대어보면, 도메인과 요구사항이 익숙하다면 연관 엔터티를 포함하여 설계할 수 있으나 그렇지 않다면 엔터티 간 관계를 생각하며 설계하는 과정에 연관 엔터티가 추가됩니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 박동규님.
다대다(M:N) 관계를 처리하는 방법은 데이터를 어떻게 관리하고 조회할 것인지에 따라 다르게 접근할 수 있습니다. 보통 실무에서는 아래 두 가지 방법 중 하나를 선택하게 됩니다:
기본 엔티티 먼저 설계 후 중심(연관) 엔티티 생성: 먼저 학생과 과목, 사용자와 영화 같이 기본 엔티티를 설계한 후, 이들 간의 M:N 관계를 확인합니다. 그런 다음, 비즈니스적인 의미를 담은 중심 엔티티(예: 수강, 평가)를 추가하여 이를 해소합니다. 이는 더 직관적이고 쉽게 접근할 수 있는 방법이며 설계의 유연성을 제공합니다.
처음부터 중심(연관) 엔티티와 함께 설계: 초기 설계단계에서부터 학생 -> 수강 -> 과목, 사용자 -> 평가 -> 영화와 같이 중심 엔티티를 염두에 두고 설계하는 방법입니다. 이 접근은 초기 설계 단계에서 명확한 비즈니스 로직을 기반으로 할 때 용이하지만, 추후 변경이나 확장이 필요할 경우 어려울 수 있습니다.
각 방법은 사용자의 요구 사항, 데이터 처리 방식, 시스템 요구와 제약 사항에 따라 선택하게 됩니다. 실무에서는 요구 사항을 기반으로 두 방법을 혼합하여 사용하는 경우도 많습니다.
좀 더 깊이 있는 내용을 원하신다면, 다음의 유사한 질문과 답변 내용을 참고해 보세요:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
BCNF 질문
0
49
2
연관 엔티티 네이밍 규칙
0
40
1
진짜 강의 듣는거 너무 고문
0
114
1
28강 sql 파일 어딨나여?
0
79
1
2NF의 엄밀한 정의
0
66
1
comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
0
104
3
학습중인 수업자료를 받아볼 수 있을까요??
0
92
2
수업자료 pdf파일관련 건의 - 제목 링크위치 개선
0
79
2
서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문
1
96
2
실무적인 설계로 접근했을 때 제 2정규형 항상 만족?
0
71
1
슈퍼/서브 타입 joined 전략
0
64
2
created_at 관련 구현과 DB ENUM에 대해
0
64
1
데이터 역사성 훼손 문제
0
60
2
실무팁 - 등록자,수정자 컬럼 관리 관련 질문입니다.
0
78
1
구글이 이메일 변경을 허용하는 이유
0
117
1
order_item 테이블 (order_id, product_id) 유니크 제약조건 누락
0
97
2
BCNF 정규화에 대한 질문
0
117
2
주문, 결제 엔티티의 분류
1
113
1
실무에서의 복수 항목에 대한 관리 방법이 궁금합니다.
0
86
1
역할 및 발생 시점에 따른 엔티티 분류
0
82
1
대리키의 외부 노출에 대한 질문을 하고 싶습니다.
0
104
2
소프트 딜리트 정책에서 유니크 컬럼 중복 방지 전략
0
91
1
대리키 사용과 정규화
1
106
2
강의자료 까마귀발 잘못된거 아닌가요?
1
125
2