백엔드 개발을 공부하다 보면 가장 먼저 마주하는 개념 중 하나가 데이터베이스(Database)입니다.
특히 서비스를 만들 때는 단순히 데이터를 저장하는 것을 넘어
- 어떤 데이터를 저장할 것인지
- 데이터 사이의 관계는 무엇인지
- 어떤 구조로 관리할 것인지
를 먼저 설계해야 합니다.
이 과정에서 등장하는 것이 바로 ERD(Entity Relationship Diagram)입니다.
이번 글에서는
- RDB와 NoSQL의 차이
- ERD란 무엇인지
- ERD 설계 방법
을 정리해보겠습니다.
데이터베이스 종류: RDB vs NoSQL
데이터베이스는 크게 관계형 데이터베이스(RDB)와 NoSQL 두 가지로 나눌 수 있습니다.
각 방식은 데이터 저장 방식과 사용 목적이 다릅니다.
RDB (관계형 데이터베이스)
RDB는 테이블 간 관계를 기반으로 데이터를 저장하는 데이터베이스입니다.
가장 많이 사용되는 데이터베이스 방식이며 대부분의 웹 서비스에서 사용됩니다.
특징
- 데이터를 테이블(Row, Column) 형태로 저장
- _PK(Primary Key), FK(Foreign Key)_로 테이블 관계 표현
- 정해진 스키마(schema) 기반으로 데이터 관리
장점
- 데이터 정합성과 무결성 유지
- 복잡한 JOIN 쿼리 처리에 강함
- 트랜잭션 처리에 유리
단점
- 스키마 변경이 비교적 어려움
- 비정형 데이터 처리에 유연성이 떨어짐
- 대규모 분산 환경에서는 확장이 복잡할 수 있음
대표적인 RDB
- MySQL
- PostgreSQL
- Oracle
- MariaDB
NoSQL (비관계형 데이터베이스)
NoSQL은 관계 중심이 아니라 유연한 데이터 구조로 데이터를 저장하는 데이터베이스입니다.
특징
- 스키마가 없거나 매우 유연
- 다양한 데이터 구조 지원
대표적인 데이터 구조
- Key-Value
- Document
- Column Family
- Graph
장점
- 비정형 데이터 저장에 유리
- 구조 변경이 자유로움
- 대규모 데이터 처리와 수평 확장에 강함
단점
- 데이터 일관성 관리가 어려울 수 있음
- 관계형 데이터 표현이 어려움
- 복잡한 JOIN 연산에는 부적합
대표적인 NoSQL
- MongoDB
- Redis
- Cassandra
- Neo4j
언제 RDB를 사용하고 언제 NoSQL을 사용할까?
백엔드 서비스에서는 상황에 따라 다른 데이터베이스를 선택합니다.
RDB가 적합한 경우
- 회원 관리 시스템
- 주문 / 결제 서비스
- 금융 시스템
즉 데이터 정확성과 관계가 중요한 서비스입니다.
NoSQL이 적합한 경우
- 로그 데이터 저장
- 채팅 서비스
- 캐시 시스템
- 실시간 추천 시스템
즉 대용량 데이터 처리와 확장성이 중요한 서비스입니다.
ERD(Entity Relationship Diagram)란?
ERD는 데이터베이스 설계를 시각적으로 표현한 다이어그램입니다.
쉽게 말하면
서비스에 필요한 데이터 구조와 테이블 간 관계를 표현한 설계도
라고 볼 수 있습니다.
백엔드 개발에서는 기능을 구현하기 전에 먼저 데이터 구조를 설계합니다.
ERD를 설계하면 다음과 같은 장점이 있습니다.
- 필요한 엔티티를 명확하게 정의
- 테이블 간 관계를 한눈에 파악
- 데이터 중복 최소화
- 이후 JPA 엔티티 설계가 쉬워짐
즉, ERD는 백엔드 개발에서 매우 중요한 설계 단계입니다.
ERD의 핵심 구성 요소
ERD는 크게 4가지 요소로 구성됩니다.
1. Entity
저장하고 싶은 대상
보통 테이블이라고 생각하면 됩니다.
예시
- 사용자(User)
- 책(Book)
- 카테고리(Category)
- 해시태그(Hashtag)
- 좋아요(Like)
2. Attribute
엔티티가 가지는 속성(컬럼)입니다.
예시 (User 엔티티)
- id
- name
- nickname
- phone_number
- gender
3. Relationship
엔티티 사이의 관계를 의미합니다.
예시
- 사용자는 여러 권의 책을 대여할 수 있다
- 하나의 카테고리에는 여러 권의 책이 존재한다
4. Cardinality (관계 수)
엔티티 간 관계의 개수를 의미합니다.
1:1 관계
한 엔티티가 다른 엔티티 하나와만 연결
1:N 관계
한 엔티티가 여러 엔티티와 연결
N:M 관계
여러 엔티티가 서로 여러 개와 연결
예시
- 사용자 → 대여 : 1:N
- 카테고리 → 책 : 1:N
- 책 ↔ 해시태그 : N:M
ERD 설계 방법
보통 ERD 설계는 다음 순서로 진행합니다.
1. 요구사항에서 엔티티 찾기
요구사항을 읽고 명사를 중심으로 엔티티를 추출합니다.
예시 (책 대여 서비스)
- 사용자
- 책
- 카테고리
- 해시태그
- 대여
- 알림
2. 엔티티 속성 정의
각 엔티티에 필요한 정보를 정의합니다.
예시
User
- 이름
- 닉네임
- 전화번호
- 성별
Book
- 제목
- 설명
Category
- 이름
3. 엔티티 관계 정의
엔티티 간 관계를 정의합니다.
예시
- 사용자는 여러 권의 책을 대여할 수 있음
- 책은 하나의 카테고리에 속함
- 책은 여러 개의 해시태그를 가질 수 있음
4. N:M 관계 해결 (중간 테이블)
관계형 데이터베이스에서는 N:M 관계를 직접 표현하지 않는것을 권장합니다.
대신 중간 테이블을 생성합니다.
책 ↔ 해시태그
BOOK N : M HASHTAG
이렇게 관계를 별도의 테이블로 분리하면 데이터 구조가 훨씬 명확해지고,
나중에 쿼리를 작성할 때도 JOIN을 통해 쉽게 데이터를 조회할 수 있습니다.