웹 서비스 및 데이터 모델링

데이터 분류

데이터 항목에는 한번 등록되면 자주 변경되지 않는 타입(마스터 데이터)과 자주 변경/추가되는 타입(트랜잭션 데이터)이 있음

마스터계의 테이블

몬스터(적)의 데이터나 직업의 데이터 등

전체 레코드 수가 그다지 많지는 않음

콘솔 게임에는 용량 관계도 있기 때문에 값비싼 데이터베이스가 아닌 프로그램으로 관리하는 경우도 적지 않지만, 서버 측이라면 관리 효율성 쪽이 우선되기 때문에 비록 항목이 적어도 다른 데이터와 같이 데이터베이스에서 관리하는 것이 정석임

트랜잭션계의 테이블

테이블 관련

일대다 관계

파생 관계(1대 0..1형)

일대다 테이블에 비해 빈도는 적지만 등장하는 상황은 많이 있음

소셜 게임에서의 전형적인 예는 아이템

아이템이라고 해도 소비 아이템도 있고, 무기, 방어 아이템도 있음. 아이템마다 분류가 존재


아이템
	- 아이템ID(PK), 이름, 아이템 종류, 게임내 가격, 설명문, 등록일

공격계 아이템
	- 아이템ID(PK), 공격력, 공격 속성, 사용 횟수 상한

방어계 아이템
	- 아이템ID(PK), 방어력, 방어내성, 사용 횟수 상한

소비 아이템
	- 아이템ID(PK), 효과 범위

파생 관계의 예. 아이템 테이블 중에 아이템 종류라는 데이터 항목을 제공하여 해당 아이템의 종류에 따라 공격/방어/소비 아이템 중 하나가 되는 형식임

소셜 게임에서는 파생 관계를 사용하는 상황이 많음

예를 들어 시한 이벤트에서는 이벤트 전용의 테이블 제공. 이 테이블의 기본 키는 사용자 ID이거나 또는 사용자 ID + alpha. 두 경우 모두 메인인 기본 키를 동일 테이블과 분리하는 것이 일반적임

데이터 모델링 관점에서 이벤트에 참가하는 사용자와 참가하지 않는 사용자가 있음. 따라서 사용자 ID로 봤을 때 관련은 1대 0..1이 되어 파생 관계를 사용해야 할 상황이라고 말할 수 있음

테이블이 나눠져 있으면 제거하기도 편함

계층 관계

ID	미션명	상위 ID
A	미션 A	B
B	미션 B	D
D	미션 D	I
F	미션 F	I
I	미션 I	-

ID	미션명	계층구분	상위 ID
A	미션 A	0	B
B	미션 B	1	D
D	미션 D	2	I
F	미션 F	2	I
I	미션 I	3	-

미션 A를 클리어하면 미션 B가 출현

미션 B를 클리어하면 미션 D가 출현

미션 D와 F를 클리어하면 미션 I가 출현

일반적으로 이러한 마스터 데이터는 운영 측이 수동으로 등록하지만, 등록을 주의하지 않으면 무한 루프에 빠질 수 있음. 등록 오류를 회피하려면 오른쪽 테이블의 계층 구분 을 도입하여 자신이 지금 어느 계층에 있는지를 열로 갖게 하는 방법이 있음

계층형 부품표 타입

피라미드형의 계층 관계의 약점을 극복하는 모델로서 알려져 있는 것이 계층형 부품표 라고 불리는 데이터 모델임

몇 가지 직업을 다 소화해 내면 새로운 직업으로 전직할 수 있음

새로운 직업의 후보는 한 개가 아닌 복수의 직업이 새로 나타날 수 있음

계층형 부품표 모델의 특징은 두 테이블 사이에 일대다 관계가 두 개 존재한다는 점
어떤 부품과 다른 부품을 조합함으로써 별도의 정해진 부품이 만들어진다
완성된 부품과 또 다른 부품을 조합하면 다른 부품이 생긴다
조합한 부품이 세 개 이상 있다 라는 복잡한 구조도 이것으로 처리 가능

직업 ID	직업명
1	전사
2	무술가
3	승려
4	마법사
5	무희
6	광대
7	음유시인
8	배틀 마스터
9	팔라딘
10	현자
11	슈퍼스타
12	갓 핸드

상급직 ID	하급직 ID	필요 레벨
8	1	-
8	2	-
9	2	-
9	3	-
10	3	-
10	4	-
11	5	-
11	6	-
11	7	-
12	8	-
12	9	-

전사(1) + 무술가(2) → 배틀 마스터(8)

무술가(2) + 승려(3) → 팔라딘(9)

승려(3) + 마법사(4) → 현자(10)