您如何规范一对一或另一方的关系？

发布于 2024-08-25 19:58:23 字数 110 浏览 8 评论 0原文

我正在存储棒球统计数据，并希望使用三个表来存储：球员、击球统计和投球统计。出于该问题的目的，每个球员都会有击球统计数据或投球统计数据，但不能同时具有两者。

我如何在 3NF 中规范这种关系？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

仙女 2024-09-01 19:58:23

PlayerId 将是 BattingStats 和 PitchingStats 表中的外键

[并记住在统计表中放入一些时间维度（季节、年份等）]

顺便说一句，这是一个错误的假设：据我所知，投手也可以击球！

回复收藏 0 原文

叹倦 2024-09-01 19:58:23

你真的要求不要使用超过 3 个表吗？标准化通常意味着将一个非标准化模型分解为许多标准化关系。

如果您可以拥有 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_id 属性应具有唯一约束，它也应该是玩家关系的外键。 Batting_Stats 和 Pitching_Stats 也应该分别具有击球手和投球的外键。

但请注意，上述内容并不强制规定球员只能是击球手或投手。

更新：

我知道强制球员只能是击球手或投手的一种方法是通过此模型：

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 的唯一约束将确保一名玩家只能拥有一个角色。最后添加检查约束，以便Batting_Stats.role_type = 'Batter'和Pitching_Stats.role_type = '投手'。这些检查约束保证 Batting_Stats 始终描述击球手，并注意投手。这同样适用于 Pitching_Stats。

Are you really required not to use more than 3 tables. Normalization normally implies breaking down one non-normalized model into many normalized relations.

If you can have more than 3 tables, you may want to consider the following (in 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, ...)

Attributes in [] define the primary key, but a surrogate key may be used if preferred. The player_id attribute in Batters and Pitches should have a unique constraint, and it should also be a foreign key to the Players relation. Batting_Stats and Pitching_Stats should also have a foreign key to Batters and Pitching respectively.

Note however that the above does not enforce that a player can be only a batter or only a pitcher.

UPDATE:

One method I am aware of to enforce that a player is only a batter or only a pitcher, is through this model:

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, ...)

The role_type should define a pitcher or a batter. Batting_Stats and Pitching_Stats should have a composite foreign key to Roles using (role_id, role_type). A unique constraint on player_id in Roles would ensure that a player can only have one, and only one, role. Finally add check constraints so that Batting_Stats.role_type = 'Batter' and Pitching_Stats.role_type = 'Pitcher'. These check constraint guarantee that Batting_Stats is always describing a batter, and note a pitcher. The same applies for Pitching_Stats.

回复收藏 0 原文