乐器和艺术家都是“具有”关系的例子。该类型是“是”关系的一个示例。在关系数据库设计中，Has-a和Is-
a关系的建模完全不同。歌曲是流行歌曲，或者歌曲是摇滚歌曲。（我想这首歌既可以流行又可以是摇滚，但是在您的描述中并不清楚）。

Has-a关系更为常见，通常在任何好的教程中都会涉及到。在这些相同的教程中，通常不会对Is-a关系进行足够的介绍。如果要获取有关is-
a关系的ER建模的文章，请查找“一般化/专业化”。这将解释如何描述这些关系之一，而不是如何设计适合的表。

如果您熟悉对象建模，则最简单的概念称为类/子类模式（也称为类型/子类型）。这很简单，但是取决于对继承的内置支持。这种支持通常存在于任何对象系统中，并且为您完成了大多数艰苦的工作。如果您正在设计一个关系数据库，您将面对一个事实，即关系模型不直接支持继承。这意味着除非您愿意使用SQL方言中可用的SQL扩展名，否则您必须设计表来模仿继承的好处。

这两个标签的名称已知两种相对标准的设计： 单表继承
类-表继承

您可以通过阅读每个标签的“信息”标签来获得简要说明。通过查找Martin Fowler对这两种模式的处理，您可以获得更好的描述。

单表解决方案将帮助您为所有歌曲文件创建一个表，其中的列与任何或所有类别相关。

类表解决方案将帮助您为歌曲文件设计一个表，为每种流派设计一个表。如果您使用共享主键技术，从而使流派表中的每个条目从歌曲文件表中的相应条目中“继承”其ID，将很有帮助。当您插入新的歌曲文件时，必须通过额外的编程使这种继承发生。

哪一个更好？这取决于您的情况。你决定。