Как Вы нормализуете one-to-one-or-the-other отношения?

Вы действительно не обязаны использовать более 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 в Batters and Pitches должен иметь уникальное ограничение , а также должен быть внешним ключом для отношения Players. Batting_Stats и Pitching_Stats также должны иметь внешний ключ для Batters и Pitching соответственно.

Обратите внимание, однако, что вышеизложенное не означает, что игрок может быть только отбивающим или только питчером.

ОБНОВЛЕНИЕ:

Один из известных мне способов обеспечить, чтобы игрок был только отбивающим или только питчером, заключается в этой модели:

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 = 'Pitcher' . Эти проверочные ограничения гарантируют, что Batting_Stats всегда описывает жидкое тесто, и отмечают питчер. То же самое касается Pitching_Stats.

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

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

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