实现Actor数据库的ER图
ER Diagram that implements Actors Database
注意：这是一个粗略的副本，我还没有包括约束、弱实体……等等。这个问题我还需要好好理解一下。
问题：
要跟踪哪个剧院公司管理表演者，两个剧院公司的哪个表演者，我是否必须为其他实体集中的每个实体集制作唯一代码以跟踪它们？
可以start_Location简单地指向剧院公司实体的地点吗？
Actor可以出生在一个地方还是必须有一个指向地方的属性？
到目前为止我的人际关系有意义吗？
Plays中是否有Short_Descript等冗余属性？
我可以在 Place 中创建一个名为 "Town, State/Department/Province" 的属性吗？还是必须是组合属性？
请注意：如果我有更多问题等，我将编辑和更新我的图表...
如有任何建议或提示，我将不胜感激。
ERD：
问题信息：
一个演员出生在一个地方并且 he/she 目前居住在一个地方（此信息是必填的）。
我们只在数据库中存储演员最后已知的居住地。
我们需要演员的以下信息：演员编号、演员姓名、演员出生日期和演员死亡日期（检查是否死亡 > 出生）。
演员是表演者，or/and是戏剧导演。
我们为表演者存储 he/she 开始表演的日期。
我们为剧院导演存储开始日期his/her最后一次担任剧院导演
我们在 DBActors 中考虑以下类型的戏剧：戏剧、喜剧和悲剧。
对于每个我们喜欢存储以下数据：戏剧编号、戏剧标题、戏剧简短描述、创作年份、首次登台日期（p_date_p、日期）。
对于戏剧，我们还存储戏剧类型、主要正面角色的名称和主要反面角色的名称。
剧集类型为以下之一：
“古典”、“中世纪”、“文艺复兴”、“nineteenth-century”、“现代”和
“当代”
对于喜剧，我们存储喜剧类型、主要角色的名称
字符 ，以及第二个字符的名称
喜剧类型为以下之一：“古罗马”、“古希腊”、“闹剧”、“幽默喜剧”、“风俗喜剧”、
“即兴喜剧”和“荒诞剧场”；
对于悲剧，我们存储悲剧类型（t_type，varchar(20)）和主要的名称
字符
悲剧类型为以下之一：“Greek”、“Roman”、“Renaissance”、“Neo”
-古典”和“现代”
一出戏由一位或多位戏剧家创作
我们可能不认识某些戏剧的剧作家。
我们将所有已知的戏剧存储在数据库中，即使它们没有被表演（“壁橱戏剧”）
有些演员也是戏剧家。
我们在数据库中存储了所有已知的戏剧家。
一位演员在任何时间戳都被一家独特的剧院公司雇用
He/she 将在 he/she 被录用后整年留在同一家公司。
我们在数据库中存储 he/she 被剧院公司聘用的年份
（小整数）
有可能是演员换了he/she所在的剧团
his/her 一生中多次工作。一个演员有可能在不同的年份多次被同一家公司聘用。 He/she 可以执行
一部或多部戏剧（至少一部）
由剧院公司演出。
有可能演员被一家剧团聘用，在另一家剧团演出的戏剧中演出。
同一个演员演同一出戏很不寻常但有可能
由不同的剧院公司呈现。一家剧团 performs/presents
每年一部或多部剧。
同一出戏可以由一个或多个不同的剧团演出。
我们喜欢在数据库中存储戏剧开始表演的日期
由一家剧院公司。
同一部剧可能由不同的剧团在同一日期上演。
我们需要为一位剧作家存储his/her剧作家编号，his/her姓名。
一位剧作家写了一部或多部剧本（至少一部）。
每个剧院公司要存储在数据库中的信息
是：剧院公司编号，剧院公司名称，演出日期
剧团开办。
对于我们存储在数据库中的每个剧院公司
剧院公司开始的第一个位置（地点）
可能有不止一家剧团从同一个地方。
一家剧团必须至少聘请一名演员。
每个剧院公司都有一位独特的剧院导演。
He/she 在特定日期开始 his/her 工作。
有可能同一家剧院公司有不同的剧院导演，但时间不同，同一剧院导演管理不同的剧院
不同时期的剧院公司（从不在同一日期）。
有可能是同一个剧场导演管理同一个剧场
不同日期的剧院公司。
地点要存储的信息是：地点编号，城镇和state/department/province，地点国家
以下是我对您问题的回复：
- 每当你查看两个 table 并看到一个多对多关系时，你可以使用 link 或者 table 轻松解决问题。也称为联结 table“是一个数据库 table，它包含同一数据库中两个或多个其他数据库 table 的公共字段。它位于与其他 table 的一对多关系的多边。路口 table 有许多名称，其中包括交叉引用 table、桥梁 table、连接 table、地图 table、交叉点 table, linking table, many-to-many resolver, link table, pairing table, transition table, crosswalk, associative entity或协会 table。” Wikipedia example 你看到我在你之前的问题中使用了这些 table。在这种情况下，您是在说一个演员可以管理我的许多剧院公司和一个剧院公司，还可以管理许多演员。这是多对多，因此如果您在 table 之间为两者之间的每个关系创建一个 link table，您将在 link 中添加一个新行table 仅包含剧院公司 ID 和演员 ID。如果一个演员由许多剧院公司管理，那么您将向 link table 添加几行，每一行都包含相同的演员 ID，但每一行都有不同的剧院公司 ID。
- 是的，您可以 start_Location 直接指向地点。这意味着 Start_Location 属性必须是将剧院公司指向相关地点记录的主键 (PK) 的外键 (FK)。
- 演员当然可以出生在一个地方，但是就像上面一样，你需要在Actor中有一列，即FK到Place Table的PK。您可以将此列称为 Birth_Place，它所包含的只是 Place 中与演员出生地相关的记录的 PK。此列也需要为 NOT NULL，因为所有演员都需要 Birth_Place.
- 到目前为止，您的图表似乎可以解决这个问题，是的。请参阅问题 1 的后续补充答案。
您越来越擅长删除冗余。你的图表看起来不错。我要提出的唯一建议是，为什么你有一个游戏 table 然后是 3 个单独的游戏类型 table？为什么不将它们一起添加到名为 Play 的 Table 中。它会正好位于 Play 当前在您的图表中所处的位置，并且包含它已经包含的相同属性，但您还添加了以下内容：
一个。 Type – 可以是一个字符串，您可以在其中放置“Drama”、“Comedy”或“Tradegy”，这样您就可以确切地知道它是什么类型的戏剧。此外，这将允许您将未来的游戏类型添加到游戏中 table，而不必将全新的 table 添加到数据库中。
b。 Sub_Type – 也将是一个字符串并保存您当前在单独的 table 下的类型。它们在每个 table 中本质上都是相同的属性，并且会根据父类型持有不同的类型描述符。
c。 Main_Character – 将是一个包含主角的字符串，因为在你的三个独立的 table 中，你有主角。你只是称他们为 3 个不同的东西。 （明白我要进去的方向了吗？）
d。 Secondary_Character – 将是一个包含次要字符的字符串。你在你的戏剧和喜剧中有一个次要角色，但在你的贸易记录中没有，所以在贸易记录中，这一栏最终会变成空的。看到我在那里做了什么吗？您现在有一个 table，而您以前有 4 个，在那个 table 中，您可以检索在这 4 个单独的 table 中拥有的所有相同信息。希望这会让您的生活更轻松。
- 你可以随心所欲，但我假设你指的是最佳实践，通常认为最佳实践是将这个单一属性分成简单属性子部分。 IE。使它成为一个组合属性。
注意：这是一个粗略的副本，我还没有包括约束、弱实体……等等。这个问题我还需要好好理解一下。
问题：
要跟踪哪个剧院公司管理表演者，两个剧院公司的哪个表演者，我是否必须为其他实体集中的每个实体集制作唯一代码以跟踪它们？
可以start_Location简单地指向剧院公司实体的地点吗？
Actor可以出生在一个地方还是必须有一个指向地方的属性？
到目前为止我的人际关系有意义吗？
Plays中是否有Short_Descript等冗余属性？
我可以在 Place 中创建一个名为 "Town, State/Department/Province" 的属性吗？还是必须是组合属性？
请注意：如果我有更多问题等，我将编辑和更新我的图表...
如有任何建议或提示，我将不胜感激。
ERD：
问题信息：
一个演员出生在一个地方并且 he/she 目前居住在一个地方（此信息是必填的）。
我们只在数据库中存储演员最后已知的居住地。
我们需要演员的以下信息：演员编号、演员姓名、演员出生日期和演员死亡日期（检查是否死亡 > 出生）。
演员是表演者，or/and是戏剧导演。 我们为表演者存储 he/she 开始表演的日期。
我们为剧院导演存储开始日期his/her最后一次担任剧院导演
我们在 DBActors 中考虑以下类型的戏剧：戏剧、喜剧和悲剧。
对于每个我们喜欢存储以下数据：戏剧编号、戏剧标题、戏剧简短描述、创作年份、首次登台日期（p_date_p、日期）。
对于戏剧，我们还存储戏剧类型、主要正面角色的名称和主要反面角色的名称。
剧集类型为以下之一： “古典”、“中世纪”、“文艺复兴”、“nineteenth-century”、“现代”和 “当代”
对于喜剧，我们存储喜剧类型、主要角色的名称 字符 ，以及第二个字符的名称
喜剧类型为以下之一：“古罗马”、“古希腊”、“闹剧”、“幽默喜剧”、“风俗喜剧”、 “即兴喜剧”和“荒诞剧场”；
对于悲剧，我们存储悲剧类型（t_type，varchar(20)）和主要的名称 字符
悲剧类型为以下之一：“Greek”、“Roman”、“Renaissance”、“Neo” -古典”和“现代”
一出戏由一位或多位戏剧家创作 我们可能不认识某些戏剧的剧作家。
我们将所有已知的戏剧存储在数据库中，即使它们没有被表演（“壁橱戏剧”）
有些演员也是戏剧家。
我们在数据库中存储了所有已知的戏剧家。
一位演员在任何时间戳都被一家独特的剧院公司雇用
He/she 将在 he/she 被录用后整年留在同一家公司。
我们在数据库中存储 he/she 被剧院公司聘用的年份 （小整数）
有可能是演员换了he/she所在的剧团 his/her 一生中多次工作。一个演员有可能在不同的年份多次被同一家公司聘用。 He/she 可以执行 一部或多部戏剧（至少一部）
由剧院公司演出。
有可能演员被一家剧团聘用，在另一家剧团演出的戏剧中演出。
同一个演员演同一出戏很不寻常但有可能 由不同的剧院公司呈现。一家剧团 performs/presents 每年一部或多部剧。
同一出戏可以由一个或多个不同的剧团演出。
我们喜欢在数据库中存储戏剧开始表演的日期 由一家剧院公司。
同一部剧可能由不同的剧团在同一日期上演。
我们需要为一位剧作家存储his/her剧作家编号，his/her姓名。
一位剧作家写了一部或多部剧本（至少一部）。
每个剧院公司要存储在数据库中的信息 是：剧院公司编号，剧院公司名称，演出日期 剧团开办。
对于我们存储在数据库中的每个剧院公司 剧院公司开始的第一个位置（地点）
可能有不止一家剧团从同一个地方。
一家剧团必须至少聘请一名演员。
每个剧院公司都有一位独特的剧院导演。 He/she 在特定日期开始 his/her 工作。
有可能同一家剧院公司有不同的剧院导演，但时间不同，同一剧院导演管理不同的剧院 不同时期的剧院公司（从不在同一日期）。
有可能是同一个剧场导演管理同一个剧场 不同日期的剧院公司。
地点要存储的信息是：地点编号，城镇和state/department/province，地点国家
以下是我对您问题的回复：
- 每当你查看两个 table 并看到一个多对多关系时，你可以使用 link 或者 table 轻松解决问题。也称为联结 table“是一个数据库 table，它包含同一数据库中两个或多个其他数据库 table 的公共字段。它位于与其他 table 的一对多关系的多边。路口 table 有许多名称，其中包括交叉引用 table、桥梁 table、连接 table、地图 table、交叉点 table, linking table, many-to-many resolver, link table, pairing table, transition table, crosswalk, associative entity或协会 table。” Wikipedia example 你看到我在你之前的问题中使用了这些 table。在这种情况下，您是在说一个演员可以管理我的许多剧院公司和一个剧院公司，还可以管理许多演员。这是多对多，因此如果您在 table 之间为两者之间的每个关系创建一个 link table，您将在 link 中添加一个新行table 仅包含剧院公司 ID 和演员 ID。如果一个演员由许多剧院公司管理，那么您将向 link table 添加几行，每一行都包含相同的演员 ID，但每一行都有不同的剧院公司 ID。
- 是的，您可以 start_Location 直接指向地点。这意味着 Start_Location 属性必须是将剧院公司指向相关地点记录的主键 (PK) 的外键 (FK)。
- 演员当然可以出生在一个地方，但是就像上面一样，你需要在Actor中有一列，即FK到Place Table的PK。您可以将此列称为 Birth_Place，它所包含的只是 Place 中与演员出生地相关的记录的 PK。此列也需要为 NOT NULL，因为所有演员都需要 Birth_Place.
- 到目前为止，您的图表似乎可以解决这个问题，是的。请参阅问题 1 的后续补充答案。
您越来越擅长删除冗余。你的图表看起来不错。我要提出的唯一建议是，为什么你有一个游戏 table 然后是 3 个单独的游戏类型 table？为什么不将它们一起添加到名为 Play 的 Table 中。它会正好位于 Play 当前在您的图表中所处的位置，并且包含它已经包含的相同属性，但您还添加了以下内容：
一个。 Type – 可以是一个字符串，您可以在其中放置“Drama”、“Comedy”或“Tradegy”，这样您就可以确切地知道它是什么类型的戏剧。此外，这将允许您将未来的游戏类型添加到游戏中 table，而不必将全新的 table 添加到数据库中。
b。 Sub_Type – 也将是一个字符串并保存您当前在单独的 table 下的类型。它们在每个 table 中本质上都是相同的属性，并且会根据父类型持有不同的类型描述符。
c。 Main_Character – 将是一个包含主角的字符串，因为在你的三个独立的 table 中，你有主角。你只是称他们为 3 个不同的东西。 （明白我要进去的方向了吗？）
d。 Secondary_Character – 将是一个包含次要字符的字符串。你在你的戏剧和喜剧中有一个次要角色，但在你的贸易记录中没有，所以在贸易记录中，这一栏最终会变成空的。看到我在那里做了什么吗？您现在有一个 table，而您以前有 4 个，在那个 table 中，您可以检索在这 4 个单独的 table 中拥有的所有相同信息。希望这会让您的生活更轻松。
- 你可以随心所欲，但我假设你指的是最佳实践，通常认为最佳实践是将这个单一属性分成简单属性子部分。 IE。使它成为一个组合属性。