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

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 리뷰(다이어그램 리뷰)를 할 때 체크해야 할 항목(예: 매핑 표현, 키 설계, 제약조건 반영 등)은 무엇이 있을까?

 

 

사용자(User)와 역할(Role)의 N:M 관계에서 UserRole 조인 테이블 설계

관계형 DB는 N:M을 직접 표현하지 않고 조인 테이블을 만들어 두 개의 1:N 관계로 나눈다.

User 테이블과 Role 테이블 외에 둘을 연결할 UserRole 테이블 새로 설계하기

피그마로 직접 그려따

ERD클라우드 사용법,, 아직 너무 어려워서,.,, 피그마로 최대한 그려봤는데..

 

• User 테이블:
  
  • user_id는 각 사용자를 식별하는 고유한 기본 키(Primary Key, PK)이고, user_name은 사용자의 이름을 저장한다.
  • user_name은 일반 데이터 컬럼으로 실질적인 내용과 의미를 담는 정보(사람이 보고 이해하는 값)이다. 중복 허용하는 경우도 있지만, 식별이 주 목적은 아님
• Role 테이블:
  
  • role_id는 각 역할을 식별하는 고유한 기본 키(PK)이고, role_name은 역할의 이름을 저장한다.
  • role_name도 user_name 처럼 일반 데이터 컬럼으로 실질적인 내용과 의미를 담는 정보(사람이 보고 이해하는 값)이다. 중복 허용하는 경우도 있지만, 식별이 주 목적은 아님
• UserRole 테이블 (조인 테이블):
  
  • user_id와 role_id는 각각 User와 Role 테이블의 기본 키를 참조하는 외래 키(Foreign Key, FK)이다.
  • 동시에 이 두 컬럼을 묶어서 복합 기본 키(Composite Primary Key, PK)로 사용한다. 이는 (사용자, 역할)의 조합이 항상 고유해야 함을 의미하며, 한 명의 사용자에게 동일한 역할이 중복으로 할당되는 것을 원천적으로 방지하여 데이터 무결성을 보장한다.

 

참조

https://nbcamp.spartacodingclub.kr/blog/erd-%EA%B0%9C%EC%B2%B4-%EA%B4%80%EA%B3%84-%EC%9D%B4%ED%95%B4%EB%A5%BC-%EB%8F%95%EB%8A%94-%ED%8C%81-19137

ERD 다이어그램 그리는 방법 - 내일배움캠프 블로그

 

 

 

공통 속성(created_at, updated_at, deleted_at)을 두는 이유

• 데이터 변경 추적 : 언제 생성/수정/삭제 되었는지 기록
• 소프트 삭제(Soft Delete) : deleted_at으로 실제 삭제 대신 비활성화 처리
• 감사(Audit) 로그 역할

참조

https://velog.io/@ash3767/created-at-updated-at

database created at updated at

https://reyoo-dev.tistory.com/entry/DB-%ED%85%8C%EC%9D%B4%EB%B8%94%EC%9D%84-%EC%84%A4%EA%B3%84%ED%95%A0-%EB%95%8C-isdeleted-%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EA%B2%83%EC%9D%B4-%EC%A2%8B%EC%9D%84%EA%B9%8C-deletedat-%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EA%B2%83%EC%9D%B4-%EC%A2%8B%EC%9D%84%EA%B9%8C

[DB] 테이블을 설계할 때 is_deleted 를 사용하는 것이 좋을까? deleted_at 을 사용하는 것이 좋을까?

https://www.reddit.com/r/webdev/comments/1cez61c/do_you_have_created_at_and_last_update_at_fields/?tl=ko

Reddit의 webdev 커뮤니티

 

 

속성의 데이터 타입과 제약조건의 ERD 표현

데이터 타입

ERD에서 속성의 데이터 타입은 일반적으로 속성 이름 바로 옆 괄호 안에 표기한다. 이는 데이터베이스 스키마를 설계할 때 해당 속성이 어떤 종류의 데이터를 저장할지를 명확히 하기 위해서이다.

• 표기법: 속성명 (데이터타입)
• 예시:
  • 회원아이디 (VARCHAR(20))
  • 주문수량 (INT)
  • 생성일 (DATETIME)

주요 데이터 타입:

• 문자열: VARCHAR(n), CHAR(n), TEXT
• 숫자: INT, BIGINT, DECIMAL(p, s)
• 날짜/시간: DATE, DATETIME, TIMESTAMP
• 이진: BOOLEAN, BIT

 

ERD 키와 제약 조건 표기법 (찾아볼수록 뭔가 다 다른듯한,.,,?)

 

기본 키 (Primary Key, PK)

기본 키는 NOT NULL과 UNIQUE 제약조건을 모두 가지며, 테이블의 각 레코드를 고유하게 식별한다.

• 속성명에 밑줄을 긋거나 PK 라고 표시
• 열쇠로도 표현
• 다이어그램의 개체(Entity)에서 키 영역을 구분하여 상단에 배치
• 주 식별자는 유일한 속성이므로 다른 속성과의 명확한 구분을 위해 구분선을 두기도 한다.

 

