📁 DB 모델링과 ERD 다이어그램 이해하기

이전 포스팅

1. 데이터베이스 모델링이란?

▶ DB 모델링의 정의

데이터베이스 모델링은 현실 세계의 개체(Entity)와 이들 사이의 관계(Relationship)를 데이터 구조로 표현하여 데이터베이스에 적용할 수 있도록 설계하는 과정입니다.

▶ 왜 모델링이 중요한가

• 개발 방향과 데이터 흐름을 명확히 정리할 수 있다.
• 데이터 중복을 줄이고 무결성을 확보할 수 있다.
• 변경과 확장에 유연한 구조를 설계할 수 있다.
• 구조를 시각화하여 협업과 유지보수에 용이하다.

▶ 논리 모델 vs 물리 모델

구분논리 모델물리 모델

정의	개념적 설계	실제 구현 구조
표현 방식	ERD, 관계 설정 등	SQL 스키마, 인덱스 등
사용 대상	기획자, 개발자	DBA, 백엔드 개발자

---

2. ERD(Entity Relationship Diagram)란?

▶ ERD의 역할과 목적

ERD는 데이터베이스 구조를 도식화한 다이어그램으로, 테이블 간 관계와 구조를 시각적으로 표현해줍니다. 이를 통해 데이터 흐름과 설계 방향을 쉽게 이해하고 논의할 수 있습니다.

▶ ERD 구성 요소

• Entity (엔터티): 테이블에 해당하는 구성요소
• Attribute (속성): 테이블의 컬럼 정보
• Relationship (관계): 테이블 간의 연결 관계를 나타내는 선

---

3. 관계의 종류와 의미

관계는 데이터베이스의 테이블 간 연결 방식을 정의하며, 올바른 설계를 위해서는 관계의 유형을 정확히 이해해야 합니다. 대표적인 관계는 1:1, 1:N, N:M 세 가지가 있으며, 각 관계는 외래키(Foreign Key)의 위치와 구조에 차이를 가집니다.

▶ 1:1 관계

• 하나의 엔터티가 오직 하나의 엔터티와만 연결됨
• 예: 사용자 ↔ 사용자 프로필
• 외래키는 어느 쪽에 있어도 되지만, 보통 더 자주 조회되는 쪽에 둡니다

Table users {
  id int [pk]
  name varchar
}

Table user_profiles {
  id int [pk]
  user_id int [ref: > users.id, unique]
  bio text
}

▶ 1:N 관계

• 하나의 엔터티가 여러 엔터티와 연결됨
• 예: 블로그 ↔ 게시글, 사용자 ↔ 주문
• 외래키는 "여러 개"를 가지는 테이블에 위치

Table blogs {
  id int [pk]
  title varchar
}

Table posts {
  id int [pk]
  blog_id int [ref: > blogs.id]
  title varchar
}

▶ N:M 관계

• 다수와 다수가 연결되는 구조
• 예: 학생 ↔ 수업
• 반드시 중간 테이블을 통해 1:N + N:1 구조로 분리

Table students {
  id int [pk]
  name varchar
}

Table classes {
  id int [pk]
  name varchar
}

Table enrollments {
  student_id int [ref: > students.id]
  class_id int [ref: > classes.id]
  enrolled_at datetime
}

이처럼 각 관계는 ERD 설계에서 매우 중요하며, 관계의 방향성과 외래키의 위치를 정확히 이해하고 적용하는 것이 핵심입니다.

4. ERD 다이어그램에서 사용되는 기호

ERD에서는 테이블 간 관계를 시각적으로 나타내기 위해 다양한 관계 기호를 사용합니다. 이 기호들은 연결의 방향과 필수 여부, 데이터 수량을 의미합니다.

▶ ERD 관계 기호 예시

| 관계 기호 | 의미       | 설명                                               |
|-----------|------------|----------------------------------------------------|
| |—|       | 필수 1     | 반드시 하나와만 연결 (예: 사용자 ↔ 주민등록정보) |
| O—|       | 선택 1     | 없어도 되고 하나만 연결 (예: 사용자 ↔ 프로필 이미지) |
| |—<       | 필수 다수  | 최소 하나 이상 연결 (예: 사용자 ↔ 게시글)        |
| O—<       | 선택 다수  | 0개 이상 연결 가능 (예: 상품 ↔ 리뷰)              |

