관계형 데이터 모델링

src/content/documents/data-analysis/game-service-erd-modeling.json

게임을 만든다고 생각해 봅시다.

게임에는 플레이어, 아이템, 몬스터, 길드처럼 수많은 정보가 존재합니다.

예를 들어 플레이어에 대한 정보를 저장하려면 다음과 같은 데이터가 필요할 수 있습니다.

플레이어 ID : 1001
닉네임      : 천기사
레벨        : 35
보유 아이템 : 철검, 회복 포션, 가죽 갑옷
길드        : 용기사단

플레이어가 1명뿐이라면 이렇게 저장해도 큰 문제가 없습니다.

하지만 플레이어가 100만 명이고, 아이템이 수천 종류이며, 플레이어마다 여러 개의 아이템을 가지고 있다면 어떨까요?

모든 정보를 한곳에 저장하기보다는 플레이어는 플레이어끼리, 아이템은 아이템끼리 나누어 저장하고 필요한 정보를 서로 연결하는 방법이 필요합니다.

이렇게 데이터를 **테이블(Table)**로 나누고 각 테이블 사이의 **관계(Relationship)**를 설계하는 것이 **관계형 데이터 모델링(Relational Data Modeling)**입니다.

관계형 데이터베이스의 기본 구조

관계형 데이터베이스에서는 데이터를 **행(Row)**과 **열(Column)**로 구성된 테이블에 저장합니다.

게임의 플레이어 정보를 다음과 같이 저장할 수 있습니다.

Player 테이블

player_id

nickname

level

gold

1

천기사

35

5000

2

흑마법사

42

8200

3

슬라임헌터

21

2300

여기서 각각의 개념을 데이터 모델링 용어로 표현하면 다음과 같습니다.

  • Table : Player

  • Column(Attribute) : player_id, nickname, level, gold

  • Row(Record) : 플레이어 한 명의 데이터

즉,

PLAYERplayer_id nickname level gold1 천기사 35 50002 흑마법사 42 82003 슬라임헌터 21 2300
Player 테이블의 행과 열

처럼 현실의 플레이어 정보를 구조화해서 저장하는 것입니다.

Entity — 무엇을 테이블로 만들 것인가?

관계형 데이터 모델링을 시작할 때 가장 먼저 생각해야 하는 것은 **어떤 대상을 따로 관리할 것인가?**입니다.

이러한 대상을 **Entity(엔티티)**라고 합니다.

RPG 게임이라면 다음과 같은 Entity를 생각할 수 있습니다.

Player
Item
Monster
Guild
Quest
Skill

보통 이러한 Entity들이 실제 데이터베이스에서는 각각의 테이블이 됩니다.

예를 들어 플레이어와 아이템을 관리한다면 다음과 같이 나눌 수 있습니다.

Player
────────────
player_id
nickname
level
gold


Item
────────────
item_id
item_name
price

여기서 중요한 점은 서로 다른 종류의 정보를 하나의 테이블에 무작정 넣지 않는 것입니다.

Attribute — 대상이 가지고 있는 정보

Entity가 결정되었다면 그 대상이 어떤 정보를 가지고 있는지 결정해야 합니다.

이것을 **Attribute(속성)**라고 합니다.

예를 들어 Player라는 Entity가 있다면 다음과 같은 Attribute를 가질 수 있습니다.

Player
─────────────
player_id
nickname
level
gold
hp

Item이라면 다음과 같습니다.

Item
─────────────
item_id
item_name
item_type
price
attack

쉽게 생각하면

Entity = 어떤 것을 저장할 것인가? Attribute = 그것의 어떤 정보를 저장할 것인가?

입니다.

게임 캐릭터로 비유하면 캐릭터 자체가 Entity, 캐릭터의 레벨·HP·닉네임 등이 Attribute라고 볼 수 있습니다.

Primary Key — 플레이어를 어떻게 구별할까?

플레이어 테이블에 다음과 같은 데이터가 있다고 생각해 봅시다.

player_id

nickname

level

1

천기사

35

2

천기사

51

닉네임이 동일한 플레이어가 존재할 수 있습니다.

그렇다면 단순히 천기사라는 닉네임만 가지고는 어떤 플레이어인지 정확하게 구별할 수 없습니다.

그래서 각각의 데이터를 유일하게 식별할 수 있는 값이 필요합니다.

이것이 **Primary Key(PK, 기본키)**입니다.

Player
──────────────────
player_id  ← PK
nickname
level
gold

예를 들어

player_id = 1

이라면 데이터베이스에서 정확히 한 명의 플레이어를 찾을 수 있도록 설계하는 것입니다.

PK = 테이블에서 각 데이터를 구별하기 위한 고유한 값

이라고 생각하면 됩니다.

Relationship — 테이블끼리 연결하기

관계형 데이터 모델링에서 가장 중요한 부분 중 하나가 바로 **Relationship(관계)**입니다.

게임에는 서로 독립적인 데이터만 존재하지 않습니다.

예를 들어

플레이어 → 길드에 가입한다.
플레이어 → 아이템을 가지고 있다.
플레이어 → 퀘스트를 수행한다.
몬스터 → 아이템을 드롭한다.

