이번 글에서는 ERD Cloud를 이용해 앞서 만들었던 게시판 프로젝트의 ERD를 설계해볼 것이다.

참고영상 : https://www.youtube.com/playlist?list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa

---

1. ERD 설정

우선, ERD 우측 상단의 톱니바퀴 아이콘을 클릭하면 위와 같이 ERD 설정 화면이 나온다.

여기서, DISPLAY는 테이블에 표시되는 각 컬럼의 속성 표시 여부를 설정해준다.

📌 ERD Cloud DISPLAY 설정 요약

항목	의미	예시
Domain	값 범위 제한	상태값, 성별 등
Type	데이터 타입	INT, VARCHAR 등
Allow Null	비어도 되는지 여부	이메일(X), 수정일(O)
Default	기본값 지정	false, CURRENT_TIMESTAMP
Comment	컬럼 설명	설명 메모 용도

---

2. ERD 설계 핵심 개념 정리

📌 ERD 구성 요소

✔️ Entity
독립적인 개체 (예: 사용자, 게시글 등)

✔️ Weak Entity (약한 엔티티)
다른 엔티티 없이는 존재할 수 없음 (예: 주문 상세)

✔️ Relationship (관계)
두 개체 사이의 관계 (예: 작성한다, 포함된다 등)

✔️ Weak Relationship (약한 관계)
약한 엔티티와 연결되는 관계

✔️ Attribute (속성)
엔티티가 가지는 속성 (예: 이름, 이메일 등)

✔️ Multivalued Attribute (다중 속성)
하나의 엔티티가 여러 값을 가질 수 있음 (예: 전화번호 여러 개)

---

📌 관계(Cardinality)

🔗 1:1 필수
양쪽 엔티티 모두 반드시 서로 하나와 연결되어야 함
예시) 사람은 주민등록번호를 하나 반드시 가져야 함

🔗 1:1 선택
한쪽은 필수지만, 다른 한쪽은 연결되지 않아도 됨
예시) 학생은 지도교수를 선택적으로 가질 수 있음

🔗 1:N 필수
한 엔티티는 반드시 여러 엔티티와 연결되어야 함
예시) 강의는 한 명 이상의 학생이 반드시 수강해야 함

🔗 1:N 선택
한 엔티티는 여러 엔티티와 연결될 수 있지만, 없어도 됨
예시) 학생은 강의를 수강하지 않을 수도 있음

---

📌 식별 관계 vs 비식별 관계

✅ 식별 관계 (Identifying Relationship)
자식 테이블의 기본키(PK)가 부모의 기본키를 포함
→ 부모 없이는 자식도 존재할 수 없음 (강한 의존성)
예시: 주문 - 주문상세

✅ 비식별 관계 (Non-identifying Relationship)
자식 테이블의 기본키에 부모키가 포함되지 않음
→ 부모와 자식은 독립적인 생명주기
예시: 회원 - 게시글 -> 회원이 탈퇴해도 게시글은 남아 있을 수 있음

🌟 정리

구분	식별 관계 (Identifying)	비식별 관계 (Non-identifying)
PK 구성	부모 PK가 자식 PK에 포함됨	부모 PK는 자식 PK에 포함되지 않음
삭제 시	부모 삭제 → 자식도 삭제됨	부모 삭제 → 자식은 남아있을 수 있음
의존성	강한 의존 (자식은 식별 불가)	식별 가능 (자식은 독립된 PK 가짐)

---

3. 게시판 ERD 설계

위 ERD는 게시판 시스템의 핵심인 회원(Member)과 게시글(Board) 테이블 간의 구조와 관계를 보여준다.

🔗 관계 설명: 1:N 비식별 관계

• 1:N (One to Many) 관계
  → 한 명의 회원이 여러 개의 게시글을 작성할 수 있음
• Board.member_id는 Member.id를 참조하는 Foreign Key
• 비식별 관계 (Non-identifying):
  → 게시글은 회원이 탈퇴해도 독립적으로 남아있을 수 있음
  (즉, 게시글의 기본키에 member_id가 포함되지 않음)

---

마무리
이번 글에서는 ERD 설계를 시작하기 위한 기본 설정, ERD 핵심 개념까지 정리했다.
마지막으로 ERD Cloud를 이용해서 실제 게시판 프로그램에 적용한 ERD까지 살펴보았다.
간단한 프로젝트였지만 데이터베이스 개념을 다시 정리할 수 있었고,
앞으로 더 규모가 큰 프로젝트에서도 유연하게 확장할 수 있을 것 같다!