实例观察网络模型与关系模型对现实世界的建模差异

我感觉受 主流/传统的 Object Orientation 对 领域模型设计 的影响, 以及 SQL 对 关系模型设计 的影响, 目前领域模型基本都设计为 "网络模型" 也就是更倾向于 传统的数据结构.

举个例子, 比如要描述一颗螺丝 s1 和一颗螺母 c1, 以及把它们拧在一起的关系.

如果按照网络模型(传统数据结构)的思路, 那么就必须同时有一个把螺丝拧进螺母(s1.cap = c1)和一个把螺母拧上螺丝的动作(c1.screw = s1), 显然这跟现实世界的逻辑思维是有差别的.

反过来如果按照关系模型的思路, 只要一个建立拧接关系的动作 (new Screwing(s1, c1)), 就跟现实逻辑是恰好符合的.

不过在通用OO语言基础上实现关系模型的语义, 还是要费些周折, 不过也不是不可能. Object Relation Kin Model 就是一个结合通用OO语言与关系模型的例子.

Object Relation Kin Model还没有来得及看。

从对这两种的描述来看，传统的数据结构强调的是参与者之间的相互联系，而关系模型则是强调的是：这种联系构成了一种关系，而这种关系构成了一种新的模型。是否可以简单的这样理解。

嗯, 严格追根溯源的话, 关系模型是Codd在1970年根据数学上的 "关系理论" 提出来的, 数学的概念定义很抽象, 其实也不能跟现实世界完全匹配, 不过经过这么多年在计算机领域的发展, 关系模型在软件数据模型方面已经算得上比较实际, 应用的时候基本上就可以按SunMicro所说的简单理解.

而网络模型没有数学理论的根源, 基本上就是从数据结构演化来的, 所以跟软件设计有本源的亲和性. 但是现在计算机也在商业处理方面广泛应用了, 业务逻辑跟科学计算, 基础算法, 甚至跟物理/化学系统模拟都有本质性的差别, 可以说是更接近日常直觉上的逻辑思维方式, 于是在商业计算方面, 软件设计跟 关系模型 的亲和性倒显得更强一些了.

或者说 关系模型 更倾向于人脑的逻辑方式, 更抽象, 更接近 "WHAT"; 而 网络模型 更倾向于电脑的逻辑方式, 更细节, 更接近 "HOW".

领域模型设计也不一定是两个动作，看螺丝和螺母哪个更主要，可以是s1.cap = c1或者c1.screw = s1吧。当然和new Screwing(s1,c1)还是有语义上的差别的。比如杯子上加个盖子，应该是 杯子1.盖子 =盖子1吧。

是的, 有的时候通过计算机解决问题并不需要自然实体的完整信息, 这些情况下网络模型就显得更为灵活, 只按需建模处理局部信息, 简单高效. 不过这些情况在数据结构, 基础算法, 有限元模拟等领域很广泛, 但是在商务计算方面就相对少见. ERP, CRM, PDM/PLM等领域关系常常还是相互的, 所以关系模型就显得更贴切些.

Class Screwing()不就是一种服务吗？[Evans03]跟关系模型有什么关系