我有一个关系数据库（大约30个表），我想将它转换到neo4j图数据库中，我不知道从哪里开始...... 是否有将表和/或元组转换为图模型的一般方法？ （关系属性，一个或多个图？）文档的最佳来源是什么？
感谢您的帮助，
祝你好运
答案 0 :(得分：3)
首先，如果可能的话，我建议不要使用你的关系数据库作为你的＆＃34;参考＆＃34;用于转置到图形模型。关系建模中的错误和陷阱经常被转移到图模型并引入其他奇怪的东西。事实上，如果你有一个源ER图，这可能是一个更好的起点，因为它实际上已经是一个图。甚至可以考虑为您的域名进行重新建模练习！
也就是说，从基本的角度来看，您可以将大多数表视为表示节点类型（例如＆＃34; User＆＃34;或＆＃34; Movie＆＃34;），其中表示连接表和键关系类型。
从我的角度来看，一个很好的起点是确定图表/数据源应该回答的一些问题。写下这些问题，并尝试提出代表问题的Cypher查询。很多时候，图形模型自然会产生这种努力，而且它并不那么困难。
如果您还没有，我强烈建议您从此处获取图表数据库电子书的（免费）副本：http://graphdatabases.com/
它充满了很多关于从哪里开始建模你的域的好信息，甚至当你习惯以关系方式做事时需要考虑的事情。它还包含一些关于Cypher的资料，尽管Neo4j网站（neo4j.org）有一本参考手册，其中包含有关Cypher的大量最新信息。
希望这有帮助！
答案 1 :(得分：3)
这种转换不会成为一站式商店，因为并非所有的数据模型都适合图形建模，每个应用程序都是独特的特殊雪花......但是说.....
通常，您的基地＆＃39;表格（例如用户，角色，订单，产品）将成为节点，并且您的“表格”会加入表格。 （a.k.a. buster tables）将成为您关系的候选者（例如UserRole，OrderLineItem）。关键是要记住，在图表中，通常情况下，在两个特定节点之间只能有一个给定类型的关系 - 所以在上面的例子中，如果你的系统允许相同的产品在一个订单中两次 - 这会导致的问题。
外键是你的第二个关系来源，看看它们是否有意义成为一个关系或只是一个属性。
请记住您要通过数据模型解决的问题 - 如果它遍历您的对象以查找关系和距离等等，那么图表可能非常合适。如果您正在建模电子商务应用程序，您正在处理操作单个嵌套对象（例如订单 - ＆gt;订单项 - ＆gt;产品 - ＆gt; sku），那么关系模型可能是合适的。
希望我的0.02美元帮助...
答案 2 :(得分：0)
正如已经说过的，从关系数据库模型到图形数据库模型没有神奇的转变。
您应该查找原始实体及其相关方式，以便找到您的节点，属性和关系。并始终牢记您要执行的查询类型。
正如 BtySgtMajor 所说，"Graph Databases"是一本很好的书，它是免费的。