我有一个名为 tv_shows 的数据库，其结构如下：
tv_shows(tv_show_id, tv_show_title, tv_show_desc, network, status)
seasons(season_id, tv_show_id, season_no, season desc)
episodes(episode_id, tv_show_id, season_id, episode_title, episode_desc, episode_ref, air_date)
一个电视节目可以有很多季和集
一个季可以有很多集
一个集可以只属于一个电视节目和一个季。
我需要知道的是如何在ERD上表示这一点，因为它在季节表和剧集表中都tv_shows(tv_show_id)显示为外键。
tv_show 的主键 (tv_show_id) 在两个子表之间共享。
一个表被多个其他表引用没有问题。从这个角度来看，你的设计是可以的。
你可能会争辩说tv_show_idinepisodes是多余的。您可以使用season_idonly 来引用该seasons表，并从中派生 the tv_show_id。还有一个隐藏的约束；您希望tv_show_id存储的内容与给定的存储内容episodes相同。如果您不存储in ，那么当然不会发生这种不匹配。tv_show_idseasonsseason_idtv_show_idepisodes
是的，你可以——虽然不清楚你是否应该这样做。
如果一集恰好属于一个季节 - 即你不能有一个没有季节的一集 - 不需要在剧集中包含“show_id”，因为这隐含在与季节的关系中。这是重复的，并且可能导致虚假数据 - 有人可能会插入一个与节目栏无关的季节的剧集。
然而，在现实世界中，并非所有剧集都与一个季节相关联——例如，存在“一次性”。如果您想对其进行建模，您可以在剧集表中包含 show_id。但是，这会导致逻辑有点尴尬 - 您的查询必须了解“节目”和“剧集”之间存在两种类型的关系。对于这些情况，最好包含一个称为“无情节”的情节，或者其他什么，这样所有的关系都清晰统一。
或者，您可以有一个与季节相关的名为“episode”的表，以及一个名为“one-off”的类似表。
如您所见，在 SQL 中处理继承式关系没有很好的方法。
这完全取决于您使用的是代理键还是复合键。
如果您的主键都是无意义的整数，由 auto_num/identity/sequence 分配，则无需将父键向下传播给孙子。
但是，如果 的主键seasons是 的组合，那么出现在表 tv_show_id中是有意义的。season_notv_show_idepisodes
这也取决于您如何定义外键约束。最好定义一个清晰的层次结构，如下所示：
电视节目 -|-----< 季节 -|----< 剧集
这清楚地表明，即使其中episodes有一个tv_show_id，你也应该经过seasons才能到达那里。在实践中，您始终可以直接进行连接，但从参照完整性的角度来看，您不必担心同时指向节目 A 的剧集和节目 B 的季节。