Вам, NickChay, пытаются объяснить, что вне контекста понятия "поставщик" и "покупатель" не имеют смысла. Контекст в данном случае - контрактные обязательства. Если хотите иметь простую возможность быстро идентифицировать поставщика или покупателя, заведите соответствующие признаки, которые будут обновляться тогда, когда контрагент выступит в соответствующей роли.

> Второй пример попроще и попоказательней. Возьмем

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

> Схема данных.

Вы, простите, учитесь или работаете? Imho на профильных факультетах должны давать хотя бы основы, чтобы на практике не делать детских ошибок.

> Таблица Участники. 1. Код. 2. Наименование.

Даже еще не открыв регламента, ясно, что должно быть сущность, идентифицирующая турнир. Что это за соревнования? Кто принимает в них участие? Кто обслуживает и организовывает эти соревнования? Где они проводятся?

> Таблица Матчи участника. 1. Код участника. Код матча. Мячи участника. Статус (хозяин/гость).

У любого турнира есть календарь. Вот в терминах календаря соревнований и пишите.

> Такая схема будет правильной?

Абстрактной правильности не бывает. Бывает соответствие техническому заданию и несоответствие.