图模型如何处理条件关系，例如：
(Alice -[Dates]-> Bob)
Where [Dates] exists IF and ONLY IF
(Bob -[Owns]-> Ferrari) is true
除了查询之外，我想知道数据库引擎是否根据条件应用关系，或者是否需要在应用程序中管理。
FrobberOfBits 的答案非常好，也适用于 ArangoDB 数据库。 然而，ArangoDB 提供了一个名为“Foxx”的微服务框架，它允许您为可以执行自定义代码的数据库定义其他 API 端点。
Foxx 的一个应用程序正是您的问题： * 定义一个端点来删除做两件事的关系： 1）删除关系 2) 检查所有逻辑约束或副作用并应用它们
这为您提供了直接在数据库中执行（仅一个查询触发器）的优势，并且您的应用程序代码不受这些约束。
我不能代表 arangodb，但对于 Neo4j 来说，这一点必须由应用程序解决。 您可以断言有关图的模式位并不能解决节点类型可以存在哪些类型的关系。 像你所说的那样的偶然关系甚至比这更进一步。
像这样进行验证可能比乍看起来更复杂。 假设鲍勃拥有一辆法拉利。 于是爱丽丝就和鲍勃约会了（太肤浅了！）。 一切都很好——无论是由应用程序还是数据库强制执行。 好吧，鲍勃卖掉了他的法拉利。 数据库应该做什么？
这些是特定领域的考虑因素。 您希望在应用程序层中执行此操作，以便您可以仔细考虑这些验证条件，并做正确的事情。 即使图形数据库确实支持它，也不清楚您是否想要使用图形数据库的默认强制策略（无论是什么）。
我认为在图表中对这样的逻辑进行建模是可能的，并且在某些情况下是合理的。
这是一个使用带标签的属性图而不是 RDF 的示例，但我认为相同的方法是可行的（尽管在我想象的 SPARQL 中查询可能会更困难）。
假设我们有一个跟踪人员和策略的系统。 策略将根据该人的属性的各种组合和条件应用于该人。 能够在图表中表示这种条件性就太好了。 这里与提议的示例存在一些差异，因为“适用于”与“现在正在约会”不同（因此“FrobberOfBits”关注不一定相关）。 以下是政策“适用性”的示例：
This policy shall apply to anyone who performs
Action A in Location B unless they have
Exemption C and also Grade D or Grade E.
我将定义一些人，以便我们有我们想知道“此政策是否适用”的示例：
PersonA --- performs --> ActionA
--- worksIn --> LocationB
--- hasExemption --> ExemptionC
--- hasGrade --> GradeD
PersonB --- performs --> ActionA
--- worksIn --> LocationB
--- hasGrade --> GradeD
PersonC --- performs --> ActionA
--- worksIn --> LocationF
--- hasExemption --> ExemptionC
--- hasGrade --> GradeE
只要思考上述陈述，我们就可以得出该政策不适用于
PersonA，适用于PersonB
（无豁免）而不适用于
PersonC（错误位置）。
我相信这样的系统在理想情况下应该能够变得任意复杂 - 也就是说，应该能够支持无限嵌套数量的 AND / OR / NOT 子句。我们可以通过引入“布尔顶点”（再次，我在这里谈论属性图）来实现这种建模，它封装了导出适用性的规则。
任何策略都可以“应用于”一组事物（诸如位置、活动等顶点）。 在我们的图中，我们总是可以将这些事物顶点之一交换为布尔顶点，该顶点本身将链接到“事物”或进一步的布尔值。
这是我们以这种方式建模的政策适用性：
Policy -> AND
-> LocationA
-> ActivityB
-> NOT
-> AND
-> ExemptionC
-> OR
-> GradeD
-> GradeE
阅读上面的内容需要一些心理体操，但我们可以像这样分解它
如果该人满足 3 项条件（位置 A、活动 B 和非），则政策适用