概念模型与图模型

我们已经开始在伦敦进行一些关于图形建模的会议，并且在第一次会议中指出，我描述的过程与为关系数据库建模时非常相似。

我以为我最好阅读有关关系模型的方式的阅读，并且遇到了乔·马奎尔（Joe Maguire）的精彩视频，标题为“ 数据建模者仍然有工作：为NoSQL环境进行调整 ”。

Joe首先展示了以下“大框架”，该框架描述了建立关系模型所涉及的步骤 ：

他指出了几张幻灯片，指出我们经常模糊不同阶段之间的界线，最终设计出包含许多实现细节的模型：

另一方面，如果我们将概念模型与图模型进行比较，则问题不大，因为两个模型的映射非常紧密：

• 实体->节点/标签
• 属性->属性
• 关系->关系
• 标识符->唯一约束

唯一约束不能完全捕获标识符所做的所有事情，因为可以创建具有特定标签的节点而无需指定唯一约束的属性。 除此之外，尽管每个概念都一一对应。

我们经常说图形是白板友好的 ，这意味着您在白板上绘制的模型与存储在数据库中的模型相同。

例如，考虑以下人物素描及其与各种书籍的互动：

如果我们要使用Neo4j的密码查询语言将其转换为写查询，它将看起来像这样：

CREATE (ian:Person {name: "Ian"})
CREATE (alan:Person {name: "Alan"})
CREATE (gg:Person:Author {name: "Graham Greene"})
CREATE (jlc:Person:Author {name: "John Le Carre"})
 
CREATE (omih:Book {name: "Our Man in Havana"})
CREATE (ttsp:Book {name: "Tinker Tailor, Soldier, Spy"})
 
CREATE (gg)-[:WROTE]->(omih)
CREATE (jlc)-[:WROTE]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "05-02-2011"}]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "08-09-2011"}]->(omih)
CREATE (alan)-[:PURCHASED {date: "05-07-2014"}]->(ttsp)

还有一些额外的括号和“ CREATE”关键字，但是我们并没有失去域名的保真度，以我的经验，非技术/商业人士将能够理解该查询。

相比之下， 本文显示了从描述员工，部门和工会的概念模型到最终的关系模型可能要采取的步骤。

如果您没有时间阅读这些内容，我们将从这个初始模型开始……

…到了建立一个可以存储在关系数据库中的模型的时候：

您会注意到我们丢失了关系类型，它们已被4个外键取代，这使我们可以将不同的表/集合连接在一起。

在图模型中，我们能够与概念模型保持更紧密的联系，从而与企业的语言保持更紧密的联系。

我仍在探索数据建模的世界，接下来对我来说是阅读Joe的“ 精通数据建模 ”书。 我也很好奇普通形式和数据冗余如何应用于图形，因此我也会对此进行研究。

像往常一样欢迎思想！

翻译自: https://www.javacodegeeks.com/2014/10/conceptual-model-vs-graph-model.html