neo4j 예제 - 그래프와 관계 개념

Question

저는 그래프 데이터베이스에서 초보자입니다. 관계형 mySQL을 약간 다루기 전에 저와 잘 지내십시오.하지만이 분야에서도 전문가라고 생각하지는 않습니다. 나는 데이터베이스 설계와 관련하여 12이라는 질문을 발견했지만 내 문제에 대한 당신의 의견을 알고 싶습니다. 내 Cypher 쿼리를 테스트 할 수있는 샘플 데이터 세트를 직접 만들고 싶습니다. 내 마음에 떠오르는 분야는 LastFM과 같은 음악 청취자를위한 소셜 네트워크와 유사한 데이터 세트입니다. 내 소셜 네트워크의 나는 또한 사용자를 만든 사람 (안 밴드 멤버)으로

(nir:Band { name: "Nirvana", town: "Seatle", country: "USA", genere: "Grunge" }) 
(dgr:Person { name: "Dave Grohl", born: 1969, instrument: "drums" }) 

:

그래서 내 첫번째 생각은 노드 밴드와 사람의 두 가지 유형을 작성했다.

(dgr)-[:IS_MEMBER_OF {from: 1987, to: 1994} ]->(nir) 
(user1)-[:IS_FRIEND_OF]->(user6) 
(user1)-[:LIKES]->(nir) 

그런 다음 나는이 개념은 내가 지금 볼 수있는 최소 세 가지 제한 사항이 실현 : 내가 가진 관계의 유형이있다

밴드가 하나 개의 장르 만 분류 할 수있다
2. 밴드는 한 도시/국가에서만 시작될 수 있습니다.
3. 밴드 회원은 회원이 된 모든 밴드의 한 악기에서 재생할 수 있습니다.

처음 두 가지 문제를 해결하기 위해 먼저 Python 등에서 알 수 있듯이 배열과 비슷한 일부 데이터 유형에 대해 생각했습니다. 이 배열에서는 하나 이상의 요소 (여러 장르 또는 여러 도시 및 국가)를 저장할 수 있지만 neo4j의 배열에 대해서는 찾지 못했습니다. 그럼 난 모든 제한이 우아 neo4j에 의해 자연적으로 해결 될 수 있다는 것을 깨달았다 필요한 유일한 것은 노드와의 관계 수정 약간입니다 :

(nir:Band { name: "Nirvana" }) 
(foo:Band { name: "Foo Fighters" }) 

(dgr:Person { name: "Dave Grohl", born: 1969 }) 

(grn:Genere { name: "Grunge" }) 
(rck:Genere { name: "Rock" }) 

(dgr)-[:IS_MEMBER_OF {from: 1987, to: 1994, instrument:"drums"} ]->(nir) 
(dgr)-[:IS_MEMBER_OF {from: 1994, to: 1998, instrument:"drums"} ]->(foo) 
(dgr)-[:IS_MEMBER_OF {from: 1998, to: 2014, instrument:"guitar"} ]->(foo) 

(stl:Town { name: "Seatle" }) 
(por:Town { name: "Portland" }) 

(usa:Country { name: "USA" }) 

(stl)->[:IS_IN]->(usa) 
(por)->[:IS_IN]->(usa) 

(nir)->[:IS_FROM]->(stl) 
(nir)->[:IS_FROM]->(por) 

(nir)->[:PLAYS]->(grn) 
(nir)->[:PLAYS]->(rck) 

(user1)-[:IS_FRIEND_OF]->(user6) 
(user1)-[:LIKES]->(nir) 

마지막으로 내 질문 :

1. 은 내가 말할 수 있습니다 위에서 언급 한 제한 사항에 만족하고 은 내 필요에 완벽하게 맞습니다 (밴드는 한 도시에서만 발생합니다). 아직도 노드 유형 (타운, 컨츄리, 장르)을 가지고있는 것이 더 좋았던 것처럼 언급 되었습니까? 완전히 다른 노드 유형을 크래킹하는 것보다 이미 존재하는 노드에서 속성을 사용하는 것 (성능) 이점이 있습니까? 예를 들어 나타내는 노드가 과 관련됩니다. 악기 또는 미래의 관점과 완전히 다른 무언가?
2. 관계형 데이터베이스에는 m : n 관계가있을 때 조인 테이블이 필요하다는 규칙이 있습니다. 그래프 데이터베이스에도 적용 할 수 있지만 조인 테이블 대신 새 노드 을 작성해야합니다 (Town, Country, Genre)?

   가 @Michael 기아에 회신

