艺术家到宋ERD
Artist to Song ERD
我在阅读维基百科时看到艺术家和歌曲之间定义的以下数据库关系：
http://en.wikipedia.org/wiki/File:ERD-artist-performs-song.svg
来源：http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
下面的文字说明如下：
Two related entities shown using Crow's Foot notation. In this example, an optional relationship is shown between Artist and Song; the symbols closest to the song entity represents "zero, one, or many", whereas a song has "one and only one" Artist. The former is therefore read as, an Artist (can) perform(s) "zero, one, or many" song(s)
现在我对这种关系有一些疑问，因为定义的关系对我来说似乎不切实际：
1) 在现实生活中，一首歌可能有 1 到许多可能表演甚至创作这首歌的艺术家，所以在我看来正确的关系应该显示从歌曲到艺术家的“-IE”而不是“-II”
2) 一个艺术家怎么能演奏 0 首歌曲“-0E”——如果这是真的，根据实体名称的字典定义，该实体不应再被归类为艺术家，对吗？ （请不要评论看到自称为艺术家并且不能表演歌曲的人——我必须同意这一点）根据显示的 DB 关系，艺术家分类被授予不能表演歌曲的实体，因此在设计 ERD 时实体的字典定义是否也应该规定实体关系？如果是这样，在数据库关系建模中是否有针对此类规划的特定名称，以考虑为实体指定的名称的定义？
3) 在 ERD 中，"performs" 动词被用来显示关系动作，查看其他 ERD，当图表以视觉方式表示时，我没有看到任何地方也为关系定义动词.是否有必要在 ERD 中定义和显示此动词？我问的原因是因为在上述情况下，"performs" 动词可能是一个糟糕的选择，如果选择了 "creates" 动词，那么关系可能是正确的，艺术家可能会创作 0 到 * 首歌曲但是由于为关系选择了动词，正如我上面提到的，它打破了语句试图描绘的逻辑联系，从而使其成为无效关系。基于此，选择的动词在数据库关系图中应该不是强制性的吗？
问题 #1
在现实世界中，我们通常认为一首歌可以由许多不同的艺术家演奏。例如，甲壳虫乐队的歌曲有多少次被不同的艺术家以不同的方式演绎。
然而，在数据世界中，它很可能被完全视为一个单独的歌曲实体，因为这样可以记录歌曲新版本中的所有差异，例如不同的编曲等. 如果您按照建议对系统建模，将无法（或者可能没有简单的方法）捕获任何信息。
这是我对图表以这种方式对关系建模的原因的合理假设。正如您所建议的那样，将艺术家与歌曲的关系建模为多对多在技术上没有任何问题，但这取决于您正在构建的系统的性质和要求。
问题 #2
基数（可选、强制、一、多等）指示实体/关系可以存在的条件。用简单的英语来说，这张图应该更像是 "An artist can exist, but not have any related songs. A song cannot exist unless it is related to an artist"。我不确定我是否误解了 "dictionary definition" 和 "cannot" 的意思，所以如果我没有正确解决这一点，请告诉我。我当然可以看出你对动词用法的困惑，但请记住，它是关于存在的，而不是执行动作的能力。
问题 #3
动词本身有助于阐明关系。如果可以用通俗易懂的语言阅读，就可以更容易地理解系统的组件。它还可以帮助您了解系统本身的性质。也就是说，这个DB很可能是为了记录艺术家和他们的歌曲表演，不一定只是一个歌曲和艺术家的目录。
关于省略动词，我想在某些情况下作者认为这是显而易见的，或者添加动词可能会使图表变得混乱等等。基本上，如果您只是想知道如何实现数据库中的关系，您真正需要知道的只是关系的类型（一对多等）和约束（强制的、可选的等）。这个动词在某种程度上是糖。
在这个图表的例子中，尽管它似乎不是这样建模的，但可以说这个数据库也记录了这首歌的作者。这样，一个名为 "Lyricist" 的实体与一个动词 "writes" 可能存在另一种关系。创作/创作歌曲的人可能与演唱歌曲的人不同。现在，诚然，我们正在进入非常深入的细节，因为我们可以谈论一首歌是许多不同实体（歌词、乐器、编曲等）的组合。但这将超出原始图表的范围。
让我知道这是否澄清了事情。
我在阅读维基百科时看到艺术家和歌曲之间定义的以下数据库关系：
http://en.wikipedia.org/wiki/File:ERD-artist-performs-song.svg
来源：http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
下面的文字说明如下：
Two related entities shown using Crow's Foot notation. In this example, an optional relationship is shown between Artist and Song; the symbols closest to the song entity represents "zero, one, or many", whereas a song has "one and only one" Artist. The former is therefore read as, an Artist (can) perform(s) "zero, one, or many" song(s)
现在我对这种关系有一些疑问，因为定义的关系对我来说似乎不切实际：
1) 在现实生活中，一首歌可能有 1 到许多可能表演甚至创作这首歌的艺术家，所以在我看来正确的关系应该显示从歌曲到艺术家的“-IE”而不是“-II”
2) 一个艺术家怎么能演奏 0 首歌曲“-0E”——如果这是真的，根据实体名称的字典定义，该实体不应再被归类为艺术家，对吗？ （请不要评论看到自称为艺术家并且不能表演歌曲的人——我必须同意这一点）根据显示的 DB 关系，艺术家分类被授予不能表演歌曲的实体，因此在设计 ERD 时实体的字典定义是否也应该规定实体关系？如果是这样，在数据库关系建模中是否有针对此类规划的特定名称，以考虑为实体指定的名称的定义？
3) 在 ERD 中，"performs" 动词被用来显示关系动作，查看其他 ERD，当图表以视觉方式表示时，我没有看到任何地方也为关系定义动词.是否有必要在 ERD 中定义和显示此动词？我问的原因是因为在上述情况下，"performs" 动词可能是一个糟糕的选择，如果选择了 "creates" 动词，那么关系可能是正确的，艺术家可能会创作 0 到 * 首歌曲但是由于为关系选择了动词，正如我上面提到的，它打破了语句试图描绘的逻辑联系，从而使其成为无效关系。基于此，选择的动词在数据库关系图中应该不是强制性的吗？
问题 #1
在现实世界中，我们通常认为一首歌可以由许多不同的艺术家演奏。例如，甲壳虫乐队的歌曲有多少次被不同的艺术家以不同的方式演绎。
然而，在数据世界中，它很可能被完全视为一个单独的歌曲实体，因为这样可以记录歌曲新版本中的所有差异，例如不同的编曲等. 如果您按照建议对系统建模，将无法（或者可能没有简单的方法）捕获任何信息。
这是我对图表以这种方式对关系建模的原因的合理假设。正如您所建议的那样，将艺术家与歌曲的关系建模为多对多在技术上没有任何问题，但这取决于您正在构建的系统的性质和要求。
问题 #2
基数（可选、强制、一、多等）指示实体/关系可以存在的条件。用简单的英语来说，这张图应该更像是 "An artist can exist, but not have any related songs. A song cannot exist unless it is related to an artist"。我不确定我是否误解了 "dictionary definition" 和 "cannot" 的意思，所以如果我没有正确解决这一点，请告诉我。我当然可以看出你对动词用法的困惑，但请记住，它是关于存在的，而不是执行动作的能力。
问题 #3
动词本身有助于阐明关系。如果可以用通俗易懂的语言阅读，就可以更容易地理解系统的组件。它还可以帮助您了解系统本身的性质。也就是说，这个DB很可能是为了记录艺术家和他们的歌曲表演，不一定只是一个歌曲和艺术家的目录。
关于省略动词，我想在某些情况下作者认为这是显而易见的，或者添加动词可能会使图表变得混乱等等。基本上，如果您只是想知道如何实现数据库中的关系，您真正需要知道的只是关系的类型（一对多等）和约束（强制的、可选的等）。这个动词在某种程度上是糖。
在这个图表的例子中，尽管它似乎不是这样建模的，但可以说这个数据库也记录了这首歌的作者。这样，一个名为 "Lyricist" 的实体与一个动词 "writes" 可能存在另一种关系。创作/创作歌曲的人可能与演唱歌曲的人不同。现在，诚然，我们正在进入非常深入的细节，因为我们可以谈论一首歌是许多不同实体（歌词、乐器、编曲等）的组合。但这将超出原始图表的范围。
让我知道这是否澄清了事情。