Реляционная петля в моей базе данных

Question

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

Я знаю, что следует избегать таких циклов, но если есть причина для каждого из них? Например, у меня есть четыре стола - игроки, команды, игры и участники. В каждой игре всегда две команды - моя команда и противники. Поэтому мне нужно добавить внешний ключ team_id в таблицу игр. Затем у меня есть игроки, каждый игрок в настоящее время играет в определенной команде, между двумя этими таблицами существует [много-одно]. И я хочу держать где-то статистику о «этом» игроке в таблице «эта» игра - участники. Что еще - мне нужно держать информацию о некоторых из моих игроков в таблице переводов, так что есть еще один цикл. Но могу ли я сохранить этот дизайн?

Answer 1

Вам следует рассмотреть возможность изменения дизайна стола.

В таблице игр:

• вы должны удалить part_Id, так как вы описываете участников в таблице участников.

• как team_id и opp_id должны быть внешние ключи к столу команд

В таблице участников

• вы должны удалить part_id первичный ключ, добавьте team_id и использовать team_id, player_id и game_id как первичный ключ, так как один игрок не может играть в обеих командах

В таблице игроков

• вы должны удалить team_Id и использовать эту таблицу, чтобы описать игроков

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

В таблице переводов вы должны иметь идентификатор передачи, идентификатор игрока, команду 1 и команду 2. Новые дополнения к этой таблице должны сигнализировать о необходимости обновить таблицу новых членов команды.

Answer 2

Циркулярные ссылки, естественно, существуют между объектами «реального мира».
Таким образом, правило должно быть понято так, как будто нам нужно избегать поддержки целостности, совместимой с РСУБД, по циклическим ссылкам.

Какие ссылки FK/PK должны быть удалены (а дополнительная информация должна храниться вместе с сущностью) - другой вопрос и ответ зависит от ваших потребностей.

Обычно фиксирование «динамического события» в РСУБД (например, трансферы или игры) «сохраняет» всю информацию и не требует использования каких-либо fk. Обработка транзакций AKA.