※ 일부 ERD 툴에서는 위 기호들이 다르게 표현될 수 있으므로 사용 중인 툴의 표현 규칙도 함께 확인하는 것이 좋습니다.

▶ 관계선 해석 방법

• |는 필수, O는 선택(optional) 관계를 의미합니다.
• <는 다수(Many) 관계이며, 보통 외래키가 있는 방향을 가리킵니다.

관계 기호는 설계 의도를 명확히 표현하는 수단이므로, 정확한 의미와 위치를 이해하고 사용해야 데이터 무결성과 확장성을 보장할 수 있습니다.

• (이미지 예시: ERD 관계선 시각화)

---

5. ERD 작성 시 자주 나오는 예시

▶ 사용자(User) ↔ 게시글(Post)

Table users {
  id int [pk]
  name varchar
}

Table posts {
  id int [pk]
  user_id int [ref: > users.id]
  title varchar
}

▶ 게시판(Board) ↔ 댓글(Comment)

• 게시판 1개에 여러 댓글이 연결됨 → 1:N 관계

▶ 제품(Product) ↔ 리뷰(Review)

• 하나의 제품에 여러 리뷰 → 1:N 관계

▶ 카테고리(Category) ↔ 상품(Item)

• 카테고리 1개는 여러 상품을 포함 → 1:N 관계

---

6. ERD 툴 소개 및 사용법 예시

▶ dbdiagram.io란?

• 웹 기반 ERD 설계 툴
• DBML, SQL, PostgreSQL, MySQL 등 다양한 포맷 지원
• 설계한 구조를 코드로 관리하거나 시각화 가능

▶ 예시 DBML 코드

Table students {
  id int [pk]
  name varchar
}

Table classes {
  id int [pk]
  name varchar
}

Table enrollments {
  student_id int [ref: > students.id]
  class_id int [ref: > classes.id]
}

• enrollments 테이블을 통해 다대다 관계를 표현

---

7. ERD 설계 시 실수 방지 팁

▶ 실무에서 자주 발생하는 실수

• 관계 방향을 잘못 설정해 참조 무결성 오류가 발생함
• 외래키 설정은 했지만 인덱스를 누락하여 성능 저하 초래
• 다대다 관계를 직접 연결하려고 하고 중간 테이블을 생략함
• 컬럼 이름에 의미 없는 축약어나 중복된 이름을 사용해 가독성 저하
• 테이블마다 일관되지 않은 명명 규칙 사용으로 유지보수 어려움
• 정규화가 과도하거나 부족하여 데이터 중복 또는 복잡성 증가
• 날짜, 숫자 등 데이터 타입을 적절히 사용하지 않아 정렬/연산 오류 발생
• ERD 상에 정의된 관계를 실제 DB에 구현하지 않아 무결성 누락

▶ 실수 방지 방법

• 관계를 설계할 때 반드시 1:1, 1:N, N:M 중 어떤 구조인지 먼저 명확히 판단
• 외래키가 있는 컬럼에는 인덱스를 반드시 설정하여 성능을 보장
• 다대다 관계는 항상 중간 테이블을 통해 풀어서 구현
• 테이블 및 컬럼 이름은 팀에서 정의한 명명 규칙을 따르고, 축약어는 지양
• 논리 모델링 단계에서 충분한 리뷰를 거쳐 정규화/비정규화의 균형을 맞춤
• 데이터 타입은 목적에 맞게 사용하고, 특히 날짜와 숫자는 주의하여 설정
• ERD 작성 시 정의한 제약 조건(FK, UNIQUE 등)은 DB에 모두 반영되도록 함
• 설계 초기에 팀원들과 ERD를 공유하고 피드백을 받아 재검토하는 과정 마련

ERD와 DB 모델링은 단순히 데이터를 저장하기 위한 구조가 아니라, 데이터 흐름과 시스템 전체의 안정성을 결정짓는 설계 핵심입니다.

▶ 시작을 위한 팁

• 요구사항을 바탕으로 개체와 관계부터 명확히 정리
• ERD는 반복적으로 검토하고 개선하는 구조로 접근
• 너무 많은 관계보다는 명확하고 단순한 구조로 시작하는 것이 좋습니다.