데이터 모델링이란? (그래프 DB 편)

 

지난 편에는 항공 예약 시스템을 예시로 하여 관계형 DB로 나타내는 데이터모델링을  상세히 살펴보았다. 이번 글은 ‘데이터 모델링이란? (RDB편)’에서 예고했듯이, 그래프 데이터베이스에 주목하여 GDB 개념 정의와 함께 GDB의 데이터 모델링을 알아보고자 한다. 

 

본 문서는 그래프 데이터베이스를 처음 접하거나 분석을 위한 모델링에 애로사항을 겪는 사람들에게 도움이 될 수 있다. 

 

GDB에서의 데이터 모델링

그래프 데이터 모델은 일반적인 소셜 네트워크 서비스 외에도 다양한 데이터 도메인의 표현이 가능하다. 지난 RDB편에 이어서 이번에도 항공 예약 시스템을 예시로 살펴본다. 

GDB 구성요소

먼저 그래프 데이터 모델을 설계하는 과정을 잘 이해하기 위한 그래프의 주요 구성요소를 설명한다. Property graph는 다음과 같은 구성요소를 가지고 있다.

 

항공 예약 시스템 요구 사항 파악

 

Vertex (Node)

객체 하나에 대해 표현하는 단위이다. 노드는 데이터의 이름-값 쌍을 보유하는 속성을 포함할 수 있다. 또 하나 이상의 Label을 사용하여 노드에 역할 또는 유형을 할당할 수 있다. 해당 제품에서는 JSON의 형태로 표현이 가능하다.

Edge (Link / Relationship)

객체 간 관계를 표현하는 단위이다. 관계 타입과 데이터 관계 간 특성을 표현하는 속성값으로 표현한다.

Label

유사한 속성을 가진 그룹을 표현하는 단위이다. 사람, 동물, 자동차와 같이 각 객체를 공통으로 정의할 수 있는 레이블 명을 이용하여 표현한다.

  

모델링의 과정은 RDB에서의 과정과 유사하지만, 진행 상황을 살펴보면 다른 점을 알 수 있다. 

 

1. 요구사항 파악

해당 과정은 RDB와 같다.

 

2. 개념적 데이터 모델 설계(화이트보드 모델링)

해당 과정에서는 명료성, 적절성, 고유성, 일관성을 고려한 Naming Rule을 설정한다. 주제 영역별 주요 노드와 개별 노드 간의 엣지 도출이 가능하다. 이를 화이트보드에 그리듯이 자유롭게 진행한다.

 

3. 논리적 데이터 모델 설계

노드, 레이블, 엣지에 대한 정의가 이루어진다. 그래프 데이터 모델 설계도의 작성 및 검증을 통하여 이루어진다.

 

항공 예약 시스템 논리적 데이터 설계 GDB

 

 

4. 물리적 데이터 모델 설계

해당 단계에서는 Property의 정의가 이루어진다. 모든 레이블(노드, 엣지) 혹은 Unique Constraint Index가 필요한 Property를 정의한다. 시스템 구성의 설계와 데이터의 용량 산정과 같이 물리적으로 모델 설계에 접근한다.

 

GDB 모델링 TIP

그래프 모델링에 대해 옳고 그른 방법은 없다. 어떤 방법이 적합하고 우선순위를 정하는 측면에서 뛰어난 성능을 발휘할 수 있는지는 모델링을 수행하는 사람의 선택에 달렸다. 요구 사항에 가장 적합한 데이터 모델을 찾으려면 몇 가지 기술로 접근하고 해당 분석에서 데이터 모델 결정을 내리는 것이 도움이 되는 경우가 많다. 아래는 데이터 모델을 결정하는 데 도움이 되는 방법들에 관해 설명한다.

 

쿼리 작성과 우선순위 지정

데이터에 관해 물어볼 질문과 쿼리의 구성에 대해 알고 있으면 데이터 모델의 구조를 결정하는 데에 도움이 된다. 쿼리가 특정 날짜의 범위 내에서 결과를 반환해야 함을 알고 있을 때 날짜는 노드의 속성이 아닌 별도의 노드 또는 관계로 저장해야 할 것이다. 아직 정확한 쿼리 구성을 모르더라도 구축 중인 시스템의 목적을 이해한 후 요구 사항을 중심으로 모델을 구성하면 보다 정확한 방식으로 데이터 모델링의 수행이 가능하다.

모든 쿼리 또는 기능에 대한 완벽한 모델을 찾는 것은 매우 어렵다. 특정 사항을 개선할 수는 있지만 모든 것에 적용할 수 있는 방법 대신 사용자의 요구에 가장 적합한 모델을 결정해야 한다. 최대 성능을 갖는 쿼리와 목적을 달성하는 데 중요한 역할의 쿼리 중 선택할 수 있도록 한다. 필요에 따라 쿼리의 우선순위가 조정되면 모델을 더욱 유연하게 구현할 수 있다.

 

Node/Edge Property 설정

노드는 실존하는 개체(엔티티), 엣지는 구조(엔티티 간의 관계 및 의미)를 표현한다. 노드의 속성은 엔티티의 속성이나 메타 데이터를 나타나게 정의하고 엣지의 속성은 관계의 강도 또는 관계의 속성, 메타데이터를 나타내도록 정의한다. 

 

관계의 표현

능동-수동 관계 또는 양방향으로 표현되는 관계는 모두 표현하지 않고 하나로 표현하도록 한다. 이때, 속성을 이용한 방향 규칙을 만드는 것이 좋다. 그러나 규칙 없이 무작위로 한쪽만 표현하고자 하면 쿼리 작성 시 ‘-[]-’ 또는 ‘<-[]->’를 사용한다. 또, 다수의 노드 간 하나의 관계에서 발생하는 시스템의 경우 관계 노드를 생성하는 것을 권장한다. 

 

