Если один и тот же игрок не может участвовать в одном матче более одного раза, вам потребуется составной ключ {Player_ID, MatchID}, независимо от того, добавляете ли вы другой ключ (например, {Participation_ID}) или нет. .

Добавление ключа {Participation_ID} имеет смысл только в том случае, если у вас есть другие таблицы, которые ссылаются на него ¹, и вы хотите сделать их внешние ключи более тонкими, или если вы используете особенно враждебную ORM, которая требует несоставного первичного ключ.

Имеют ли столбцы справа от MatchID функциональную зависимость от составного ключа

да.

Вы можете думать о «функциональной зависимости» просто как о способе сказать, что отношение (набор кортежей) является функцией. Чтобы отношение было функцией (в математическом смысле этого слова), оно всегда должно давать одинаковый «результат» для одних и тех же «аргументов».

Если атрибуты данного ключа являются «аргументами», а остальные атрибуты являются «результатом», то два разных результата не могут быть получены из одних и тех же аргументов просто потому, что ключ уникален и, следовательно, любая конкретная комбинация значения ключевых атрибутов ² не могут идентифицировать более одного кортежа.

Таким образом, все атрибуты всегда функционально зависят от ключа. Это всегда верно для любого ключа, иначе он не был бы ключом.

Единственный вопрос - зависит ли какой-либо неключевой атрибут также от правильного подмножества ключевых атрибутов. Если это так, вы нарушили 2НФ. ³

В вашем случае, если какой-либо из атрибутов зависит от Player_ID только (или только MatchID), это нарушит 2NF.

Последнее, в чем я немного сомневаюсь, - это огромное количество столбцов. Вся информация справа от MatchID - это подробности о том, КАК игрок (Player_ID) выступил в матче (MatchID). Должны ли они быть в другой таблице?

Похоже, они там, где должны быть с логической точки зрения. Маловероятно, но возможно, что у вас могут быть какие-то физические причины для вертикального разделения данных . ⁴

Некоторые несвязанные предложения:

• Используйте согласованное именование: если есть Player_ID, должно быть Match_ID, а не MatchID (или наоборот). Ого, я пропустил ваше последнее предложение.
• Используйте единственное число для имен таблиц, по той же причине, по которой единственное число обычно используется для имен классов в ООП.

¹ Чего вы не видите, насколько я могу судить.

² Он же. «основные» атрибуты. Как ни странно, первичный атрибут не обязательно должен принадлежать «первичному» ключу (он может принадлежать альтернативному ключу), поэтому просто сказать «ключевые атрибуты», вероятно, будет лучшей терминологией, ИМХО.

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

⁴ СУБД в наши дни обычно могут обрабатывать сотни или даже тысячи столбцов, и на самом деле это не значит «огромное количество столбцов».

Столбцы {PlayerID, MatchID}, похоже, работают как составной ключ.

Столбцы справа от MatchID имеют функциональную зависимость от (составного) первичного ключа, если они представляют статистику этого игрока в одном конкретном матче.

Если эти столбцы вместо этого представляют общую статистику игроков, то они зависят только от PlayerID, и этот дизайн не входит в 2NF.

Обычные формы принимают во внимание каждый ключ-кандидат, а не только первичный ключ. Тот факт, что вы позже добавляете целочисленный идентификатор строки, ParticipationID, не меняет ничего в моих предыдущих абзацах - столбцы {PlayerID, MatchID} по-прежнему кажутся (составной) кандидатный ключ, и вы должны их учитывать.

Не существует такой вещи, как нормальная форма «У меня не слишком много столбцов». Если вам нужно 20 атрибутов, которые функционально зависят от каждого ключа-кандидата, тогда вам нужно 20 атрибутов, которые функционально зависят от каждого ключа-кандидата.