如何正确构建架构答案

【问题标题】：How to correctly structure schema如何正确构建架构
【发布时间】：2014-03-07 13:49:35
【问题描述】：

我参加了 DBM/BI 证书课程（更像是速成课程），我决定着手开展一个独立项目，以实时实施我正在学习的所有内容。长话短说，我将分析过去 13 年中票房最高的 130 部电影的数据 (boxofficemojo.com)（使用 MySQL 服务器/工作台。）。首先，我想绘制一个模式，然后进行一些数据挖掘/可视化。到目前为止，我是这样划分的：

"Movies"
 Movie_ID (Primary )
 Dom_Revenue
 Int_Revenue
 OpWe_Revenue
 Budget


"Rating"
Rating_ID (P)
Rating

"Release"
Release_ID (P)
Year
Month
Day
Movie_ID (F)

"Cast"
Director_Gender (P)
Lead_Gender (P)
Director_Name
Director_Name
Movie_ID (F)

"Studio"
Studio_ID (P)
Studio_Name

这些是我迄今为止的关系：

rating to movies - one to many ( many movies can be rated R , a movie can only have 1 rating )
release to movies - one to many ( many movies can be released on the same weekend, a movie can only be released once)
cast to movies - one to many (directors/actors can make many movies, a movie can only have one cast)
studio to movies - many to many (movies can be attached to more than one studio, a studio can make more than one movie)

我知道架构很可能不是 100% 正确，所以我应该将所有其他表的主键作为外键包含在“电影”表中吗？我的人际关系怎么样？

提前致谢

【问题讨论】：

标签： mysql database-design schema relational-database dms

【解决方案1】：

这与 Leo 的第一个答案有关，但我会更具体，并添加更多观察。

首先，Release 属性在功能上依赖于Movie_ID（或一般的电影），因此它不应该是单独的Entity。

其次，相对于第一个，您的发布实体中有Year、Month 和Day，为什么不将其设为Release_Date，其中包含Year、Month 和Day 反正？然后您可以再次将您的Release 属性作为Movie 的一部分。

第三，相对于第一个，为什么不添加Movie_Title 字段？

所以，总而言之，您可以拥有以下架构：

"Movies"
Movie_ID (Primary )
Movie_Title
Dom_Revenue
Int_Revenue
OpWe_Revenue
Budget
Release_Date

您可以轻松查询在某个Year 发布的电影，例如：

SELECT Movie_Title, Year(Release_Date) as Release_Year
FROM Movies
WHERE Year(Release_Date) = 2011

或者你也可以通过Year（或Month）来计算它

SELECT Year(Release_Date) as Release_Year, COUNT(*) Number_of_Movies_in_a_Year
FROM Movies
GROUP BY Year(Release_Date)
ORDER BY Year(Release_Date)

第四，在您的Cast 实体中，您说过“导演/演员可以制作很多电影，一部电影只能有一个演员表”。但是看看你的Cast，你有一个Movie属性，它是来自Movies的FK（外键），这意味着Movie可以有很多Cast，因为FK总是在许多方面。此外，这个实体几乎违反了4NF（第四范式）。因此，最好的方法可能是在您的Cast 表中进行专业化并将其与Movies 表相关联，以便它具有One-to-Many 关系或Cast 或Director 可以有很多电影。所以，它看起来像这样：

 "Cast"
 Cast_ID (PK)
 Cast_Name
 Cast_Gender
 Cast_Type (values here could either be Director or Lead or could be simply letters like D or L)

您的Movies 表现在可以更改为：

"Movies"
Movie_ID (Primary )
Movie_Title
Dom_Revenue
Int_Revenue
OpWe_Revenue
Budget
Release_Date
Lead_ID (FK)
Cast_ID (FK)

最后，您说“电影可以隶属于多个工作室，一个工作室可以制作多个电影”。 Many-to-many 关系通常具有bridge table 以创建实体之间的many-to-many 关系。因此，假设您有一个 Studio_Movie 实体/表作为您的桥接表，那么您将拥有这样的：

"Studio_Movie"
Studio_ID (PK, FK1)
Movie_ID (PK, FK2)

【讨论】：

谢谢，这真的很清楚，一个快速的问题：Movies 下的 Lead_ID 和 Cast_ID FK 代表 Cast 下的相同 Cast_ID PK 对吗？取决于 cast_type 的值？ .如果是这样，假设我的 cast_type 是主角（然后我会将其放在 Lead_ID 下），Cast_ID FK 是否会变为空值？谢谢！
我想我弄错了，它应该只是一个Cast_ID，但没有Lead_ID。但是，Lead_ID 可以改为Director_ID，然后为Directors 创建一个与之相关的实体。另一方面，如果每部电影都有一个Cast 和一个Lead，那么原始设计就不会改变。

【解决方案2】：

我觉得还可以。

我只是认为“发布”实体可能有点矫枉过正（知道同时发布了哪些电影有什么用？）所以我认为它可能只是一组电影属性。

而且你的“演员”实体也有两个导演。也许您可以将其标准化并仅保留 1 个导演（由于电影 1N 个导演，这只是添加关系的问题）

关于 FK，是的，您应该添加它们。你们的关系看起来不错。

祝你好运。

【讨论】：