0

現在のデザイン:

  • Gamestable : Gameid, dmy, starttime, dayplayed, weeknumber, Hometeamdivisionid, Hometeamid, Awayteamdivisionid, Awayteamid, Hometeampointsscored, Awayteampointsscored, win-loss

  • Hometeamdivisiontable : Hometeamdivisionid

  • ホームチームテーブル: ホームチームid

  • Awayteamdivisiontable : Awayteamdivisionid

  • アウェイチームテーブル: アウェイチームid

もっと多くのテーブルが必要ですか、それとも単に別のテーブルが必要ですか?

4

1 に答える 1

1

初期観察

「ホーム チーム」と「アウェイ チーム」に別々のテーブルは必要ありません。考えてみてください。あなたにはチームがあります。これらは部門に編成されています。彼らはゲームをします。任意のゲームでは、1 つのチームがホーム チームであり、1 つのチームがアウェイ チームですが、別のゲームでは、特定のチームがホーム チームまたはアウェイ チームになる場合があります。チームは一度に 1 つのディビジョンに所属します。したがって、次のような設計が必要です。

  • 部門: 部門 ID、名前 (...)

  • チーム: チーム ID、ディビジョン ID、名前 (...)

  • ゲーム: ゲーム ID、プレイ日、開始時間、ホーム チーム ID、アウェイ チーム ID、ホーム チーム スコア、アウェイ チーム スコア (...)

明らかに、「ホーム チーム ID」は「アウェイ チーム ID」と等しくないなど、Game テーブルの値には制約があります。より複雑な制約もあるかもしれません: 2 つのチームは同じディビジョンに属していなければなりません (ディビジョン間のプレーがない場合)。Game から Team への 2 つの外部キー制約があります。

これらから、他のすべてを計算できます。「週番号」を定義するには、「カレンダー」テーブルが必要になる場合があります。特定のゲームがシーズンのどの週にプレイされたかを判断する最も簡単な方法は、おそらく次のとおりです。

  • カレンダー: 日付、シーズン ID、週番号 (...)

「チーム A」が 2012 年春に西部地区に所属し、2012 年秋に東部地区に所属していた場合などは、より複雑になる必要がありますが、一度に 1 つのシーズンしか記録する必要がないため、チームは常に同じ部門に所属している場合は、ほぼ問題なく使用できます。

より多くの情報が利用可能になりました

全体的な目標は、多くのシーズンにわたってリーグで行われたゲームを記録することです。リーグを構成するチームは安定しており、ディビジョンは 2 つしかありませんが、チームは異なるシーズンにディビジョン間を移動できます (ただし、シーズン中は移動できません)。

最初に必要な変更は、Team テーブルに対するものです。これDivision IDは、永続的な属性ではなく、特定のシーズンのチームのプロパティになりました. 暦上の問題もより重要です。

  • シーズン: シーズン ID (PK)、名前、開始日、終了日 (...)

  • 部門: 部門 ID (PK)、名前 (...)

  • チーム: チーム ID (PK)、名前 (...) (部門 ID はありません)

  • SeasonDivisionTeam : シーズン ID、ディビジョン ID、チーム ID (PK は 3 つの属性すべて)

  • ゲーム: ゲーム ID (PK)、プレイ日、開始時間、ホーム チーム ID、アウェイ チーム ID、ホーム チーム スコア、アウェイ チーム スコア、会場 ID、(...)

  • カレンダー: 日付 (PK)、シーズン ID、週番号 (...)

SeasonDivisionTeam という名前は良くありません。しかし、私はより良い名前に空白を描いています。基本的に、各シーズンの各部門にどのチームが所属していたかを定義します。これは、3 つの個別の外部キーを持つ「すべてのキー」テーブルです。シーズン テーブル (開始日と終了日を含む) とカレンダー テーブルの間には制約があります。暦表で特定の季節に指定された日付は、季節表で同じ季節に指定された日付の範囲から外れてはなりません。または、シーズン テーブルから季節の日付を削除し、カレンダー テーブルで日付の有効な範囲を定義することもできます。

おそらく、主要な運用表のデータを要約した統計表がいくつか作成されることになるでしょう。たとえば、特定の日付の部門の順位を計算することは可能ですが、計算コストがやや高くなります。「シーズンの終わり」の順位を記録するための要約表があるかもしれません。必要に応じて、各週の終わりにエントリを含めることができます。

プレーオフで何をするのが最善かはわかりません。ゲームテーブルは生データを記録できます。ゲームがプレイされた場所を記録するために、Venue 列を追加することができます。これはジュニア ディビジョンなので、シーズンの終わりに 1 日か 2 日にノックアウト トーナメントが開催されることを想像できます。この場合、短時間でゲームのクラスターがプレイされる可能性があります。または、ゲームの間隔をより定期的に空けておくこともできます。Games テーブルの構造は、これらのバリエーションのいずれかを記録できます。ただし、プレーオフの構造を定義するための表を考案することは賢明であると思われるかもしれません。最善の方法は、プレーオフ組織がどれほど安定しているかによって異なります。そのためには、より多くの情報が必要です。ただし、単純なゲームの録画に関しては、概説された Games テーブルには問題はありません。問題は、人間がプレーオフ ゲームにどのように意味を与えるかです。

于 2013-03-24T14:59:48.740 に答える