Как вы нормализуете отношения "один к одному" или "другой"?

Question

Я храню данные по статистике бейсбола и хотел бы сделать это с помощью трех таблиц:игроки, статистика сражений и статистика питчинга.Для целей вопроса у каждого игрока будет статистика отбивания или статистика подачи, но не и то, и другое.

Как бы я нормализовал такие отношения в 3NF?

Answer 1

PlayerID будет внешним ключом как в таблицах BattingStats, так и в таблицах PitchingStats

[и не забудьте указать некоторое временное измерение (сезон, год и др.) в таблицах статистики]

и, кстати, это неверное предположение:насколько я знаю, питчерам тоже разрешено отбивать!

Answer 2

Вы действительно обязаны не использовать более 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 in Роли гарантировали бы, что у игрока может быть только одна, и только одна, роль.Наконец, добавьте проверка ограничений так что Batting_Stats.role_type = 'Batter' и Pitching_Stats.role_type = 'Pitcher'.Эти контрольные ограничения гарантируют, что Batting_Stats всегда описывает отбивающего, и обратите внимание на питчера.То же самое относится и к Pitching_Stats.

Answer 3

Я знаю, как бы я реализовал это с практической точки зрения (я бы создал объединенное представление над непересекающимися таблицами и поместил уникальный индекс в идентификатор игрока - следовательно, они могут отображаться только в одной таблице).

Или в таблице игроков запишите, какой тип статистики у них есть, а затем включите это в отношение FK из таблиц статистики.

Но любой из них, вероятно, ближе к металлу, чем вы хотите.