Database 实现Actors数据库的ER图

注意：这是一个粗略的副本，我还没有包括约束、弱实体等等。我仍然需要对这个问题有一个坚实的理解

问题:

为了跟踪哪家剧院公司管理表演者，哪家剧院公司的表演者是两个剧院公司的表演者，我是否必须为其他实体集中的每个实体集制作唯一的代码来跟踪他们

起始位置是否可以简单地指向剧院公司实体的位置

演员可以出生在某个地方，还是必须有指向某个地方的属性

到目前为止，我的关系有意义吗

剧本中是否存在诸如简短描述之类的冗余属性

我可以在适当的地方创建一个名为城镇、州/部门/省的属性吗？或者它必须是一个组合属性

请注意：我将编辑和更新我的图表，如果我有更多的问题等

如有任何建议或提示，我将不胜感激

ERD：

问题资料:

演员出生在一个地方，他/她目前居住在一个地方。此信息是强制性的

我们只在数据库中存储演员居住的最后一个已知地点

我们需要演员的以下信息：演员编号、演员姓名、演员出生日期和演员死亡日期检查是否死亡>出生

演员是表演者或/和戏剧导演。 我们为表演者存储他/她开始表演的日期

我们为剧院总监存储他/她最后一次担任剧院总监的开始日期

我们在戏剧作品中考虑戏剧、喜剧和悲剧。p> 对于每一个，我们希望存储以下数据：剧本编号、剧本标题、剧本的简短描述、剧本编写的年份、在舞台上首次呈现的日期、日期

对于戏剧，我们还存储戏剧类型、主要积极角色的名称和主要消极角色的名称

戏剧类型为以下类型之一： “古典”、“中世纪”、“文艺复兴”、“十九世纪”、“现代”和 “当代”

对于喜剧，我们存储喜剧类型，即main的名称 字符，以及第二个字符的名称

喜剧类型如下：“古罗马”、“古希腊”、“闹剧”、“幽默喜剧”、“礼仪喜剧”， “艺术喜剧”和“荒诞派戏剧”

对于悲剧，我们存储悲剧类型t_type、varchar20和main的名称 性格

悲剧类型有以下几种：“希腊”、“罗马”、“文艺复兴”、“新古典主义” -“古典”与“现代”

戏剧是由一个或多个剧作家写的 我们可能不认识某些戏剧的剧作家

我们在数据库中存储所有已知剧本，即使它们不是“秘密剧本”

有些演员也是剧作家

我们在数据库中存储所有已知的mdramatist

演员在任何时间都会被一家独特的戏剧公司雇佣

他/她受雇时将在同一家公司工作一整年

我们在数据库中存储了他/她受雇于戏剧公司的那一年 小整数

演员可能会改变他/她所在的剧团 在他/她的一生中工作过很多次。一个演员有可能在不同的年份多次被同一家公司雇用。他/她可以在舞台上表演 一个或多个角色至少扮演一个角色

由剧团演出

一个演员可能被一家戏剧公司雇佣，并在另一家戏剧公司上演的戏剧中表演

这是不寻常的，但可能是同一个演员在同一个发挥 由不同的剧团演出。戏剧公司表演/演出 每年有一部或多部戏剧

同一剧可以由一个或多个不同的剧团演出

我们喜欢在数据库中存储播放开始的日期 一家戏剧公司

同一出戏可能由不同的剧团在同一天开始演出

我们需要为剧作家存储他/她的剧作家编号和姓名

剧作家写了一个或多个剧本，至少一个

存储在每个战区连数据库中的信息 is：剧院公司编号、剧院公司名称、演出日期 戏剧公司成立了

对于我们存储在数据库中的每个剧院公司 剧院公司成立的第一个地点

在同一个地方，可能会有不止一家剧院

戏剧公司必须至少雇佣一名演员

每个剧团都有一个独特的剧团导演。 他/她在特定日期开始工作

同一家剧院公司可能有不同的剧院总监，但在不同的时间和相同的剧院总监 管理不同的 不同时期的剧团从不在同一日期演出

有可能是同一个剧院导演管理同一个剧院 剧院公司在不同的日期

---

为地点存储的信息是：地点编号、城镇和州/部门/省、地点国家/地区以下是我对您的问题的回答：

