图形数据库 (图形数据库neo4j)

图数据库源于欧拉和图实践，也被称为面向/基于图的数据库，其英文对应为Graph>常识图谱的存储于检索

常识图谱是一种形容理想环球中实体、事情、概念及其相关的有向图结构。

其基本构成单元是理想，通常以RDF的结构示意，蕴含实体、属性及属性值和相关。

常识图谱指标是构建一个片面的理想环球常识库，允许智能问答、消息检索等运行。

存储是常识图谱的两大基本配置之一，包括基于表结构和图结构的存储。

基于表结构的存储方式有三元组表、类型表、思索层级相关的类型表和相关型数据库。

三元组表以三元组方式存储理想，结构繁难，易于了解，但存在单表过大和结构繁多的缺陷。

类型表为每种类型构建一张表，同一类型的实例存于同一表中，可以防止表过大疑问，但或者形成冗余。

相关型数据库经常使用二维表结构存储数据，具有二维表的属性限度，实用于存储结构化数据，但不允许结构或数组类型的属性。

基于图结构的存储方式驳回图数据库。

图数据库将实体视为节点，相关视为带有标签的边，基于有向图实践存储数据。

图数据库的外围概念包括节点、边和属性。

Neo4j、OrientDB、HyperGraphDB和InfiniteGraph等是经常出现的图数据库系统，它们各有特点，如Neo4j高性能、本地化操作、开源好处；OrientDB文档-图混合特性；HyperGraphDB的超图概念；InfiniteGraph的散布式特性。

图数据库的查问言语通常驳回SPARQL，用于口头子图婚配等特定查问。

常识图谱的查问关键经过数据库系统成功，相关型数据库经常使用SQL言语，图数据库经常使用SPARQL言语。

SQL言语分为数据查问、数据操纵、数据定义和数据控制四局部，提供访问数据的接口。

SPARQL言语是图数据库普遍允许的查问言语，用于失掉和治理数据，与SQL言语相似，是一种结构化的查问言语。

常识图谱的查问不只仅是数据检索，更关键的是经过图查问技术成功特定查问图的查找，即子图婚配疑问。

常识图谱产品设计与Schema定义(KG-PM系列)

与@伟哥微信意识一个多月了，两周前约见并关于常识图谱的一些疑问和想法启动讨论，感谢伟哥带着电脑并向我展示了他们的产品。

整个讨论以伟哥展示他们的产品为主线，围绕如何了解KG、to B KG产品设计谋略、to B KG产品的开展方向三大块启动讨论交换。

关于如何了解KG，先来看学术界的定义：常识图谱是结构化的语义常识库，用于以符号方式形容物理环球中的概念及其相互相关，其基本组成单位是『实体-相关-实体』三元组，以及实体及其相关属性-值对，实体之间经过相关相互结合，构成网状的常识结构。

关于上述定义有两点不懂：1.上方所说的相关是底层存储时以相关的方式存储，还是下层以相关的方式展现/运行，究竟什么样的图产品可以称之为常识图谱？的Schema如何设计，设计要点在哪，以及流程是什么样的？过后并未对第1点达成分歧，起初伟哥提到一个新框架：图平台 + 算法平台 + 运行平台是不是有点形象，先来拆分一下：在了解了伟哥展示的产品后，发现一个疑问，（要吐槽了，伟哥勿打），作为细分行业to B产品，该产品只是基于已有数据做了图的展现，启动数据的图相关展现、查问搜查、门路打点衔接、数据散布展现等。

用我原话说：“觉得这个产品没有灵魂，没有外围竞争力”。

为什么这么说呢？是，该产品将数据的相关梳理分明，正当展现，以及展现数据在各个区段内的散布，能在短期间内发现数据之间的关联，繁难业务人员启动检查了解相关盲区、数据盲区，缺陷是基于数据的各条线路过于普遍、错乱，不能协助业务人员有针对性的剖析发现疑问、聚焦疑问，为决策提供有效协助，属于一个消息聚合产品。

因此，伟哥这个KG产品只能算是图平台。

我的想法是可以依据业务场景梳理思想逻辑，形象出规定，依据如今的数据相关基于某条规定、某条线路启动推理，依据一些算法如聚类、分类、关键点发现等等去开掘业务疑问点，真正做到让数据撑持业务决策，属于基于图谱成功算法对标业务场景。

这一层触及到详细的业务运行，算是运行平台。

