问题描述
我知道有些算法（甚至工具）可以将关系数据库（RDBMS）转换为Graph数据库，反之亦然。有几个问题比这个大一些：
-
是否有一种常用的工作算法用于这种转换：示例RDBMS =>图（或几个）？ 这个算法是双射的吗？更确切地说：
2.1。给定所述算法，转化RDBMS =>图内射（一对一）？更清楚的是，是否可以有任何两个关系数据库可以转换成相同的图形数据库？
2.2。同样，任何Graph DB都可以用关系数据库来表示吗？基本上，我在问算法函数是否是完全满意的？
Is there a common-practice working algorithm out there for such transformation, for example RDBMS => graph (or several)?
Is this algorithm bijective? To be more precise:
2.1. Given said algorithm, is the transformation RDBMS => graph injective (one-to-one)? More plainly, can there be any two relational DBs that can be transformed into the same Graph DB?
2.2. Similarly, is any Graph DB can be represented by a relational DB? Basically, I'm asking if the algorithm function is surjective (onto)?
从图的特定数学概念（节点集合，边缘关系）到关系的典型的双向映射表示。本质上，因为数学使用集合和关系。
没有标准图形DBMS。并没有标准的方法来使用一个代表应用程序/业务情况。因此，图形数据库状态和图形之间没有标准映射。一个关系状态，更不用说一个在另一个中表示另一个表示，对于所表示的情况来说是自然的。
没有关系值属性，映射并不总是非射 - 关系结构和关系结构，因为我们有时必须选择关系型替代值1：1与我们已经使用的关系值。
但是数据库或数据结构变量通常代表应用程序/业务情况。通常情况下有一对多或一对一的从情景到表示的映射。在关系模型下，每个表都有一个关联的（特征）谓词（语句模板），并保留了构成谓词（语句）的行。其他数据结构以临时方式用于表示一种情况。
关系模型的特殊之处在于，您可以通过谓词逻辑和/或关系运算符进行一般查询 - 查询表达式确定一个谓词，其结果保存了从谓词中得出真正命题的行。 （以一定的复杂性保证和一定的自动优化机会来计算）。
表示相同情况的结构之间的映射取决于数据库表示方式的情况。所以表示之间没有通用映射，即使对于使用相同数据结构的两个表示也是如此。另一方面，您可以在两个结构之间定义一些通用映射，并且它可能是双射的，但是当一个情况由一个表示时，另一个告诉你关于情况的另一个表示，因此情况只是间接的，而不是直接情况本身。因此，不要指望描述其他结构代表的关系型版本就像是该应用程序/业务的良好关系设计。
这是ORMs& amp; amp问题;对象数据库。您可以定义从特定的面向对象状态到关系的映射，但关系只描述面向对象的状态，而不是其描述的状态。每当一个对象值持有一个被引用而不是被包含的对象的oid时，该引用对象就代表一个关系/关联实体实例。但是通常没有为与这些对象集合相关的关系给出明确的谓词。相反，我们从一个完整的代表状态到一个代表状态给予了表示函数。而在关系设计中，每个表（基本或查询结果）的每个超键值与某个（可能是关联的）实体是1：1。
I am aware that there are algorithms (and even tools) to transform relational databases (RDBMS) to Graph databases, and the other way around.
I do have several questions that are a bit larger than that:
TL;DR
There's typically an obvious bijection from a particular math notion of graph (node set, edge relation) to a relational representation. Essentially because the math uses sets and relations.
There's no standard graph DBMS. And no standard way to use one to represent application/business situations. So there's no standard mapping between a graph database state & a relational state, let alone one that gives a representation in the other that is natural for the situations represented.
Without relation-valued attributes, mappings are not always bijective between non-relational structures and relational structures because we must sometimes pick relational surrogate values 1:1 with the relation values we would have used.
Sometimes we're not interested in a particular situation, we are just interested in a data structure. Then we can come up with (various) relational versions of it.
But a database or data structure variable typically represents an application/business situation. There is typically a one-to-many or one-to-one mapping from situations to representations. Under the relational model, every table has an associated (characteristic) predicate (statement template) and holds the rows that make a true proposition (statement) from its predicate. Other data structures are used in an ad hoc way to represent a situation.
What's special about the relational model is that you can generically query via predicate logic and/or relation operators--a query expression determines a predicate and its result holds the rows that make a true proposition from its predicate. (Calculated with certain complexity guarantees and certain opportunities for automated optimization.)
Mappings between structures that represent the same situation depend on how the databases represent situations. So there is no general mapping between representations, even for two representations using the same data structure.
On the other hand you can define some generic mapping between two structures, and it might be bijective, but when a situation is represented by one, the other tells you about the other representation of the situation, hence the situation only indirectly, not the situation itself directly. So don't expect the relational version that describes the other structure's representaion to be anything like a good relational design for that application/business.
This is the problem with ORMs & object databases. You can define a mapping from a particular object-oriented state to relations but the relations are only describing the object-oriented state, not its represented situation. Every time an object value holds an oid to an object referenced rather than contained, that referencing object is representing a relationship/association entity instance. But usually there is no explicit predicate given for the relation corresponding to the set of such objects. Instead we are given a representation function from some entire representing state to a represented situation. Whereas in a relational design every superkey value of every table (base or query result) is 1:1 with some (possibly associative) entity.
这篇关于在关系数据库和基于图形的数据库之间转换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！