처럼 데이터들이 서로 연결되어 있습니다.

이러한 관계를 데이터베이스에서도 표현해야 합니다.

예를 들어 길드가 있다고 해봅시다.

Guild

guild_id

guild_name

10

용기사단

20

마법협회

그리고 Player에 guild_id를 저장합니다.

Player

player_id

nickname

level

guild_id

1

천기사

35

10

2

흑마법사

42

20

3

슬라임헌터

21

10

이제 데이터를 보면

천기사      → guild_id 10 → 용기사단
흑마법사    → guild_id 20 → 마법협회
슬라임헌터  → guild_id 10 → 용기사단

이라는 관계를 알 수 있습니다.

Foreign Key — 다른 테이블을 가리키는 값

Player 테이블의 guild_id는 Guild 테이블의 guild_id를 가리키고 있습니다.

GUILDPK guild_idguild_namePLAYERPK player_idnicknameFK guild_idFK 참조
Guild PK를 참조하는 Player FK

이처럼 다른 테이블의 PK를 참조하는 값을 **Foreign Key(FK, 외래키)**라고 합니다.

Guild.guild_id
      ↑
      │
      │ FK로 참조
      │
Player.guild_id

정리하면

PK = 나 자신을 구별하는 키 FK = 다른 테이블의 데이터를 가리키는 키

라고 이해할 수 있습니다.

PLAYER의 guild_id가 GUILD의 guild_id를 참조하는 PK와 FK 관계를 보여 주는 게임 데이터베이스 도식

관계에는 종류가 있다 — 1:1, 1:N, N:M

테이블끼리 연결한다고 해서 모든 관계가 동일한 것은 아닙니다.

관계는 크게 다음과 같이 구분할 수 있습니다.

1 : 1
1 : N
N : M

1:1 관계

한 데이터가 다른 데이터 하나와 연결되는 관계입니다.

게임에서 플레이어마다 개인 설정 정보를 하나씩 가지고 있다고 생각해봅시다.

Player 1 ───────── 1 PlayerSetting

플레이어 한 명당 설정 정보 하나가 존재합니다.

1:N 관계

하나의 데이터가 여러 데이터와 연결되는 관계입니다.

대표적인 예가 길드와 플레이어입니다.

용기사단천기사슬라임헌터궁수왕1 : N
길드와 플레이어의 1대다 관계

길드 하나에는 여러 명의 플레이어가 가입할 수 있습니다.

따라서

Guild 1 ───────── N Player

관계가 됩니다.

N:M 관계

여러 데이터가 여러 데이터와 연결되는 관계입니다.

대표적으로 플레이어와 아이템을 생각할 수 있습니다.

천기사흑마법사철검회복 포션가죽 갑옷마법 지팡이N : M
플레이어와 아이템의 다대다 관계

플레이어 한 명은 여러 아이템을 가지고 있고,

하나의 아이템 종류 역시 여러 플레이어가 가지고 있을 수 있습니다.

따라서

Player N ───────── M Item

관계가 됩니다.

하지만 관계형 데이터베이스에서는 일반적으로 N:M 관계를 그대로 구현하기보다 중간 테이블을 사용합니다.

N:M 관계를 중간 테이블로 해결하기

Player와 Item 사이에 Inventory라는 테이블을 만들어봅시다.

Player
────────────
player_id PK
nickname


Inventory
────────────
player_id FK
item_id   FK
quantity


Item
────────────
item_id PK
item_name

그러면 관계가

Player 1 ─── N Inventory N ─── 1 Item

형태로 바뀝니다.

예를 들어 다음과 같이 저장할 수 있습니다.

Inventory

player_id

item_id

quantity

1

101

1

1

102

5

2

102

10

Item

item_id

item_name

101

철검

102

회복 포션

이를 해석하면

player_id = 1
    ↓
천기사

item_id = 101
    ↓
철검 1개

item_id = 102
    ↓
회복 포션 5개

가 됩니다.

여기서 Inventory는 단순히 Player와 Item을 연결하는 것뿐만 아니라 quantity처럼 관계 자체가 가지고 있는 정보도 저장할 수 있습니다.

PLAYERPK player_idnicknamelevelINVENTORYPK/FK player_idPK/FK item_idquantityITEMPK item_iditem_nameprice1NN1
Player, Inventory, Item 관계

왜 굳이 테이블을 나눌까?

여기서 의문이 생길 수 있습니다.

그냥 Player 테이블에 아이템 이름까지 전부 저장하면 안 될까?

예를 들어 다음과 같이 만들 수도 있습니다.

player_id

nickname

item1

item2

item3

1

천기사

철검

포션

갑옷

2

흑마법사

지팡이

포션

NULL

처음에는 간단해 보입니다.

하지만 아이템을 100개 가진 플레이어가 나타난다면 어떻게 해야 할까요?

item1
item2
item3
...
item100

컬럼을 계속 추가해야 합니다.

게다가 철검의 가격이 변경된다면 플레이어마다 저장되어 있는 철검 정보를 모두 수정해야 할 수도 있습니다.

