alexeyvgИ (или) в таблице GamePlayers хорошо бы писать, сколько голов забил игрок.
И в чьи ворота :)...

Include.nv
lLocustИ что такое табличка Positions? не совсем понятен ее смысл....


Позиции игроков.
Позиции игроков в кманде - могут меняться.
Самое главное - позиции в мачте могут отличаться от позиций в команде, и их может быть несколько :).
И самое-самое главное - зачем вообще нужны позиции :)

Include.nvЗдесь вы правы, не додумал. Но думаю стоит сделать просто поле типа enum('Win', 'Draw', 'Loss'). Тогда мы сможем легко находить нужные результаты.

Правда тогда не понятно, если играют два клуба между собой, то надо ли для каждого добавлять данные в таблицу Games? Получится избыточность.

('Winner - 1', 'Winner - 2', 'Draw')

Встречное предложение. На схеме ключевые атрибуты, опущены почти все названия и прочие атрибуты, не влияющие на связывание таблиц.

Кот МатроскинMasterZivпропущено...


Критерий простой -- можно и без него.

По этому критерию он "лишний" в 99% таблиц - там ведь найдется естественный ключ, который в принципе можно сделать первичным. Выкиньте ID из Clubs - там ключом можно сделать название (или название + город, или названия + город + страна - в данном случае неважно)
Суррогат делается не из логической необходимости (иначе он не суррогат, по определению), а для технического удобства.

При отрисовке "логических схем" (термин из PowerDesigner) поля внешних ключей отсутствуют - использовать суррогаты ни к чему.
Но:
1) часто в команде встречаются аналитики/разработчики, которые "мыслят" только "физической схемой" - они привыкли видеть все поля реальной таблицы из БД :(;
2) при работе с физической схемой составные первичные ключи из нескольких полей только усложняют (увеличивают количество) полей (и отображаемой информации);
3) бывает, что в процессе разработки (дай Бог), а то уже и эксплуатации (sick!), естественный ключ оказывается не совсем первичным; при правильном подходе не самая большая проблема, но таки кропотливая работа по изменениям.

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

Да и как показала практика - особых хлопот в реализации суррогатные ключи не доставляют...