RDBMS, 관계의 주인은 누구일까?

Nogglee·2026년 1월 30일

DBMS의 종류

DBMS 종류는 왜 나뉘어졌을까?
데이터의 형태가 다양해지면서 모든 유형의 데이터를 '테이블' 형식으로만 관리하다보니,
확장성 / 유연성 / 성능 부분에서 한계가 왔다.
그래서 저장 방식별로 DBMS가 나뉘었으며, 각 유형별 특징은 아래와 같다.

종류특징예시상세설명
RDBMS정합성이 중요한 비즈니스 데이터를 관리할 때 사용MariaDB, MySQL, Oracle, PostgreSQL관계형 데이터베이스, 테이블 형태로 데이터를 관리, PK / FK를 이용하여 데이터 관계를 표현, SQL 사용
Document DB구조가 자주 바뀌는 데이터를 관리할 때 사용MongoDBJSON 형태로 데이터를 관리, 유연한 스키마, 중첩 구조 가능
Key-Value DB속도가 최우선일 때 사용Redis, DynamoDB키-값 쌍으로 데이터를 저장, 데이터의 구조가 고정됨, 빠른 조회 속도
Search Engine DB검색 속도가 최우선일 때 사용Elasticsearch, OpenSearch인덱스를 이용한 빠른 검색, 텍스트 데이터의 검색이 최적화됨(형태소 분석)
Wide Column DB대용량 데이터를 관리할 때 사용Cassandra, HBase컬럼 단위로 데이터 저장, 분산 처리에 특화됨

RDBMS를 사용하는 케이스

RDBMS는 빠른 데이터 처리보다, 정확함이 우선될 때 사용한다.
중복 없는 데이터가 필요하거나, 여러 묶음의 데이터 변경 작업에 트랜잭션이 요구되는 경우 RDBMS가 필요하다.

트랜잭션:
여러 DB 작업(INSERT, DELETE 등)을 하나의 작업으로 묶어서 처리하는 단위
전부 성공하거나, 전부 실패해야 함

트랜잭션이 필요한 케이스를 좀 더 살펴보자.
쇼핑몰의 경우 결제가 발생하면, 주문 생성 -> 재고 감소 -> 결제 완료 -> 결제 내역 생성 순서로 진행되어야 한다.
이때, 주문 생성, 재고 감소까지는 완료되고, 결제에 실패했을 경우 주문은 있는데 결제 내역은 없어진다.
그렇기 때문에 모든 싸이클이 완료되기 전까지는 결제 건에 대해 성공 처리를 하면 안된다.
이러한 작업 묶음을 처리하는 단위를 트랜잭션이라 부른다.


PK, 정규화가 필요한 이유

PK와 정규화는 데이터 중복, 데이터 수정 지옥 현상을 막기 위한 하나의 장치라고 볼 수 있다.

PK로 테이블의 각 row를 unique 하게 구별할 수 있고, FK의 기준점이 된다.
PK가 없으면 데이터 중복이 발생할 수 있으며, row를 구분할 수 없어 FK 연결이 불가하다.
row 구분이 안되면 관계 설정이 안되기 때문에 RDBMS의 핵심 요소라고 볼 수 있다.

정규화는 중복되는 데이터를 분리해서 '한 곳에서만' 관리하게 만드는 것이다.
사용자 테이블과 결제내역 테이블 모두 '이메일'데이터를 가지고 있고, 두 테이블은 관계성이 없다고 가정해보자.

만약 사용자가 100건의 결제내역을 보유한 상태에서 사용자의 이메일을 수정한다면
사용자 정보만 변경되고 결제내역의 이메일은 그대로 남아있기 때문에 이메일 수정을 100번 해주어야한다.
이메일의 주인이 누구인지 모르기 때문이다.

'사용자 테이블의 PK'를 '결제내역 테이블의 FK'로 사용했다면 FK를 기준으로 변경사항을 한 번에 반영했을 것이다.
이와 같이 데이터의 일관성을 유지하거나 수정 비용을 감소 시키기 위해 정규화가 필요한 것이다.


RDBMS에서 관계의 주인

FK를 가지고있는 테이블이 RDBMS에서 관계의 주인이다.
'관계'라는 것은 결국 FK 컬럼이 존재함으로써 구현되기 때문이다.

예시테이블로, 게시글과 댓글을 생각해보자.
게시글이 존재하지 않으면 댓글은 존재할 수 없다.
하지만 댓글이 존재하지 않아도 게시글은 존재할 수 있다.
이때문에 게시글이 '관계의 주인'이 될거라고 착각할 수 있지만, 아래 내용을 살펴보자.

게시글 하나당 여러개의 댓글을 가질 수 있으므로
어떤 게시글의 댓글인지 구분하기 위해, 댓글 테이블은 게시글 PK를 FK로 가지게 된다.
FK를 들고있으면서 '관계'를 주도하는 테이블인 댓글 테이블이 관계의 주인이 된다.

profile
Product-minded Engineer

0개의 댓글