그래서 데이터를 역할에 따라 분리합니다.

Player → 플레이어 정보

Item → 아이템 자체의 정보

Inventory → 어떤 플레이어가 어떤 아이템을 몇 개 가지고 있는지

이렇게 설계하면 데이터 중복을 줄이고 수정과 관리도 쉬워집니다.

이러한 문제를 체계적으로 해결하기 위한 과정이 **정규화(Normalization)**와 연결됩니다.

관계형 데이터 모델링과 정규화

관계형 데이터 모델링을 공부하다 보면 자연스럽게 다음 개념들을 만나게 됩니다.

1NF
 ↓
2NF
 ↓
3NF
 ↓
BCNF

정규화의 핵심 목적은 무조건 테이블을 많이 만드는 것이 아닙니다.

불필요한 데이터 중복을 줄이고 데이터의 일관성을 유지할 수 있도록 구조를 설계하는 것이 핵심입니다.

예를 들어 다음과 같이 모든 정보를 하나의 테이블에 넣었다고 생각해봅시다.

player_id
nickname
guild_id
guild_name
guild_master
item_id
item_name
item_price

이렇게 되면 같은 길드 이름이나 아이템 정보가 수많은 행에서 반복될 수 있습니다.

그래서

Player
Guild
Item
Inventory

처럼 데이터의 역할에 따라 적절하게 분리합니다.

그리고 PK와 FK를 사용해서 다시 연결합니다.

최종적으로 ERD가 만들어진다

이러한 과정을 거치면 최종적으로 게임 데이터베이스의 전체 구조를 표현할 수 있습니다.

예를 들어 간단한 RPG 데이터베이스라면 다음과 같습니다.

GUILDPK guild_idguild_namePLAYERPK player_idnicknamelevel · FK guild_idINVENTORYFK player_idFK item_id · quantityITEMPK item_iditem_name · price
Guild, Player, Inventory, Item ERD

이러한 그림을 **ERD(Entity Relationship Diagram)**라고 합니다.

길드, 플레이어, 인벤토리, 아이템 테이블의 PK와 FK 및 1대다 관계를 보여 주는 RPG 데이터베이스 ERD

관계형 데이터 모델링의 전체 흐름

지금까지의 내용을 하나의 흐름으로 정리하면 다음과 같습니다.

① 현실에서 관리할 대상 찾기
        ↓
② Entity 결정
        ↓
③ Attribute 결정
        ↓
④ Primary Key 결정
        ↓
⑤ Entity 사이의 관계 찾기
        ↓
⑥ 1:1 / 1:N / N:M 판단
        ↓
⑦ Foreign Key 설정
        ↓
⑧ 필요한 경우 정규화
        ↓
⑨ ERD 작성
        ↓
⑩ 실제 테이블 생성

게임으로 다시 생각해보면 어렵지 않습니다.

게임에는 무엇이 있지?
→ 플레이어, 아이템, 길드

플레이어에게 어떤 정보가 필요하지?
→ 닉네임, 레벨, 골드

플레이어를 어떻게 구별하지?
→ player_id(PK)

플레이어와 길드는 어떤 관계지?
→ 하나의 길드에 여러 플레이어
→ 1:N

플레이어와 아이템은?
→ 여러 플레이어가 여러 아이템을 가질 수 있음
→ N:M

N:M을 어떻게 저장하지?
→ Inventory 중간 테이블 생성

이런 판단을 반복하면서 데이터베이스의 구조를 만들어 나가는 것이 관계형 데이터 모델링입니다.

정리

**관계형 데이터 모델링(Relational Data Modeling)**은 현실의 데이터를 단순히 테이블에 집어넣는 작업이 아닙니다.

어떤 데이터를 독립적인 테이블로 관리하고, 각 데이터를 어떻게 식별하며, 서로 어떤 관계로 연결할 것인지 설계하는 과정입니다.

게임 데이터베이스를 예로 들면 다음과 같이 정리할 수 있습니다.

Entity
→ Player, Guild, Item

Attribute
→ nickname, level, price

Primary Key
→ player_id, guild_id, item_id

Foreign Key
→ Player.guild_id

Relationship
→ Guild 1 : N Player

중간 테이블
→ Player N : M Item
→ Inventory로 해결

정규화
→ 중복되는 데이터를 적절한 테이블로 분리

ERD
→ 위의 설계를 그림으로 표현

따라서 관계형 데이터 모델링의 핵심을 한 문장으로 표현하면 다음과 같습니다.

현실의 데이터를 역할에 따라 테이블로 나누고, PK와 FK를 이용하여 데이터 사이의 관계를 설계하는 과정이다.

관계형 데이터 모델링을 이해했다면 다음 단계에서는 ERD → 관계의 종류(1:1, 1:N, N:M) → 식별/비식별 관계 → 정규화(1NF, 2NF, 3NF, BCNF) → 실제 SQL 테이블 설계 순서로 이어가면 전체 흐름을 이해하기 좋습니다.

댓글 0

댓글을 불러오는 중…