核心数据中同一实体之间的一对多关系

Question

我有一个名为Item的实体。它有属性title，我希望它有子集的集合（类型Item）。

一件商品可以有多个（子）商品。 （子）项目是右项目的一部分。例如，有一个名为car的项目。它有子项目，标题为车轮，发动机和驾驶室。 Cabine有子项座椅和方向盘。

如何建模？我应该设置逆子项吗？如果我没有反转，我会收到警告。无论它是否相反，它仍然是多对多的。无法将其设置为一对多。

我该如何看待这个问题？我对数据库没有多少经验，我认为在Core Data和SQL中进行建模之间也存在差异。

编辑：图片中应该有subitems而不是subitem

Answer 1

我已将 superitem 与子项目相反添加。 superitem 是 to-one 类型，其中nullify删除规则，子项是 to-many 类型， cascade删除规则。似乎是我案例中最完美的解决方案。作为奖励，我不必编写自己的- addSubitem:方法（因为它不是为Swift生成的），因为如果我设置了项目 superitem ，它会自动添加。

Answer 2

对象建模和关系数据库设计是完全不同的，至少在表面上是这样。封装，继承和多态的概念在关系数据模型中没有确切的类比。为了进行对象建模和关系数据库设计，您将不得不以两种不同的方式考虑问题。

有一种模型介于两者之间。它被称为＆＃34;实体关系模型＆＃34;，这几乎和关系模型一样长。这对于在概念层面思考问题和分析数据需求非常有用。 ER建模与对象建模非常平行，除了对象建模模型行为和数据，ER建模仅模拟数据。

为此目的学习ER建模的问题在于，在目前的情况下，大多数使用ER图的专业人员不会使用它们来描绘概念模型。他们使用它们来描述数据库的关系设计。因此，如果您从中学习ER建模，您将学习设计方法，而不是分析方法。

数据分析和数据库设计实际上是非常不同的活动，即使单个项目要求您同时执行这两项操作，在您的脑海中将它们分开也很有用。奇怪的是，同样的划分最终也出现在对象建模中。一些对象模型是分析模型，并试图澄清问题空间。其他对象模型是设计模型，并试图澄清解决方案空间。

Answer 3

承认米蒂所说的话。你需要将你的大脑包裹在物体周围（而不是关系表）。考虑到你的例子，我将其分解如下。顶层物体是诸如汽车，卡车，飞机，船等物品。物品可以具有诸如发动机，变速器，舱室之类的系统。系统可以具有活塞，火花塞，座椅，方向盘，轮胎等部件。如果您将所有这些事物都视为对象，那么模型的开头可能如下所示：

项目可能有许多系统。系统可能有许多组件。 Apple建议设置反向，但您应该更多地关注关系及其基数（即一对一，一对多）。你可以像你描绘的那样使用反身关系（对自己），但我认为这限制了你真正利用对象模型的力量作为所有事物的能力。将被表示为＆＃39; item＆＃39;并且你不会有系统和组件（IMO）的明显区别