我正在对我们现有的数据库进行建模,并将其转换为图形数据库。
下面是我如何解释数据库图关系的方法。
group -have-> groups
group -have-> participants
participant -is-> user
user -has-> profile
user -has-> user-accounts
user-account -composed of-> social-logins
user-account -composed of-> username-password这些看起来像是有效的关系吗?我所读过的人际关系的例子包括以下几个似乎更好的例子,但我想不出其他更适合现有关系的东西。
actor - acted-in -> movie
director - directed -> movie
supplier - supplies -> product更新:这是我已经读过的一篇文章。据我所知,https://neo4j.com/developer/relational-to-graph-modeling/#_建模_从…_关系型_至_图表建议可能是
belongs-to
is-part-of发布于 2018-11-09 03:08:13
如果您有一个现有的关系数据库设计,那么您就有了图形设计的第一次迭代。表行将成为节点,外键将成为关系。
在图表中,就像在ERD设计中一样,避免使用模糊的关系名称."Has“、"is”和他们的同类对业务领域没有任何积极的看法。更糟糕的是,他们会引起混乱,因为每个人读到这些弱势的名字,无论他们的理解是什么。以“组-有->组”为例。是说左手组是右组的超级组,或者是一个子组,或者是由或必须排除的,或者是.明白我的意思了吗?
相反,使用业务域使用的单词。关系应该记录关联在应用程序和域中所扮演的角色。它应该是具体的,而且应该是单一的。如果有多种原因将节点A链接到节点B,则为每个原因创建一个单独的、名称良好的关系。
https://softwareengineering.stackexchange.com/questions/381157
复制相似问题