我有一个名为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)
电视节目可以有很多季节＆amp;发作
一个季节可以有很多集
一集只能属于一个电视节目和一个季节。
我需要知道的是如何在 ERD 上表示这一点，因为tv_shows(tv_show_id)在季节和剧集表中都显示为外键。
tv_show的主键（tv_show_id）正在两个子表之间共享。
答案 0 :(得分：0)
多个其他表引用的表没有问题。从这个角度来看，你的设计是可以的。
您可能会认为tv_show_id中的episodes是多余的;您可以单独使用season_id来引用seasons表，并从那里派生tv_show_id。还有一个隐藏的约束;您希望tv_show_id中存储的episodes与给定tv_show_id中seasons中存储的season_id相同。如果您未将tv_show_id存储在episodes中，那么当然不会发生这种不匹配。
答案 1 :(得分：0)
是的，你可以 - 虽然不清楚你是否。
如果一集只属于一个季节 - 也就是说你没有一个季节没有剧集 - 就不需要在剧集中加入“show_id”，因为这与季节的关系是隐含的。这是重复，并可能导致虚假数据 - 有人可能会插入一个与show专栏无关的季节。
然而，在现实世界中，并非所有剧集都与一季相关 - 例如，有“一次性”。如果要对其进行建模，可以在剧集表中包含show_id。然而，这会导致稍微笨拙的逻辑 - 您的查询必须理解“show”和“episode”之间存在两种类型的关系。为这些案件包括一集称为“无剧集”或其他什么，可能会更好，因此所有关系都是清晰统一的。
或者，您可以拥有一个与季节相关的名为“剧集”的表格，以及一个名为“一次性”的类似表格。
正如您所看到的，在SQL中处理继承样式关系没有很好的方法。
答案 2 :(得分：0)
这完全取决于您使用的是代理键还是复合键。
如果您的主键都是无意义的整数，由auto_num / identity / sequence指定，那么就不需要将父键传播给孙子。
但是，如果seasons的主键是tv_show_id和season_no的组合那么tv_show_id出现就有意义在episodes表中。
这还取决于您如何定义外键约束。最好定义一个清晰的层次结构，如下所示：
电视节目 - | -----＆lt;季节 - | ----＆lt; EPISODE
这清楚地表明，即使episodes中包含tv_show_id，您也应该通过seasons来实现目标。在练习中，你总是可以直接进行加入，但从参考完整性的角度来看，你不必担心同时指向节目A和节目B的季节。