我应该如何为“非此即彼”的关系建模？

假设我有一个名为Software的实体，并且有两个子类型FreeSoftware和NonFreeSoftware。NonFreeSoftware实体具有购买日期，供应商等属性。FreeSoftware实体具有许可证，源代码url等属性。

因此，如果我想为另一个实体OperatingSystem建模，应该怎么做？与软件之间存在“是”关系，而与FreeSoftware和NonFreeSoftware之间存在“或者”关系。

我认为我在分析此层次结构时缺少一些东西。

解决此问题的方法是您的子类型必须由超级类型确定（即，子类型的PK也是从子类型到超级类型的FK）。

面临的挑战是了解某事物是否真正互斥。子类型的属性应仅适用于那些子类型，但是很可能有些子类型是互斥的，而有些则不是。

如果具有某些互斥子类型，则可以在超类型上使用分区属性来指示（两个或多个）互斥子类型中的哪一个适用。该分区属性可与约束条件或触发器一起使用，以强制相互排斥。

如果您具有不互斥的子类型，则它们可以存在而无需使用任何分区属性。

考虑以下数据模型：

您具有三个超类型，但基于标志分区属性，FREE_SOFTWAREand NON-FREE_SOFTWARE类型是互斥的SOFTWARE.free_not_free。任何给定的软件可能都是OPERATING_SYSTEM，无论其是否免费。

为什么OperatingSystem将成为一个全新的实体？它应该属于“软件”一词​​，这就是它的本质。操作系统（如果为封闭源）将具有购买日期，供应商等。开放源操作系统将具有许可证，源代码URL等。

我会建议与a SoftwareType或类似事物的关系。那时，您可以/应该指定该软件是操作系统，应用程序，还是支持的任何其他类型的软件。