모델 테스트 수행

디자인 단계에서 알아채지 못한 시나리오를 접할 수 있음으로 실제 모델 테스트를 통해 이와 같은 문제를 해결할 수 있다. 또, 하나 이상의 모델을 결정할 경우 각 모델에 대한 개념 증명 테스트를 만들고 두 모델이 어떻게 작동하는지 확인해야 한다. 테스트를 통해 데이터의 일부를 로드하고 시스템에서 테스트 및 쿼리를 수행하며 도출된 결과가 요구사항 또는 성능에 맞는지 직접 눈으로 확인할 수 있다.

 

예외의 경우

먼저, 엣지는 줄이고 Property로 해결하여 무분별한 노드 및 엣지의 생성을 자제한다. 만약 실체 하는 그래프 관계에서, 노드보다 엣지가 월등히 많다면, Line graph 변환을 활용하여 GDB 모델링을 수행한다. 이는 고밀도의 노드로 인하여 문제가 발생할 수 있다. Line graph는 원래 그래프인 노드-엣지 관계를 엣지-노드 관계로 치환한 그래프이다. 너무 많은 종류의 Property로 인해 노드의 덩치가 커지는 경우, 엣지로 분리를 고려한다.

 

Line Graph로의 변환과 역변환

 

베이지안 네트워크 모델링의 경우 그래프 데이터 모델과는 별개로 생각한다. 베이지안 네트워크 모델링의 경우는 모델링하는 로직이 완전히 다르므로 기본 룰을 무시할 수 있다. 로그성 데이터나 매우 긴 속성값을 저장하는 경우에는 RDB가 보다 효과적이다.

 

Fine grain label이 generic label with property보다 컴퓨팅 측면에서 더 효과적이다.

연결되지 않는 그래프(Unconnected Graph)는 그래프로 저장하기 비효율적이거나 비생산적인 패턴이기 때문에 GDB를 사용할 필요가 없다.

 

RDB에서의 데이터 모델링이 완료되었을 때 같은 과정을 되풀이하지 않고 특정 규칙에 따라 GDB 데이터 모델로의 변환이 가능하다. 아래는 규칙에 따른 관계형 데이터 모델에서 그래프 데이터 모델로의 변환 방법에 대해 알아본다.

 

RDB to GDB

어떤 관점에서 보면 GDB는 RDBMS에서 Foreign Key를 통하여 불명확하게 나타내던 관계를 명확하게 표현한 다음 세대의 RDBMS로 생각할 수 있다. Native graph property 모델에서는 각각의 노드(혹은 데이터 객체)에 대한 관계가 직접적이고 물리적으로 형성된다. 이러한 관계들은 형태와 방향성을 가지고 있으며, 추가적인 관계 관련 정보를 갖는다. GDB의 특징은 기존 테이블 간의 조인 수행 시 고비용의 search-and-match 계산이 필요했던 RDBMS와 달리 노드 간의 이동만으로 필요한 데이터를 찾을 수 있다. 

 

먼저 표현된 RDB 데이터 모델을 GDB로 변환하기 위해서 아래와 같은 과정을 거친다. 앞서 들었던 항공 예약 시스템의 RDB 데이터 모델링을 GDB로 변환시켜보며 과정을 확인할 수 있다.

 

항공 예약 시스템 RDB to GDB (1)

 

1. 각각의 객체 테이블은 노드의 레이블 형태로 변환

2. 테이블 내 행(Row)은 노드로 변환

3. 테이블의 속성값(열, Column)은 노드 Property로 변환

4. 테이블 내 물리적 Primary Key 제거 (단, 논리적 Key는 유지)

5. 전환 데이터 Primary Key에 Unique Constraint 적용

6. 필요 속성값에 인텍스 생성

7. 테이블 Foreign Key를 관계로 변환 후 제거

8. 열 중 Default Value를 가진 경우 제거 (GDB에서는 불필요)

9. 성능상 혹은 업무상 목적으로 만들어진 비정규화 테이블들은 별개의 노드로 분리

10. JOIN 테이블들은 관계로 변환, JOIN 테이블 내 Foreign Key와 데이터 열 존재 시 관계 property로 변환

 

완료된 GDB 데이터 모델로의 변환은 다음과 같다.

 

항공 예약 시스템 RDB to GDB (2)

 

이제까지 간단한 예제를 통해 RDB와 GDB의 데이터 모델링을 수행해보며 과정을 알아보고 비교하여 각 방법의 장단점을 알아보았다. 이론적으로 접근하여 설명했으나 실전에서 사용되는 모델링 방법은 고려 사항이 더 많아서 접근이 어려울 수 있다. 

 

다음 편 예고: 그래프 모델링으로 알아보는 FDS

다음 편은 분석관점에서의 모델링을 설명하기 위해 실제 GDB모델링의 예시를 들어 설명할 것이다. FDS(이상거래탐지시스템)를 예시로 한 글이 올라오기 전까지는 ‘그래프 모델링으로 알아보는 지식 그래프’를 참고하면 본 글에 다룬 그래프 DB 모델링을 이해하는데 도움이 될 것이다.

 

 

관계형 DB와 그래프 DB, 언제 사용해야 할지 궁금하다면?

정합성의 RDB, 분석력의 GDB, 그리고 두 장점을 가진 RGDB

 

글: 비트나인 그래프 AI 센터

 

 

 

---

 

멀티모델 그래프데이터베이스 AgensGraph

60일간 무료로 사용해 보세요

bitnine.net/agensgraph-downloads/

 

제품 및 기술문의

070-4800-3517  |   agens@bitnine.net