Как вы нормализуете отношения один-к-одному или другому? - PullRequest
Новая
       70

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

5 голосов
/ 23 марта 2010

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

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

Ответы [ 3 ]

6 голосов
/ 23 марта 2010

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

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

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

2 голосов
/ 23 марта 2010

Вы действительно должны не использовать более 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 соответственно.

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

UPDATE:

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

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.

1 голос
/ 23 марта 2010

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

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

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

...