NOT NULL

NOT NULL 제약조건은 해당 속성이 반드시 값을 가져야 함을 의미

• 해당 속성에 들어갈 값에 Null을 비허용 한다면, N 혹은 NN을 적는다.
• 만약 Null 허용한다면 N을 적지 않는다.
• 속성명 옆에 * 또는 N을 붙임
• 일부 도구에서는 속성 리스트 옆에 [NOT NULL]이라고 명시하기도 합니다.

 

UNIQUE

UNIQUE 제약조건은 해당 속성의 값이 테이블 내에서 항상 고유해야 함을 의미한다. 기본 키(PK)는 아니지만 중복을 허용하지 않는 속성에 사용

• 속성명 옆에 (U) 또는 U를 붙인다.
• [UNIQUE] 라고 명시하기도 한다.

 

CHECK

CHECK 제약조건은 속성에 저장될 수 있는 값의 범위나 조건을 제한한다. ERD에서는 주로 노트나 주석을 이용해 표현하는 경우가 많다.

• 속성 옆에 {CHECK} 와 함께 조건을 명시
• 별도의 주석(Note)으로 연결하여 상세히 기술

예)

• 나이 (INT) {CHECK: 나이 >= 19}
• 주문상태 (VARCHAR(10)) {CHECK: 주문상태 IN ('결제완료', '배송중', '배송완료')}

 

 

외래 식별자(FK)

• 데이터베이스 테이블의 Foreign Key를 표현
• 외래 식별자 역시 key의 일종이라 ERD 엔티티에도 열쇠 아이콘으로 표시한다.(프로그램에 따라 다를 수 있음)
• 외래 식별자를 표시할 때에는 선을 이어주는데 개체와 관계를 따져 표시한다.

참조

https://velog.io/@cvcvcx9/ERD%EC%9D%98-%ED%91%9C%EA%B8%B0%EB%B2%95

ERD의 표기법

 

 

 

외래키 제약 조건의 삭제

• ON DELETE CASCADE : 부모 삭제 → 자식도 자동 삭제 (예: 주문 삭제 시 주문 상세도 삭제)
• ON DELETE SET NULL : 부모 삭제 → 자식 FK를 NULL로 (예: 사용자가 삭제되면 글의 작성자는 NULL)
• ON DELETE RESTRICT : 부모 삭제 불가 (자식이 있으면 삭제 금지)

 

 

네이밍 컨벤션과 매핑 규칙 문서화 필요성

• 팀 프로젝트에서는 일관성이 중요
• userId vs user_id vs uid 같은 혼란 방지
• 매핑 규칙을 명확히 하면 협업 시 버그 감소
• 개발자가 이름을 찾는 데 소비되는 시간 절약할 수 있음

참조

https://bestinu.tistory.com/62

 

ERD 리뷰 시 체크리스트

엔티티 검토

• 모든 엔티티가 독립적으로 존재 가능한지
• 엔티티명이 단수 명사로 명확하게 작명되었는지
• 비즈니스 요구사항을 모두 충족하는지

속성 검토

• 모든 엔티티에 기본키(PK)가 정의되었는지
• 속성명이 의미를 명확히 전달하는지
• 필수 속성과 선택 속성이 적절히 구분되었는지
• 데이터 타입이 적절히 선택되었는지

관계 검토

• 모든 관계의 카디널리티(1:1, 1:N, N:M)가 올바른지
• 외래키(FK)가 적절한 위치에 배치되었는지
• N:M 관계가 중간 테이블로 정규화되었는지
• 참조 무결성 제약조건이 고려되었는지

정규화 검토

• 중복 데이터가 제거되었는지
• 갱신 이상, 삽입 이상, 삭제 이상이 없는지
• 비즈니스 규칙이 ERD에 올바르게 반영되었는지

네이밍 검토

• 전체적으로 일관된 네이밍 규칙이 적용되었는지
• 약어 사용이 최소화되었는지
• 예약어와 충돌하지 않는지

 

 

 

 

 

 

템플릿 예시들을 볼 수 있는 사이트 - 몇몇개는 무한로딩으로 나오지 않음...ㅠ

https://creately.com/diagram-community/popular/t/erd

Erd Templates | Editable Online or Download for Free | Creately

 

 

 

 

 

 

참조

https://www.devkobe24.com/Backend%20Development/2025-08-10-EDR-GUIDE.html#-erd-%EA%B2%80%ED%86%A0-%EC%B2%B4%ED%81%AC%EB%A6%AC%EC%8A%A4%ED%8A%B8

📚[Backend Development] ERD(Entity-Relationship Diagram) 설계 완벽 가이드

 

 

 

 

 

 

 

다시 볼 블로그들

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

📋 데이터 모델링 개념 & ERD 다이어그램 작성 💯 총정리

https://blog.naver.com/dodnam/221750031014

DB 모델링 - Entity, ERD, 논리적 모델링, 정규화