次のような構造の tv_shows という名前のデータベースがあります。
tv_shows(tv_show_id, tv_show_title, tv_show_desc, network, status)
seasons(season_id, tv_show_id, season_no, season desc)
episodes(episode_id, tv_show_id, season_id, episode_title, episode_desc, episode_ref, air_date)
テレビ番組には多くのシーズンとエピソードを含める
ことができます シーズンには多く
のエピソードを含めることができます エピソードは 1 つのテレビ番組と 1 つのシーズンにのみ属することができます。
私が知る必要があるのは、シーズン テーブルとエピソード テーブルの両方で外部キーとして表示されるERDでこれを表現する方法です。tv_shows(tv_show_id)
tv_show の主キー (tv_show_id) は、2つの子テーブル間で共有されています。
テーブルが他の複数のテーブルによって参照されていても問題はありません。その観点からあなたのデザインはOKです。
tv_show_idあなたは、インepisodesが不必要であると主張するかもしれません。season_id単独でseasonsテーブルを参照し、そこから派生させることができますtv_show_id。隠された制約もあります。に格納されているのは、指定されたのにtv_show_id格納されてepisodesいるものと同じであることが期待されます。に保存しないと、もちろんその不一致は発生しません。tv_show_idseasonsseason_idtv_show_idepisodes
はい、できます-すべきかどうかは明確ではありませんが。
エピソードが正確に1つのシーズンに属している場合、つまりシーズンなしでエピソードを作成できない場合は、シーズンとの関係に暗黙的に含まれているため、エピソードに「show_id」を含める必要はありません。これは重複しており、偽のデータにつながる可能性があります。誰かが番組の列に関連付けられていないシーズンのエピソードを挿入する可能性があります。
ただし、現実の世界では、すべてのエピソードがシーズンに関連付けられているわけではありません。たとえば、「1回限り」があります。それをモデル化する場合は、エピソードテーブルにshow_idを含めることができます。ただし、これは少し厄介なロジックにつながります。クエリでは、「show」と「episode」の間に2つのタイプの関係があることを理解する必要があります。これらの場合には、「エピソードなし」などと呼ばれるエピソードを含める方がよい場合があります。これにより、すべての関係が明確で均一になります。
または、季節に関連する「episode」というテーブルと、「one-off」という同様のテーブルを作成することもできます。
ご覧のとおり、SQLで継承スタイルの関係を処理する優れた方法はありません。
それはすべて、代理キーを使用しているか複合キーを使用しているかによって異なります。
主キーがすべて無意味な整数であり、auto_num / Identity / sequenceによって割り当てられている場合、親キーを孫に伝達する必要はありません。
ただし、の主キーがとseasonsの組み合わせである場合は、テーブルに表示するのが理にかなっています。 tv_show_idseason_notv_show_idepisodes
外部キー制約をどのように定義するかにも依存します。次のように、明確な階層を定義することをお勧めします。
テレビ番組-|-----<シーズン-|----<エピソード
これは、たとえそれepisodesが含まれていても、そこにたどり着くためtv_show_idに通過seasonsすることになっていることを明確にしています。実際には、いつでも直接参加できますが、参照整合性の観点から、番組Aを指すエピソードと番組Bのシーズンを同時に心配する必要はありません。