Neo4j: The Definitive Guide

3장. 모델링 결정 재검토하기

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

그래프 모델링( )은 비즈니스의 사용 사례를 명확히 이해해야 하는 직관적인 프로세스입니다. 관계형 스키마 설계와는 다르며, 유연성과 고정된 규칙이 없기 때문에 처음에는 당황스러울 수 있지만, 프로세스에 익숙해지면 보람 있는 작업이라는 것을 알게 될 것입니다.

1장에서 만든 그래프를 사용하여 다음 쿼리 중 몇 가지를 시도해 보겠습니다.

상황에 따라

트랙, 앨범, 아티스트 및 그 장르가 포함된 데이터 세트가 주어졌고 관계형 데이터베이스 관리 시스템(RDBMS)을 위한 스키마를 설계하려고 한다고 가정해 보겠습니다. 아마도 익숙한 정규화 규칙 세트를 적용하여¹ 을 적용하여 그림 3-1과 같이 비슷한 구조적 모델(테이블과 열 이름은 다를 수 있음)을 만들 수 있습니다.

그림 3-1. RDBMS의 스키마

이것을 어떻게 그래프로 모델링할까요? 노련한 그래프 모델러라면 "상황에 따라 달라집니다!"라고 대답할 수 있을 것입니다. 정말요? 네, 그렇습니다. 그림 3-2에서 3-4는 세 가지 그래프 모델을 보여 주며, 모두 유효합니다.

그림 3-2. 장르를 아티스트의 속성으로 모델링하는 모델 A.

그림 3-3. 장르는 노드이고 앨범은 모델 B의 속성입니다.

그림 3-4. TRACK_VERSION 노드와 장르를 레이블로 사용하는 모델 C

데이터 집합에 더 많은 엔티티를 추가하면 가능한 모델의 수가 늘어납니다. 어떤 모델도 틀린 것은 없으며, 사용 사례에 따라 적합성이 달라집니다. 그렇기 때문에 노련한 그래프 모델러라면 "그래프가 어떤 질문에 답하기를 원하십니까?"라고 묻는 것이 좋습니다. 사용 사례에 따라 그래프에 대한 질문에 답하고 효율적인 쿼리를 수행하기 위해 어떤 모델이 최적인지 결정됩니다.

팁

다른 모든 것과 마찬가지로 단순하게 유지하는 것이 좋습니다. 필요한 만큼만 모델링하고 그 이상은 하지 말고 조급하게 최적화하지 마세요.

그래프 모델은 언제든지 리팩터링할 수 있으며, 이는 안티패턴으로 간주되지 않습니다. 그래프 모델은 비즈니스의 변화에 따라 지속적으로 진화해야 ...