Question

我参加了DBM / BI证书课程（速成课程更像），我决定开始一个独立的项目来实现我正在实时学习的一切。长话短说，我正在分析有关过去13年中收视率最高的130部电影（使用MySQL服务器/工作台）的数据（boxofficemojo.com）。首先，我想绘制一个模式，然后进行一些数据挖掘/可视化。以下是我到目前为止如何拆分它：

"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％正确所以我应该将所有其他表中的主键作为“电影”表中的外键包含在内吗？我的关系怎么样？

提前致谢

Answer 1

对我来说没问题。

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

此外，您的“演员”实体还有两名董事。也许你可以将其标准化并只保留1个导演（因为电影1＆lt; - ＆gt; N导演，这只是增加关系的问题）

关于FK，是的，你应该添加它们。你们的关系很好。

祝你好运。

Answer 2

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

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

其次，与第一个相关，您的发布实体中有Year，Month和Day为什么不将其作为具有Year的Release_Date，{ {1}}和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来自FK的{{1}}（外键）属性，这意味着Movies可以有很多Movie，因为Cast总是在很多方面。此外，这个实体几乎违反了4NF（第四范式）。因此，可能最好的方法是在FK表中进行专业化，并将其与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

如何正确构建架构

2 个答案: