5

野球の統計にデータを保存していますが、players、battingStats、pitchingStatsの3つのテーブルを使用して保存したいと思います。質問の目的のために、各プレーヤーはバッティング統計またはピッチング統計を持っていますが、両方は持っていません。

3NFでこのような関係を正規化するにはどうすればよいですか？

4

3 に答える 3

6

PlayerIdは、BattingStatsテーブルとPitchingStatsテーブルの両方で外部キーになります

[統計テーブルに時間ディメンション（季節、年など）を入れることを忘れないでください]

ちなみに、これは悪い仮定です。私が知る限り、投手もバットを打つことができます。

于 2010-03-23T13:56:38.057 に答える
2

本当に3つ以上のテーブルを使用しないようにする必要がありますか。正規化は通常、1つの非正規化モデルを多くの正規化された関係に分解することを意味します。

3つを超えるテーブルを持つことができる場合は、次のことを検討することをお勧めします（3NFの場合）。

Players:        ([player_id], name, date_of_birth, ...)
Batters:        ([batter_id], player_id)
Pitchers:       ([pitcher_id], player_id)
Batting_Stats:  ([batter_id, time_dimension], stat_1, stat_2, ...)
Pitching_Stats: ([pitcher_id, time_dimension], stat_1, stat_2, ...)

の属性[]は主キーを定義しますが、必要に応じて代理キーを使用できます。player_idBatters and Pitchesの属性には一意の制約が必要であり、Playersリレーションの外部キーでもある必要があります。Batting_StatsとPitching_Statsには、それぞれBattersとPitchingへの外部キーも必要です。

ただし、上記は、プレーヤーが打者または投手のみになることを強制するものではないことに注意してください。

アップデート：

プレーヤーが打者または投手だけであることを強制するために私が知っている1つの方法は、このモデルを使用することです。

Players:        ([player_id], name, date_of_birth, ...)
Roles:          ([role_id, role_type], player_id)
Batting_Stats:  ([role_id, role_type, time_dimension], stat_1, stat_2, ...)
Pitching_Stats: ([role_id, role_type, time_dimension], stat_1, stat_2, ...)

role_typeピッチャーまたはバッターを定義する必要があります。Batting_StatsとPitching_Statsには、を使用するロールへの複合外部キーが必要(role_id, role_type)です。ロールでの一意の制約によりplayer_id、プレーヤーは1つだけのロールを持つことができます。最後に、チェック制約を追加して、Batting_Stats.role_type = 'Batter'とPitching_Stats.role_type = 'Pitcher'。これらのチェック制約は、Batting_Statsが常にバッターを記述していることを保証し、ピッチャーに注意します。同じことがPitching_Statsにも当てはまります。

于 2010-03-23T14:02:31.103 に答える
1

私はこれを実際的な観点からどのように実装するかを知っています（互いに素なテーブルに対してUNIONedビューを作成し、プレーヤーIDに一意のインデックスを付けます-したがって、それらは1つのテーブルにしか表示できません）。

または、playersテーブルで、彼らが持っている統計のタイプを記録し、それを統計テーブルからFK関係に含めます。

しかし、これらのどちらかはおそらくあなたが望むよりも金属に近いでしょう。

于 2010-03-23T14:05:29.417 に答える