이

편집 instrument이 IS_MEMBER_OF 관계의 구성원 인 경우 "당신은 쿼리하는 자신에게 물어 봐야은/사용 사례는 당신이 그것으로 해결 싶어"또는 instrument 경우 회원입니다 Person 나는 원하는 데이터를 얻기 위해 여전히 (아마 Cypher 쿼리가 더 서투른 것처럼 보일 수있다.) 잘 모르겠다. 미국에서 온 밴드에서 연주 한 모든 드러머를 보여주세요.물론 앞에서 언급 한 제한 사항으로 제한됩니다 (사람은 하나의 악기에서만 연주 할 수 있습니다). 내 질문은 그 제약 (첫 번째 제안 스키마)을 알고 있다면 다른 (두 번째 제안 스키마) 데이터베이스 모델을 만드는 것이 합리적이라면 나는 그것들에 만족한다. 처음에 두 번째 제안 된 스키마가있는 이점이 있습니까? 지금 볼 수있는 것은 첫 번째 스키마와 달리 두 번째 스키마가 잘 조정된다는 것입니다. 성능과 같은 것이 있습니까?

"밴드 멤버십을 노드로 모델링하는 것이 흥미로울 수 있습니다. 그런 다음이를 계기 노드, 시간 트리 (연도 -> 월 -> 멤버십)에 연결하거나 주문 (다음 관계 있음). " 이 간단한 CYPHER 예제를 게시 할 수 있습니까? 나를 상상하기는 어렵다.

"그래프 데이터베이스는 관계를 미리 구체화하고 연결하는 노드와 함께 저장합니다." 다음 두 가지는 기본적으로 성능 측면에서 동일한 것을 의미합니까? 두 관계 모두 노드를 연결하기 때문입니다.

CREATE (dgr:Person {name:"Dave Grohl", instrument: "drums"})-[:IS_MEMBER_OF]->(nir:Band {name:'Nirvana'}) 
CREATE (dgr:Person {name:"Dave Grohl"})-[:IS_MEMBER_OF {instrument: "drums"} ]->(nir:Band {name:'Nirvana'}) 

Answer 1

두 번째 모델은 정말 멋지게 보입니다. 자신이 원하는 모든 쿼리/유스 케이스를 지원한다면 스스로 해결해야하는 쿼리/유스 케이스를 스스로에게 물어야합니다.

밴드 멤버쉽을 노드로 모델링하는 것이 흥미로운 경우에는 계기 노드, 시간 트리 (year-> month-> membership)에 연결하거나 주문 (다음 관계 있음).

조인 테이블에 관한 질문.

그래프 데이터베이스에서는 이러한 관계가 필요하지 않지만 관계는 역할을 수행합니다 (그러나 조인 테이블은 구현하지 않습니다). 그래프 데이터베이스는 관계를 미리 구체화하고 에과 연결된 노드를 저장합니다. 따라서 조인을 따라 쿼리하는 것은 데이터베이스의 기존 레코드를 따르기 때문에 값 비싸지 않습니다.

따라서 기술 기본 및 외래 키가 필요하지 않습니다. 이해할 수있는 유일한 점은 엔터티를 조회하는 데 사용할 속성을 인덱싱하는 것입니다. : Person (이름), : Band (이름), 장르, 국가 및 마을에서 동일합니다 (이름으로 검색하려는 경우).

시작하는 데 도움이되는 유용한 도구는 http://graphgen.neoxygen.io 그래프 생성기 예입니다.

관심이있는 경우 음악 도메인에 대한 몇 가지 데이터 세트 및 기사도 있습니다. http://www.neo4j.org/misc/music (musicbrainz 데이터 세트는 구식이며 업데이트해야합니다).