간단히 말해서, 지식지도의 패턴은 한 분야의 데이터 모델과 동등하며, 이 분야에서 의미 있는 개념 유형과 속성을 포함하고 있습니다. 모든 영역의 패턴은 주로 유형과 속성으로 표현됩니다. 그림 1 은 plantdata 의 벤처 도식입니다. 주로 1 급 시장의 투자 융자를 탐구하기 위해 구축되었습니다. 이 모델은 주로 벤처 투자를 구축하기 전에 요구 사항과 벤처 투자에 유용한 데이터를 정의하는 것입니다. 예를 들어, 모든 인물은 키와 몸무게를 가지고 있지만, 이 수치들은 벤처 투자에 큰 의미가 없기 때문에 도식에서 건설할 필요가 없다. 벤처 투자에 관심이 있는 사람들은 이 자금과 인물이 어떤 회사에 투자했는지, 투자한 업종, 투자한 회사 유형 등을 모두 이 스키마에서 상세하게 구축해야 한다.
1. 도메인 구축 방법
정의도메인의 개념은 모든 유형 위에 있으며, 정의필드의 정의는 구체적이지 않고 가능한 한 추상적이어야 하며, 정의영역은 가능한 독립적이고 교차하지 않아야 한다. 예를 들어, 지방은 도메인 개념이 아니어야 합니다. 개념이 도메인이어야 하는지 생각할 때, 우리는 이 개념이 계속 추상화될 수 있는지 여부를 고려해야 한다. 예를 들면: 성; 도시; 국가; 현 등은 모두 지리적 위치에 속한다. 도메인의 개념을 정의할 때는 도메인 경계를 명확히 하여 서로 다른 도메인 간의 지리적 구분을 쉽게 구분할 수 있도록 해야 합니다.
도메인 유형을 어떻게 결정합니까?
여기서 제품 관리자는 이 모델을 구축하는 데 필요한 핵심 요구 사항과 사용자가 해결해야 할 문제에 대해 생각해야 합니다. 이러한 핵심 요구 사항을 충족하기 위해 어떤 개념을 만들어야 합니까?
예를 들어, 자동차 분야에서 사용자는 주로 자동차의 브랜드, 차계, 엔진 등과 같은 문제에 관심을 갖는다.
NBA 분야에서는 사용자가 주로 팀, 리그, 코치, 선수 등에 관심을 갖는다.
필요에 따라 사용자의 요구를 충족하기 위해 도메인 아래에 다양한 유형을 구축해야 합니다.
3. 재산을 결정하는 방법
사고의 관점은 다음과 같다.
1. 사용자 요구 사항부터 시작
2. 통계를 증거로 삼다
예를 들어, 축구 분야에서 팀 유형을 설정한 후 해당 유형은 사용자의 관점에서 모든 팀 엔티티와 트리거를 함께 수집합니다. 사용자가 관심을 가질 관계는 무엇입니까?
그림 2 는 메시 (팀의 선수), 에네스토 발웨이드 (팀의 코치), 시갑 (팀의 리그) 을 포함한 내가 축구 분야를 위해 만든 간단한 아틀라스로, 메시, 시갑, 에네스토 발웨이드는 각각 축구 선수, 축구 리그, 축구 코치 등 다양한 유형에 속한다
위 그림에서 상식은 그래픽 조회와 자연어 처리 기술로 기본적인 문답을 지원할 수 있다. 예를 들어 메시는 어느 팀입니까? 에네스토 발웨이드의 코치는 누구입니까? 서갑에는 어떤 팀이 차고 있습니까? 등등
모델의 적용은 제품 관리자가 고려해야 할 핵심 사항입니다. 제품 요구 사항에 따라 모델이 어떻게 구축되어야 하는지, 완전한지 여부가 결정되기 때문입니다. 그러나 제품의 구체적인 응용이 모델의 전체 구축 모델을 주도하고 있다. 제품 애플리케이션을 신중하게 고려하지 않으면, 가장 나쁜 경우는 긴 모델을 구축하면 하나의 논리적 구덩이로 인해 완전히 폐기될 수 있다는 것이다. (윌리엄 셰익스피어, 햄릿, 지혜명언) 지식지도는 전신을 움직이는 공사이기 때문에, 실제 경험에 따르면 지도 건설과 응용이 부분적으로 단절되면 지도 도식을 수정하는 데 드는 비용이 지도 도식을 재건하는 것보다 더 클 수 있다. 따라서 특정 응용 프로그램 시나리오를 확인하는 것이 패턴 구축의 성공에 매우 중요합니다.
작가는 패턴을 결정하는 일련의 과정을 집필했다.
먼저 수요 강도에 따라 기본 핵심 요구 사항, 패턴 특징 요구 사항, 금상첨화 요구 사항 및 향후 확장 요구 사항으로 응용 프로그램을 나눕니다.
기본 핵심 요구 사항: 수요 분석 후 이 모델을 구축하기 위해 완료해야 하는 핵심 요구 사항으로, 우선 순위가 가장 높습니다.
스키마 피쳐 요구사항: 지도를 작성할 때 다른 방법으로 수행할 수 있는 피쳐 요구사항이 자주 발생할 수 있습니다. 이러한 요구는 그다지 강하지 않을 수도 있지만, 종종 예상치 못한 효과가 있을 수 있다. 왜냐하면 어느 정도 차이를 이룰 수 있기 때문이다.
금상첨화: 기본이 아닌 핵심 수요, 잘 했어, 안 해도 받아들일 수 있어.
향후 확장성 요구 사항: 스키마를 결정할 때 향후 확장성을 충분히 고려해야 합니다. 이러한 요구 사항은 지도의 스키마 구조를 크게 바꿀 수 있기 때문입니다.
모델을 만들 때, 위의 분류에 따르면, 첫 번째 단계에서 패턴이 충족시켜야 할 특정 기능을 고려하고, 기능을 하나씩 나열하며, 두 번째와 세 번째 단계에서 완료해야 할 기능, 향후 확장을 위해 확장 가능한 내용을 남겨야 하는 영역을 고려해야 합니다.
일반적으로 사용되는 방법은 excel 을 사용하여 1, 2, 3 단계에 필요한 기능점을 나열할 수 있습니다.
위 기능점이 나열되면 각 기능점에 대해 기능 키가 뒤에 표시됩니다 (참고: 이것은 중요합니다). 일반적으로 수요는 제품 수요를 특정 질의 구조로 전환하기만 하면 됩니다. 저자는 처음에 cypher 쿼리 구문을 사용했습니다. 그림 2 를 예로 들다. 나는 코치가 어떤 선수를 가르쳤는지 지지할 것이다. 질의어로 번역하면 (a: 축구 코치)
과정은 다음과 같습니다: 문의: Ernesto Balwede 는 어떤 선수를 데려왔습니까? → 의미 분석 → 위의 쿼리로 변환, Ernesto valverde 를 매개 변수 A 로 쿼리 대체 → 결과 반환 → 프런트엔드 패키지 표시.
참고: 위의 각 기능 점 뒤에는 구성 점이 표시되어 있습니다. 대부분의 기능 점의 구성 점은 요구 사항 자체가 비교적 크면 서로 다른 요구 사항으로 인해 아키텍처 구성 충돌이 발생하기 쉽기 때문에 구성 점에 중점을 두어야 합니다. 앞서 언급했듯이 패턴은 가능한 적은 수의 오류를 보장해야 합니다. 이때 구조의 관건을 알아차렸기 때문에 전체적으로 이 도식 중간에 논리 블랙홀이 있는지 여부를 볼 수 있다. 일반적인 문제는 주로 속성 설계와 지식 통합에 있습니다.
위의 문서를 가지고 개발을 찾아가서 어떤 것이 더 잘 이루어지는지 확인해 보세요. 일반적으로 대부분의 수요 개발은 이 수준에 이를 것이다. 만약 학우를 개발하기에 충분한 전공이 있다면, 그는 그의 관점에서 너에게 그의 소중한 의견을 줄 것이다. 일반적으로 제품 관리자는 생각할 때 이 모델의 역할에 대해 생각하는 경향이 있으며 개발자는 엔지니어링 구현, 구현 효율성, 운영 효율성, 계산량 등에 대해 생각합니다.
대규모 빌드 모드에서 데이터 소스의 상황을 신중하게 고려해야 합니다. 회사마다 데이터가 다르기 때문에 그들은 다른 대책을 채택한다.
일반적으로 데이터 소스를 다음 범주로 나눕니다.
1. 청소된 구조화된 데이터: 이 데이터 부분은 일반적으로 본사 또는 다른 회사의 핵심 데이터이며 구축 시 우선적으로 고려해야 합니다. 이 데이터 부분은 일반적으로 데이터 형식을 변경하기만 하면 지도에 들어갈 수 있다.
2. 깨끗하고 구조화된 데이터이지만 데이터가 불완전합니다. 이 데이터 부분은 일반적으로 데이터 마이닝과 지식 융합이 필요합니다. 세척의 난이도는 결함의 비율에 따라 결정된다.
데이터 없음: 그러한 데이터는 없지만 필요합니다. 일반적으로 BD 에서 데이터를 구입하거나 전문 웹 사이트에서 파충류를 잡을 수 있도록 선택할 수 있습니다. 예를 들어, 기업 데이터는 확인할 수 있고, 영화 데이터는 확인할 수 있으며, 산업 데이터는 산업 정보 인터넷에서 확인할 수 있습니다.
구성할 아틀라스 엔티티 수가 천만 수준이고 개발력이 충분히 강하지 않다고 가정하면 순수 데이터 마이닝 시나리오를 신중하게 사용해야 합니다. 가능하면 구조화된 데이터를 직접 구입하는 것이 좋습니다. 발굴과 지식 융합의 경제적 비용이 직접 구매하는 데이터보다 높을 수 있고 기간이 길어질 수 있기 때문입니다.
개인적으로 대규모 모델 구축이 가장 어려운 부분은 데이터 마이닝의 지식 융합에 있다고 생각한다. 예를 들어 중국에는 왕강이라는 사람이 10000 명 있는데, 파충류는 A 웹사이트에서 5,000 개의' 왕강' 을 파고 B 웹사이트에서 7,000 개의' 왕강' 을 파냈는데, 이 5000 명의 왕강과 그 7000 명의 왕은 방금 혼자였나요? 어떤 왕강이 주민등록번호가 없는 사람인지 어떻게 알 수 있습니까? 일반적인 방법은 왕강의 다른 정보 (예: 생년월일, 취업 정보, 출생지 등) 를 발굴한 다음 특정 알고리즘을 통해 지식을 융합하는 것이다. 일반적으로 웹 사이트의 데이터는 반드시 포괄적이지는 않습니다. 지식이 융합된 후에도 발굴된 데이터에는 많은 소음이 있을 수 있으며, 요구 사항에 따라 소음에 대한 관용도 다릅니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 지식명언) 패턴을 만들 때 데이터에 소음이 있을 가능성을 충분히 고려하여 소음에 대한 수요의 허용 가능성을 평가해야 합니다.
지식 융합이 완료되면 대규모 구축은 실제로 데이터 선도 프로세스입니다. 지도집의 데이터 구조 때문에 일반적으로 두 개의 테이블 (점과 모서리) 을 저장하거나 RDFs 를 사용합니다. 솔리드 수천만 후 지도의 조회 압력이 더 커지고 독립 실행형 조회가 직접 끊어질 수 있습니다. 개발은 일반적으로 graphX 를 사용하는 분산 스토리지를 개발하지만 접선 절단 문제로 인해 부작용이 생길 수 있습니다.