据我对国际业界的了解，大多KG公司关于构建图平台曾经不是难点了，艰巨在于依据业务场景构建运行平台与算法平台，以及由运行平台与算法平台反哺图平台。

下一步KG的开展方向应该聚焦基于图平台的运行平台设计。

针对第2点，KG的Schema如何设计，设计要点在哪，以及流程是什么样的？KG的Schema相当于畛域内的数据模型，属于KG的形式层，其实就是用来形容本体层(Ontology)。

为KG设计Schema相当于为其建设本体(Ontology)，包括概念、概念档次、属性、属性值类型、相关、相关定义域（Domain）概念集以及相关值域（Range）概念集。

Schema是用来规范KG的畛域与形容对象，起到治理KG的作用，比如概念自身的属性可以间接传递到实例，不须要为实例从新定义属性(形式层的属性)，实例可不齐全蕴含概念的属性。

如：“公司”会有“注册日期”，但详细到某个实例如“腾讯”可以没有这个属性，但假设“腾讯”有“注册日期”这个属性，可以间接用概念“公司”中的“注册日期”作为属性KG的设计关键为满足业务需求与运行场景，业务需求与运行场景选择产品设计，图平台产品设计的基础义务又是定义Schema，其中产品经理的关键义务就是思索Schema该如何构建。

Schema定义是与业务强行绑定的，每个KG的实践状况都不尽相反，没有通用的规范与流程，宿愿可以从从他人的只言片语中失掉些许灵感或方向。

我觉得schema这局部分为两层，1.架构上的schema，2.是基于架构上的schema启动业务梳理的实例化，第一点我觉得和技术选型底层设计毫不相关，毕竟谁家的schema样式结构都不一样，第二点我觉得是基于第一点启动的业务数据构建，这局部产品经理可以经过梳理业务数据启动实例构建，不分明你提的是第一点还是第二点。

可以说一个是系统Schema,一个是业务Schema 。

系统Schema关键由架构师来定，从表设计到数据库的构建环节。

伟哥以为：第一个是系统的schema构建，另一个是基于业务梳理的实例化展现，这里如同没有schema的事。

以下是简书作者：画一个逗逗陪着我的一些阅历分享，原文地址： 常识图谱基础（三）-schema的构建，整顿上来以供参考。

Schema定义1.构建域域（Domain）的概念在类型（type）之上，定义域时应尽量形象，域与域之间尽量相互独立，不交叉，如省份就无法定义为域，思索能否要把一个概念当做域时，关键看这个概念能否可继续向上形象，省份之上地域、国度、洲等等，他们都属于天文位置域。

2.确定域的类型确定KG的业务需求、运行场景，思索Schema的外围需求，基于需求，须要确定哪些概念？如：汽车畛域，包括汽车品牌、车系、发起机、油耗等；NBA畛域，包括球队、所属联盟、教练、球员等。

针对不同的需求，须要在域上方定义不同的类型满足需求。

3.确定属性可从两方面思索：1、以用户需求为登程点；2、以数据统计为证据；比如构建了足球畛域的球队类型后，类型汇合了一切的球队实体，从用户角度登程，须要关注哪些相关。

Schema确实认流程1.需求划分将运行依据需求强弱将其划分，可分为：基础外围需求、Schema特征需求、惊喜性需求、系统裁减需求。

基础外围需求：构建KG的Schema须要的成功的外围需求，其优先级最高。

Schame特征需求：需求优先级不是最高，但能构成与竞品构成差异化。

惊喜性需求：非基础外围需求，做了最好，不做也可以。

裁减型需求：须要充沛思索产品未来业务变动，该类需求可大大扭转Schema结构。

2.列出配置点依据需求划分，列出配置点，对配置点启动优先级排期，并充沛思索裁减性与业务开展变动。

3.转化查问结构对每个配置点启动梳理，列出要点、重点，将产品需求转化为查问结构，查问语句可以是对用户体验最关键的一环，是从用户输入到结构前往的整个环节。

尽量防止其中的逻辑破绽。

4.转化为开发需求将构建好的Schema与产品文档找与开发讨论，开发同窗对该打算启开工程成功、查问效率、计算量、成功周期等方面启动思索，产品经理设计时更并重从需求与配置的方面思索，双方启动正当评价才得出最优打算。

所以这块的详细状况还不是很分明，后续再来补充。

以上是近期关于常识图谱的一些思索与总结，常识图谱系列会继续降级，也会放大关注AI畛域的其余产品设计。

团体博客：