ERD(Entity Relationship Diagram) - 2단계 학습(1)

1. 크로우즈 풋(Crow’s Foot) 표기법에서 1, N, 선택(○), 필수(｜) 는 각각 무엇을 의미하는가? (1이 결국 필수 라는 것일까?)
2. ERD에서 식별 관계(Identifying) 와 비식별 관계(Non-identifying) 는 어떻게 구분되며, 어떤 상황에서 각각을 사용하는가?
3. ERD 상에서 1:1, 1:N, N:M 관계는 어떻게 시각적으로 표현되는가?
4. ERD에서 N:M 관계를 직접 연결하면 문제가 되는 이유는 무엇인가?
5. N:M 관계를 풀어낼 때 사용하는 조인 테이블(Junction Table) 은 어떤 역할을 하는가?
6. 조인 테이블의 키 설계 방법에는 복합 PK와 대리키(예: id 컬럼) 가 있는데, 각각의 장단점은 무엇인가?
7. FK(Foreign Key)를 조인 테이블에 추가할 때, 네이밍 규칙을 어떻게 정하면 좋은가? (예: user_id, role_id)
8. 사용자(User) 와 역할(Role) 관계가 N:M일 때, UserRole 조인 테이블을 어떻게 설계할 수 있는가?
9. 공통 속성(created_at, updated_at, deleted_at)을 테이블마다 두는 이유는 무엇인가?
10. 속성의 데이터 타입과 제약조건(NOT NULL, UNIQUE, CHECK 등)은 어떻게 ERD에 표현할 수 있는가?
11. 외래키 제약 조건에서 ON DELETE CASCADE, ON DELETE SET NULL, ON DELETE RESTRICT 는 각각 어떤 상황에 유용한가?
12. 팀 프로젝트에서 ERD 설계 시, 네이밍 컨벤션과 매핑 규칙을 문서화해야 하는 이유는 무엇인가?
13. ERD 리뷰(다이어그램 리뷰)를 할 때 체크해야 할 항목(예: 매핑 표현, 키 설계, 제약조건 반영 등)은 무엇이 있을까?

 

 

크로우즈 풋(Crow's Foot) 표기법의 기호 의미

크로우즈 풋 표기법은 정보공학 표기법(Information Engineering Notation)으로도 알려져 있으며, 실제 관계형 데이터베이스 설계에서 가장 널리 사용되는 ERD 표기법 이다.

 

• Crow’s foot (까마귀발): “많음(Many)”
• Vertical bar (｜): “정확히 하나(One)”
• Circle (○): “선택적 관계(Optional)”, 즉 0 또는 1 가능성

이러한 기호는 관계선의 끝에 배치되어 한눈에 일대일, 일대다, 다대다 관계를 시각적으로 구분할 수 있다.

 

참조

https://creately.com/guides/cardinality-symbols

Cardinality Symbols in ER Diagrams: Types & Notations + Free Templates | Creately

https://velog.io/@bami/ER-%EB%AA%A8%EB%8D%B8%EA%B3%BC-Crow-feet-%ED%91%9C%EA%B8%B0%EB%B2%95

 

 

식별 관계(Identifying) vs 비식별 관계(Non-identifying)

• 식별 관계
  • 부모 테이블의 기본기(PK) 가 자식 테이블의 PK로 포함되는 관계
  • 강한 종속성을 가짐
  • ERD에서 실선으로 표현 (────)
  • 예: 주문(Orders)과 주문상세(OrderItems). OrderItems는 반드시 Orders와 함께 존재해야 하며, PK는 (order_id, product_id) 같은 복합 키.
• 비식별 관계
  • 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)로만 들어가는 관계
  • 독립적인 식별자가 있음
  • ERD에서 점선으로 표현 (--------)
  • 예: 사용자(User)와 주소(Address). 주소는 address_id로 독립적으로 식별되고, user_id는 FK로만 존재.

 

 

ERD에서 1:1, 1:N, N:M 관계 표현

 

• 1:1 관계 : 한쪽 끝은 ｜, 다른 쪽도 ｜
• 1:N 관계 : 한쪽은 ｜, 다른 쪽은 갈퀴 모양 <
• N:M 관계 : 양쪽 모두 갈퀴 모양 <

 

 

N:M 관계를 직접 연결하면 문제가 되는 이유

 

• 관계를 직접 연결하면 중복 데이터와 무결성 문제 발생
• 예: 사용자(User)와 역할(Role) 사이 N:M을 직접 연결하면, 특정 사용자의 역할 추가/삭제 관리가 어려워짐

 

 

조인 테이블(Junction Table)의 역할

조인테이블은 지난 1단계 학습에서 언급한 연결 테이블 임

지난번과 같은 예를 들면

학생과 수업은 N:M 관계 → 한 학생은 여러 수업을 들을 수 있고, 한 수업에도 여러 학생이 등록할 수 있음.

이 관계를 해결하기위해 조인 테이블(예: 수강 테이블)을 둔다.

 

• N:M 관계를 풀어내기 위해 조인 테이블을 둠
• 학생 — 수강 테이블 — 수업 형태로 분리
• student_id, course_id를 외래키(FK)로 두고
• 두 값을 합쳐서 복합 PK로 설정

 

 

조인 테이블 키 설계 방법

조인 테이블을 설계할 때 크게 두 가지 방법이 있다.

1. 복합 PK
   • PRIMARY KEY(student_id + course_id를 합쳐 기본 키로 사용)
   • 장점: 단순하고 직관적이며, 불필요한 ID 컬럼이 생기지 않음
   • 단점: 다른 테이블에서 참조할 때는 키가 길어져 불편
2. 대리키(예: id 컬럼)
   • enrollment_id 같은 고유 ID를 PK로 사용하고, student_id, course_id는 FK로 둠
   • 장점: 다른 테이블에서 참조할 때 간단해지고 확장성이 좋음
   • 단점: 컬럼이 하나 더 생겨 구조가 다소 복잡해질 수 있음

각자 어떤 때 사용하는지가 다양하게 나와있는데.. 아직 어렵다.. 이해를 위해 찾아 본 블로그 글을 내용에 넣지는 않았는데 내가 다시 보면서 이해하려고 녛음 ㅎㅎ

바로 이 블로그

https://prohannah.tistory.com/175

 

 

FK(외래키) 네이밍 규칙

• 보통 테이블명 단수형_컬럼명을 권장
• 예: user_id, role_id, order_id

참조

https://f-lab.kr/insight/spring-pk-fk-naming-rules-20250102

스프링에서 PK와 FK 네이밍 규칙 이해하기

https://lys5654.tistory.com/47

1:N, M:N 관계에서의 외래키 설계와 테이블 명명법