4장. 모델링 및 리팩터링 패턴
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
이제 그래프 모델링의 원리를 익혔으니 다른 모델링 패턴을 살펴볼 준비가 되었습니다. 이러한 패턴을 언제 적용해야 하는지 인식하고 장단점을 비교하는 방법을 배우게 됩니다. 조만간 사용 사례와 모델이 발전함에 따라 그래프를 리팩터링해야 하므로 이 장의 후반부에서는 실습을 통해 패턴을 리팩터링하는 방법을 안내합니다.
하이퍼엣지: N-방향 관계
모두가 노래 커버에 관심을 보이는 새로운 트렌드가 있습니다. 일렉트릭하모니는 청취자들이 좋아하는 곡의 커버를 쉽게 찾을 수 있도록 도와주는 새로운 기능을 도입하여 이 흐름에 동참하고자 합니다. 이 기능은 좋아하는 트랙이 실제로 커버곡인지, 그렇다면 원곡자가 누구인지 알아내는 데 도움이 될 것입니다. 이 사용 사례를 모델링하기 위해 다시 한 번 팀과 함께 화이트보드에 앉았습니다.
가장 확실한 시작 방법은 그림 4-1에서처럼 아티스트의 트랙 녹음이 커버인지 아닌지를 ARTIST 과 Track 의 관계에 지정하는 것입니다.
그림 4-1. ARTIST 관계를 정량화하여 트랙이 커버곡인지 아닌지 표시하기
좋은 모델링 관행에는 기존 사용 사례를 다시 살펴보고 리팩터링이 사용 사례에 영향을 미쳤는지(아마도 부정적인 영향을 미쳤는지) 확인하는 것이 포함됩니다. 핵심 사용 사례인 트랙 아티스트 불러오기를 즉시 떠올려 보세요. 지금까지 일렉트릭하모니는 항상 트랙의 원래 아티스트를 표시하는 쪽으로 기울어져 왔고, 이 방식이 변경되기를 원하지 않았을 것입니다. 그러나 이제 이 정보가 관계의 프로퍼티에 포함되어 있으므로 Neo4j는 TRACK 에서 모든 ARTIST 관계를 트래버스하고 cover 프로퍼티 값을 검사한 후 대부분을 버리는 추가 작업을 수행합니다. 이는 큰 문제는 아니지만(트랙에 아티스트 수가 매우 많은 경우는 드물기 때문에), 팀에서는 이것이 올바른 해결책이라고 생각하지 않습니다.
대신 이전 장에서 관계 세분성에 대해 배운 내용을 바탕으로 새로운 관계 유형인 COVERED_BY ( 그림 4-2 참조)을 도입하기로 결정합니다.
그림 4-2. COVERED_BY 은 아티스트가 트랙을 커버했다는 사실을 나타내기 위해 도입된 새로운 관계 유형입니다.
이렇게 하면 주요 사용 사례는 방해받지 않습니다. Neo4j는 커버를 가져오거나 반대로 특정 아티스트가 커버한 모든 트랙을 찾아야 할 때 COVERED_BY 관계를 탐색합니다.
어떤 버전의 트랙을 연주한 아티스트를 찾으려면 어떻게 해야 할까요? 패턴에 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access