0

これはstackoverflowへの私の最初の質問です。何か間違ったことをした場合は、できるだけ早く修正することをお知らせください。

それで、私はテレビ番組用のデータベースを作成しようとしています。最良の方法を知り、現在のデータベースをより単純化 (正規化) したいと考えています。

私は次のような構造を持つことができるでしょう。

    Fringe  
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    Burn Notice
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    ... (More Tv Shows)

これが不明な場合は申し訳ありません。（説明を求めてください）

しかし、私が今持っている構造は3つのテーブルです（tvshow_list、tvshow_episodes、tvshow_link）

    //tvshow_list//
    TvShow Name | Director | Company_Created | Language | TVDescription | tv_ID

    //tvshow_episodes//
    tv_ID | EpisodeNum | SeasonNum | EpTitle | EpDescription | Showdate | epid

    //tvshow_link//
    epid | ep_link

取締役と会社は、ID によって、会社と取締役のリストを含む別のテーブルにリンクされています。

これを行うためのより単純な方法があると確信しています。

事前に助けてくれてありがとう、
Krishhanthan Lingeswaran

4

2 に答える 2

1

これを行うには、もっと簡単な方法があると確信しています。

私の知る限りではありません。あなたのスキーマは、あなたが求めている機能であると私が推測するもののためにあなたが作ることができる最も単純なものに近いです。その「改善」は実際にはそれをより複雑にするだけであり、必要性があなたの側に現れると判断するときに追加する必要があります。次の例が思い浮かびます（どれもスキーマを実際に単純化するものではありません）。

  • 私はあなたの外部キーと主キーの名前を標準化します。例として、列がありますshows.id, episodes.id, episodes.show_id, link.id, link.episode_id。
  • SeasonNum私の意見では、エピソードの表にあると私が推測するものを置くことintは、正規化の制約に違反します。これは大きな違反ではありませんが、本当にそれに固執したい場合は、別のSeasonsテーブルを作成し、それをShowsテーブルに多対1で関連付けてから、EpisodesをSeasonsにのみ関連付けます。これにより、たとえば、季節ごとに情報を添付することができます。また、情報の繰り返しを防ぎます（EpisodesテーブルのシーズンID外部キー列のタイプは表面上はINTのままですが、外部キーは哲学的に関連付け、必要なもの、およびダムデータ、所有しているものを格納します）。
  • テレビ番組のリストではなく、言語、ディレクター、会社をそれぞれのテーブルに入れることを検討してください。これは上記と同じ懸念事項であり、あなたの場合は正規化の軽微な違反です。
  • 言語、取締役、会社はすべて、協会のレベルに関して興味深い問題を抱えています。ほとんどのテレビ番組には、エピソードごとに異なる監督がいます。多くは複数の言語で、いくつかの異なる会社や時にはネットワークによって作成されています。では、この情報をどのレベルで保存する予定ですか？私はソフトウェアアーキテクトではないので、他の誰かが私よりもこの質問に答えることができますが、言語、ディレクター、企業のための多形多対多の関連付けと、これらの値を可能にする継承モデルを設定します。エピソードごと、シーズンごと、またはショーごとに指定し、何も指定されていない場合は親から値を継承します。

これらすべての提案に関する結論：プロジェクトに適切なものを選択してください。このレベルの関連付けによって提供される機能が不要であり、反復データを手動で入力することを気にしない場合（オートコンプリートシステムを実装して支援することになります）、正規化の一部を理解することができます。制約。

正規化は単なる提案です。あなたにとって正しいものを選び、あなたの過ちから学びましょう。

于 2010-11-26T19:47:33.540 に答える
1

正規化の基本的な概念は、所有しているデータの任意のアイテムのコピーを 1 つだけ保存する必要があるという考えです。すでに良いスタートを切っているようです。

ここでやろうとしていることをモデル化するには、エピソードとショーを使用して 2 つの基本的な方法があります。データベースの世界では、「1 対多」または「多対多」という言葉を聞いたことがあるかもしれません。どちらも便利ですが、どちらを使用するのが正しいかは、特定の状況によって異なります。あなたの場合、自問すべき大きな問題は、1 つのエピソードが 1 つの番組だけに属することができるのか、それとも 1 つのエピソードが一度に複数の番組に属することができるのかということです。2 つの形式について説明し、その質問に対する答えを知る必要がある理由を説明します。

最初の形式は、単なる外部キー関係です。エピソード テーブルに 'episodes' と 'shows' という 2 つのテーブルがある場合、1 つの (しかも 1 つだけの) 番組の ID を含む 'show_id' という名前の列があります。この方法では、エピソードを複数の番組に属さ​​せることができないことがわかりますか? これは「1 対多」の関係と呼ばれます。つまり、1 つの番組に複数のエピソードを含めることができます。

2 番目の形式は、関連付けテーブルを使用することです。これは、例で使用した形式です。この形式では、エピソードを複数の番組に関連付けることができるため、「多対多」の関係と呼ばれます。

最初の形式を使用することにはいくつかの利点がありますが、ほとんどの場合、それほど大きな問題ではありません。エピソードを取得するために 2 つのテーブルを結合するだけでよいため、クエリは少し短くなります。結局のところ、「1 対多」または「多対多」タイプの関係が必要かどうかを判断する必要があります。

多対多の関係が必要になる状況の例は、図書館をモデル化していて、誰がどの本をチェックアウトしたかを追跡する必要がある場合です。本のテーブル、ユーザーのテーブル、そして ID、book_id、および user_id を持ち、多対多の関係となる「books to users」のテーブルがあります。

それが役立つことを願っています!

于 2010-11-26T19:27:33.483 に答える