0

私は 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% 正しいとは限らないことはわかっているので、他のすべてのテーブルの主キーを "movies" テーブルの外部キーとして含める必要がありますか? 私の関係はどうですか？

前もって感謝します

4

2 に答える 2

0

これはレオによる最初の回答に関連していますが、より具体的に説明し、さらに観察を追加します。

まず、Release属性は (または一般的には映画) に機能的に依存してMovie_IDいるため、別個の であってはなりませんEntity。

第二に、最初のものに関連して、あなたは を持っており、YearRelease Entityでを持っている Release_Date にしないのはなぜですか? 次に、属性の一部として属性を再度作成できます。MonthDayYearMonthDayReleaseMovie

Movie_Title3 番目に、1 番目に関連してフィールドを追加してみませんか?

したがって、全体として、次のスキーマを持つことができます。

"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エンティティで、「監督/俳優は多くの映画を作ることができますが、映画にはキャストが 1 つしかありません」と述べました。しかし、あなたを見るCastと、 （外部キー）からのMovie属性があります。これは、が常に多側にあるため、 aが多く持つ可能性があることを意味します。そして、この実体は、4NF (第 4 正規形) に違反しているようなものです。したがって、おそらくこれを行うための最良の方法は、テーブルを特殊化し、それをテーブルに関連付けて、リレーションシップまたは aまたは多くのムービーを持つことができるようにすることです。したがって、次のようになります。FKMoviesMovieCastFKCastMoviesOne-to-ManyCastDirector

 "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)
于 2014-03-07T05:49:35.853 に答える
0

それは私には大丈夫です。

「リリース」エンティティは少しやり過ぎかもしれないと思います (どの映画が同時にリリースされたかを知るために何を使用しますか?) ので、それは映画の属性のセットである可能性があると思います。

また、「キャスト」エンティティには2人の取締役がいます。たぶん、それを正規化して、監督を1人だけにしておくことができます（映画1 <--> N監督なので、関係を追加するだけの問題です）

FK については、はい、追加する必要があります。あなたの関係は順調に見えます。

幸運を。

于 2014-03-07T00:37:24.063 に答える