카디널리티를 적용한 ERM 초안 수정

1. 1:1 관계

체크항목	설명	이유
1. 어떤 테이블에 FK를 넣을지 결정했는가?	1:1 관계에서는 한쪽 또는 양쪽에 Foreign Key(FK)를 넣어야 함	잘못 넣으면 NULL 값이 많아져 데이터 낭비 발생
2. 필수 관계인지 선택 관계인지 파악했는가?	(1)필수: 반드시 값이 있어야 함 → FK를 필수 엔터티에 넣음 (2)선택: 없어도 됨 → 선택 엔터티에 넣음	NULL 발생 여부와 모델의 정확성을 결정
3. NULL 최소화를 고려했는가?	FK를 어디에 넣을지 판단 시 NULL이 생기지 않는 방향으로 설계	NULL은 데이터 해석 혼란과 공간 낭비 초래
4. FK 조회 방향 확인	FK가 있는 테이블에서 다른 테이블의 데이터를 정확히 조회 가능한지 확인	FK 설계 오류 시 JOIN 시 혼동 발생

주의할 점

• 항목 1) Foreign Key(FK)는 "항상 존재해야 하는 데이터가 있는 쪽에 넣는다

FK를 넣는 기준

기준	FK를 넣을 위치	이유
항상 존재해야 하는 데이터	그 테이블에 FK 넣기	NULL이 생기지 않으므로 데이터가 항상 연결되어 있어 무결성 보장
없을 수도 있는 선택적 데이터	그 테이블에 FK 넣지 않기	NULL 값이 많이 생기면 공간 낭비와 데이터 해석 혼란 발생

---

2. 1:N 관계

체크 항목	설명	이유
1. 다수 쪽에 FK를 넣었는가?	1:N 관계는 항상 N(다수) 쪽에 FK를 추가	일(1) 쪽에 FK를 넣으면 컬럼 폭발(컬럼 무한 확장) 발생
2. FK로 양방향 조회가 가능한가?	- 특정 유저의 모든 리뷰 조회 가능- 특정 리뷰의 유저 조회 가능	데이터 추적과 JOIN 성능 확인
3. 관계의 방향을 명확히 파악했는가?	어떤 엔터티가 1이고, 어떤 엔터티가 N인지 비즈니스 룰로 정의	방향을 잘못 설정하면 설계 오류 및 데이터 무결성 깨짐
4. FK 명명 규칙 통일	user_id, review_id처럼 의미가 확실하게 드러나야 함	관리 용이성, JOIN 시 혼동 방지

 

---

3. M:N 관계

두 Entity 또는 테이블만 사용해서 자연스럽게 표현할 수 없기 때문에 연결 테이블을 사용한다

이 테이블에는 양쪽 Entity를 특정지을 수 있는FK 두개를 넣는다

이렇게 하면 각각의 테이블은 그대로 유지하면서 둘 사이 생기는 모든 관계를 저장하고 찾을 수 있다.

 

다대다 관계에 있는 두 Entity는 새로운 Entity와 두 개의 일대다 관계로 모델링한다

체크 항목	설명	이유
1. 중간 테이블(Junction Table)을 만들었는가?	M:N 관계를 직접 표현할 수 없으므로 중간 테이블 필수	M:N을 직접 FK로 연결 시 데이터 중복과 복잡성 폭발
2. 중간 테이블에 양쪽 FK를 넣었는가?	양쪽 엔터티를 연결할 수 있는 두 개의 FK 필요 예: user_id, product_id	관계의 정확한 매핑 보장
3. 중간 테이블의 PK 설계 확인	- 보통 두 FK를 묶어 복합 PK 생성 - 필요 시 별도의 surrogate key 추가	중복된 관계 데이터 방지
4. 관계 탐색 방향 확인	- 유저 → 찜한 상품 목록 - 상품 → 찜한 유저 목록	양방향 조회 가능 여부 확인
5. 비즈니스 룰로 관계 해석	엔터티와 관계 중 어떤 것을 Entity로 승격할지 판단	"찜하다" 같은 동사 관계가 Entity가 될 수도 있음

 

4. 공통 체크리스트

체크 항목	설명	이유
1. 비즈니스 룰 기반 모델링 여부	관계 방향과 카디널리티가 실제 서비스 규칙과 일치하는가	잘못된 모델은 실제 서비스와 불일치
2. FK 제약 조건 설정	FK에 ON DELETE, ON UPDATE 정책을 설정했는가	데이터 삭제/수정 시 무결성 보장
3. 성능 고려	FK가 JOIN 시 성능 문제를 일으키지 않는지 확인	대규모 데이터에서 성능 저하 방지
4. NULL 최소화	NULL 허용 여부를 명확히 결정	데이터 해석 혼란 및 공간 낭비 방지