每当您查看两个表并看到多对多关系时，可以使用链接器表轻松解决问题。也称为连接表“是一个数据库表，其中包含同一数据库中两个或多个其他数据库表的公共字段。它与每个其他表都处于一对多关系的多个方面。连接表有许多名称，其中包括交叉引用表、桥接表、连接表、映射表、交叉表、链接表，多对多解析器、链接表、配对表、转换表、人行横道、关联实体或关联表。“您在上一个问题中看到我使用了这些表。在本例中，您是说一个演员可以由我的多个剧院公司和一个剧院公司管理，也可以管理多个演员。这是一个多对多的问题。因此，如果您在这些表之间为这两个公司之间的每个关系创建了一个链接表，您应该在“链接”选项卡中添加一个新行仅包含剧院公司id和演员id的le。如果一名演员由多家剧院公司管理，则应向链接表中添加多行，每行都具有相同的演员id，但每行具有不同的剧院公司id。 是的，您可以将start_Location point直接指向place。这意味着该start_Location属性必须是外键FK，将剧院公司指向相关place记录的主键PK。 当然，演员可以出生在某个地方，但正如上面所述，你需要演员中的一列，这是place表PK的FK。你可以调用此列Birth_place，它所包含的只是与演员出生地相关的记录的PK。此列也需要不为空，因为所有演员都需要出生_位置 到目前为止，您的图表似乎可以解决这个问题，是的。关于后续添加的内容，请参见问题1的答案。 您在消除冗余方面越来越在行。您的图表看起来不错。我唯一的建议是，为什么您有一个播放表，然后有3个单独的播放类型表？为什么不将它们添加到名为“播放”的“播放”表中呢？它正好位于图表中播放当前所在的位置，并且包含它已经具有的相同属性，但您需要lso添加以下内容：

a、 类型–可以是一个字符串，您可以将“戏剧”、“喜剧”或“贸易”放在其中，这样您就可以确切地知道它是什么类型的戏剧。此外，这将允许您将未来的戏剧类型添加到戏剧表中，而不必向DB添加一个全新的表

b、 Sub_Type–也可以是一个字符串，保存您当前在单独的表下拥有的类型。它们在每个表中基本上都是相同的属性，只是根据父类型保存不同的类型描述符

c、 Main_Character–将是一个包含主字符的字符串，因为在三个单独的表中，您有主字符。您只是将它们称为3个单独的东西。了解我在这里的方向吗

d、 Secondary_Character–将是一个包含次要字符的字符串。在戏剧和喜剧中有一个次要字符，但在tradegies中没有，因此在tradegy记录中，此列将最终为空。看到我在那里做了什么吗？您现在有一个表，以前有4个，在该表中可以检索所有的字符您在这4个单独的表格中拥有的ame信息。希望这能让您的生活更轻松

你可以做你想做的任何事情，但我假设你指的是最佳实践，通常认为最好的实践是将这个单一属性分成它的简单属性子部分，即使它成为一个组合属性。

---

@冷酷的程序员这是我正在研究的下一个问题，ER图在上面哦，天哪。我不确定这是否适合这么做。看起来你要么有太多的信息，要么有太多的问题。另外，我认为sql标签不适合，因为这只是一个图。我投票结束这个问题，因为这个问题太宽泛了。你可能会觉得你有问题把你的信息缩小，但你的范围还不够。你的每一个要点都应该是自己的帖子。也非常感谢buddy在我做了这么多的打字和努力之后投票删除我的帖子。好的，谢谢你的答案。我会很快查看你建议的答案。5.当你建议打字时，sub_type…to在实体集合中，游戏的类型是实体集合？或者是一个包含3个属性的属性。然后每个属性中都会有更多的属性，这是每个喜剧、传统和游戏的类型

---

egy…？或者类型、子类型、主字符、次字符仅仅是实体集合PlayCorrect中的属性，类型、子类型、主字符和次字符都只是Play实体中的简单属性。例如，对于每个新记录，Type属性只包含一个字符串值。它可以是喜剧、戏剧或悲剧，但不能是多重的。然后根据输入的类型值，您将拥有一个子类型，该子类型与拾取的父类型相关。我明白了，因此，为喜剧制作一个额外属性，…，将不存在，并且子类型（如现代、中世纪等）也不存在，。。。也不存在，它将被视为一个输入，并根据类型输入生成一个子类型。但是，数据库如何知道所有这些子类型呢？因为问题是存储这些子类型。