ERD Diagram

1. ERD란 무엇인가?

• Entity Relationship Diagram
  데이터(엔티티)와 데이터 간의 관계(릴레이션십)를 시각적으로 표현한 도표.
• 주요 목적
  • DB 구조를 한눈에 파악
  • 설계 논리 검증 및 오류 예방
  • 팀원 간의 원활한 의사소통 도구

---

2. ERD의 3대 구성요소

1) 엔티티(Entity)

• 정의 : 데이터베이스에서 관리해야 하는 '대상'
• 예시 : 학생, 교수, 강의, 주문, 상품 등
• 표현 : 사각형 (엔티티명 기입)
• 실무 TIP
  실질적으로 테이블이 될 대상만 엔티티로 잡는다. 의미 없는 중복 엔티티는 과감히 배제.

2) 속성(Attribute)

• 정의 : 엔티티를 설명하는 세부 정보
• 예시 : 학생(학번, 이름, 학과), 주문(주문ID, 주문일, 총액) 등
• 표현 : 타원형 (속성명 기입, 실제 설계 단계에서는 사각형 내부에 컬럼명으로 표시하는 경우가 많음)
• 유형
  • 기본 속성 : 단순한 정보(이름, 나이)
  • 기본키(PK, Primary Key) : 각 엔티티의 유일한 식별자
  • 외래키(FK, Foreign Key) : 다른 엔티티의 PK를 참조(관계 연결에 사용)

3) 관계(Relationship)

• 정의 : 두 개 이상의 엔티티 간의 연관성
• 표현 : 마름모(Relationship 이름), 선(두 엔티티를 연결)
• 주요 관계 형태
  • 1:1 (일대일)
    예) 사람-여권(한 사람당 한 개의 여권)
  • 1:N (일대다)
    예) 교수-강의(한 교수는 여러 강의를 담당)
  • N:M (다대다)
    예) 학생-과목(학생은 여러 과목 수강, 한 과목에 여러 학생 등록)
    → 중간 테이블(교차 엔티티) 필수

---

3. 실무 중심 ERD 작성 규칙

관계의 방향과 부모-자식 구분

• 부모 테이블 : 고유하게 식별되는 엔티티(PK를 가진 테이블)
• 자식 테이블 : 부모의 PK를 참조(FK로 가짐)

관계 표현 방식

• 실선
  • 자식 테이블에서 부모의 PK를 PK+FK로 같이 쓰는 경우
  • "부모가 있어야만 자식이 생김" (Ex. 주문 - 주문상세)
• 점선
  • 자식 테이블에서 부모의 PK를 FK로만 쓰는 경우
  • "부모 없이도 자식이 생길 수 있음" (Ex. 상품 - 리뷰, 리뷰는 상품 없이도 작성 가능하다고 설계할 때)

예시1: 학생 - 수강내역(1:N)

• 학생: 학번(PK), 이름, 학과 …
• 수강내역: 수강ID(PK), 학번(FK), 강의명 …
• 관계 : 1명의 학생은 여러 개의 수강내역을 가질 수 있다. (학생 PK → 수강내역 FK, 1:N)

예시2: 주문 - 주문상세(1:N)

• 주문: 주문ID(PK), 주문일, 총액 …
• 주문상세: 주문ID(PK+FK), 상품ID(PK+FK), 수량, 가격 …
• 관계 : 한 주문에 여러 주문상세가 매핑됨. (주문 PK → 주문상세 PK+FK, 1:N)

예시3: 학생 - 과목(N:M, 다대다)

• 학생: 학번(PK), 이름, …
• 과목: 과목ID(PK), 과목명, …
• 수강테이블(교차 엔티티): 학번(PK+FK), 과목ID(PK+FK), 학기, 성적 …
• 관계 : 중간 테이블(교차 엔티티) 반드시 필요

---

4. MySQL에서 ERD 다이어그램 그리기 (Workbench 기준)

1) Reverse Engineering (자동 ERD 생성)

• 기존 DB 테이블로부터 ERD 다이어그램 생성
  1. 테이블 DDL로 생성
     → 먼저 필요한 테이블을 CREATE 문으로 모두 생성
  2. 상단 메뉴 Database 클릭 → Reverse Engineer… 선택
  3. 연결할 Connection 선택 후 Next
  4. 대상 스키마(Database) 선택 후 Next
  5. Next → Execute로 다이어그램 자동 생성

2) Forward Engineering (ERD 기반 DDL 자동 생성)

• ERD에서 직접 엔티티, 속성, 관계선을 그리고 → DDL 스크립트로 추출 가능

---

5. 실무에서 ERD를 어떻게 활용하는가?

1. 사전 논의·설계
   • 요구사항 기반으로 엔티티와 관계 도출
   • 여러 명이 참여하는 팀 프로젝트에서 논리적 근거로 활용
2. DDL 스크립트 자동화
   • ERD에서 바로 CREATE TABLE 문으로 변환해 실수 최소화
3. 데이터베이스 구조 파악
   • 신규 멤버, 외주 개발자도 한눈에 구조 파악 가능
4. 변경 이력 관리
   • 설계 변경 시, ERD에서 영향도 즉시 파악 및 문서화

---

6. 실전 ERD 설계 Tip

• 엔티티는 꼭 고유하게 식별 가능한 대상만
• 관계선은 단방향, 양방향 모두 명확히
• 1:N, N:M, 1:1 구분을 확실하게
• PK, FK 속성명은 컬럼에서 반드시 명확하게 표시
• 중간 테이블(교차 엔티티)은 다대다(N:M)에서 빠짐없이 생성
• 실무에서 실제로 관리할 속성만 반영, 불필요한 속성은 과감히 배제

---

7. ERD 설계, 왜 중요한가?

• 개발 전 오류 예방 : 논리적 결함, 중복, 비효율 구조를 사전에 차단
• 커뮤니케이션의 언어 : 기획-개발-디자인 협업의 공통 언어로 사용
• 유지보수 용이 : 구조가 명확하면 이후 확장·수정이 한결 쉬움