Arm79Мой вариант:

Вот и Маше бы приблизительно в таком виде выложить своё творение. Только бы ещё поля прописать, чтобы виднее было что где хранится и что как связано
не видел схему, но читая
Arm79Турнир, дочерний чемпионат, молодежка - это все не нужно. У них структура такая же, как и для родительского чемпионата, то есть получилась своеобразная рекурсия (или, будет правильнее, фрактал). Максимум можно реквизит завести в таблице Чемпионаты - ссылку на родительский чемпионат.
возникла мысль, что в машиной схеме это разные таблицы. Конечно их надо удалять нафиг. Это всё одно и то же - турниры. Причём никак не связанные. Ну как первенство молодёжных команд связано с турниром премьер-лиги? Это два самостоятельных турнира. И даже ссылки на родительский чемпионат создавать не требуется. Ибо российская премьер-лига не является родительским чемпионатом по отношению к первенству молодёжных команд. Ссылка на родительский чемпионат требуется при проведении многоэтапных турниров. Например, во время перехода российского футбола на схему осень-весна, когда полтора сезона играли. Или турниры Еврокубков.
В таблице турниров прописываем:
idnameparent_idstage1Лига чемпионовnullnull21-й квалификационный раунд1132-ой квалификационный раунд124Групповой турнир135Группа А4null6Группа Б4null71/8 финала1481/4 финала1591/2 финала16

Также существует предложение изменить немного схему: матчи не надо непосредственно привязывать к чемпионатам. Матчи могут быть товарищескими, благотворительными и т.д. Чтобы уж точно турнирные матчи были привязаны ключом к турнирам (лучше говорить именно так, ибо турнир необязательно чемпионат, может быть и первенством, кубком, отборочной стадией какого-либо чемпионата) добавить промежуточную таблицу Матчи турниров (id_турнира, id_матча)

Ну и табличку "Участники турнира" необходимо иметь с ключевыми полями (id_турнира, id_команды), так как именно в этой таблице можно предусмотреть гандикап для каждой команды в турнире. Плюс - удобство создания расписания матчей - более чётко определён круг команд из которого необходимо выбирать участников матча.

Организаторы - это вообще за гранью понимания. Никак не могу увидеть смысла иметь информацию, какая организация проводит матчи. Вообще на что влияет информация, о том, кто организует игры в турнире: НПЛФ (некоммерческое партнёрство любителей футбола) и ОАО "Рога и копыта"?

VashaMasha Резве так можно в Access ссылаться одной записи таблицы на другую запись в той же таблице? У наше время щас как обычно: если не запрещено, значит разрешено. Пока не нашли ссылку, что так делать нельзя, значит можно.

P.S. Но я в своих суждениях не привязывался ни к одной БД, просто теория. Если в Access так не получится, значит не судьба однако

Arm79, матч проводится на поле. Это поле может быть где угодно. И это необязательная информация. Её пока что можно опустить, подумав над ней позже., потому как упоминание стадиона ведёт к обязательной ссылке на город (ибо стадион не может находиться неизвестно где), города к странам, в общем куча связей и справочников, а выхлопу - ноль: на формирование турнирных таблиц он никак не влияет.

P.S. нам бы с таблицей матчей ещё разобраться, а не уходить в дебри справочников

VashaMasha 1 . У вас в таблице в поле parent_id по лиге чемпионов стоит NULL. В статьях же предлагают ставить простой 0. Это принципиально? И как правильно? Мне то всё равно. В запросе чтобы достать все родительские турниры я могу забить в условие отбора что 0, что Null, всё равно запрос вернёт мне родителей. Но меня могут спросить об этом, и я должна понять принципиально это или нет, и на что это может повлиять в дальнейшем? Много не надо писать, просто укажите путь я сама разберусь. Всё таки у вас опыт, и вы проблему можете увидеть сразу.
тут просто надо понять, чем отличаются null от "ноль". "ноль" - это некое значение, null - отсутствие значения. То есть если нет родителей, то правильнее иметь null (родители отсутствуют), так как если в поле parent_id ставим ноль, то по логике значит, что должен быть турнира с id=0.
VashaMasha 2 . По вашей табличке. Каждый турнир может поменять формат. Та же лига чемпионов, я видела, использовала уже несколько форматов турнира. Тот же чемпионат России тоже. А если вашу табличку продолжить вправо и использовать её для указания таких атрибутов как очки за победу, ничью, премиальные например указать, то понятно, что записи должны ссылаться на своего конкретного родителя. То есть я так понимаю что после вашего родителя_1, нужно указать следующим потомком конкретную лигу чемпионов? И остальные потомки уже будут ссылаться на этого предка? Или я не права?
Правильно понимаете, это схема конкретного турнира. Надо было мне в первой строчке написать "Лига чемпионов 2020-2021". Добавить начисление очков можно, но так как схемы начисления очков не сильно отличаются, то проще сделать отдельную табличку для этого, а в таблице турниров поставить поле с внешний ключом на эту табличку, то есть вместо миниммум четырёх столбцов, нужно добавить только один
VashaMasha 3 . И последнее. А если регламент не меняется? Получится что у нас появятся почти идентичные записи. И база будет расти. К тому же всё это надо как то каждый сезон обновлять.
В этом ничего страшного, зато в таблице участников турнира можно спокойно к каждой стадии и каждой группе указывать команды, которые участвуют в указанной группе конкретного сезона.
VashaMashaИ сам вопрос. Можно ли добавить какое то поле чтобы не добавлять каждый сезон одну и ту же структуру? Или я тут чего то не так поняла Можно сделать всё что угодно, просто имеет ли это смысл... тут главный вопрос - как определить участников какой-либо группы любой стадии произвольного турнира
В моём предложении это делается просто парой таблиц:

А в случае боязни хранения структуры отдельного турнира нужна пара таблиц для структур чемпионатов (назовём это шаблонами):
И глядя на них непонятно, как определять участников какой-либо группы на любой стадии произвольного турнира...
VashaMasha, а вместо добавления атрибутов в эту таблицу, нужно создать ещё какую нибудь с регламентными очками, и назвать её РЕГЛАМЕНТЫ например? про начисления очков написал выше.

VashaMashaMr.Fontaineidnameparent_idstage1Лига чемпионовnullnull21-й квалификационный раунд1132-ой квалификационный раунд124Групповой турнир135Группа А4null6Группа Б4null71/8 финала1481/4 финала1591/2 финала16
И ещё один вопрос. Как же форму сделать для такой таблицы? Есть ли какие то примеры для таких таблиц?
Ну дык три поля: одно текстовое для ввода названия, и два выпадающих списка: один со списком существующих турниров и второй с номерами свободных стадий. В чём проблемы-то?

VashaMashaЕсли нельзя в Access применить так званую иерархию, то по сути такая вот табличка заменит её.

ИД_МинимальнаяЕдиницаТурнира - это индефикатор минимальной зачётной единицы турнира(в плей офф, например, в 1/4 финала он укажет на определённую пару команд; в чемпионате на определённый тур)
ИД_Турнир - здесь понятно турнир, если это товарищеский матч, то так и пишем "товарищеский матч", наверняка там ведётся статистика. Я слышала от дяди что какая то сборная была чемпионом мира в товарищеских матчах, или что вроде этого
ИД_Этап - этап это я так думала, в MLS: чемпионат и плей офф, в чемпионате России в переходном это "Чемпионат=I_этап" и "Чемпионат=II_этап", в простом чемпионате Италии - это просто чемпионат будет, плей офф уже не будет. Все эти классификаторы собрать в одну таблицу и вывести сюда ИД.
ИД_СоставляющаяЭтапа - здесь я планировала указать на что разделиться этап. Чемпионат например это 1 круг и 2 круг, плей офф - это так как в той табличке - все стадии
ИНДЕКС - это Индекс пары в плей офф. Ведь там независимые как бы маленькие турниры двух команд. И их надо как то различить. Вот по этому индексу я и хотела их различать. Для матчей чемпионата например у всех матчей он будет равен 1 например, или Пустое значение
Тур ну а тут номер тура. В плей офф можно поставить первый матч и ответный, или же цифры 1 и 2 что по сути разницы не имеет. В чемпионате тоже цифры

Так я сделала в той базе что дала выше. Но вы говорите не надо такое разделение. Как же я смогу узнать тогда матчи одного тура, или 1 круга турнира например. Сделать табличку где туры расписать по датам? Но опять же это то же самое получится, только ещё и даты таскать надо будет

Да, вот этот идентификатор, который определяла выше и подставлять в таблицу Матчей. Только не ругайте меня, что я одно и тоже показываю. Я подумала может вы не поняли из таблиц и моих кривых названий, что там к чему? Объяснила
Противостояние пары команд в 1/4 финала и тур (состоящий из нескольких матчей) чемпионата это совсем не одно и то же. Потому они не могут быть минимальной единицей турнира.

Тур вообще не может быть какой-либо единицей турнира. Понятие "тур" во время напсиания Вашей курсовой работы, вообще лучше выбросить из головы, ибо он нужен только для составления расписания кругового турнира, а алгоритм такого расписания вам совершенно не нужен, ваша программа будет пользоваться уже готовым расписанием, в котором есть дата матча и его участники. К какому туру он относится, это просто справочная информация (довольно-таки избыточная в вашем случае). Вообще минимальная единица турнира - это один матч. Но у нас и так существует таблица матчей, потому вообще не понимаю зачем нужна эта таблица...

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

VashaMasha, формально есть конечно правота в Ваших словах. Но этот случай слишком частный. Увеличивается количество строк в таблице турниров, неоправданно повышается сложность дерева турнира. Есть желание - делайте отдельной группой каждую пару.

VashaMashaMr.Fontaine,

Мистер, но ведь как то ведь надо определять результат пары? В вашем варианте мы даже не сможем их сгрупировать по парам. Конечно можно в запросе выбрать одну пару, и посмотреть результат. Но если надо посмотреть все пары? Тогда ещё сложнее получится. Но это в моём понимании, конечно. Наверное я и не права. Нужен какой то индентификатор пары. Его можно поставить( и по моему даже нужно ставить) в один ряд с группами. Или же всё таки отказаться от такой структуры. Я подумаю ещё сегодня. Но мне кажется без этого нельзя. Или же опять таблица жеребьёвки. По сути это и будет ваша вторая табличка, только появится ещё один атрибут - номер, или визави или как там назвать ещё. Там как вы и говорили наряду с группой указывать этот индификатор. Я совсем заморочила вам голову. Извините.
Ну в общем случае нет необходимости определять результат пары. Ибо практическое применение этого результата отсутствует. И группировка по полям команда1, команда2 не вызывает проблем (конечно запрос будет состоять из двух частей, соединённых union, ибо кроме связки команда1-команда2 нужно проверить связку команда2-команда1).
Потому в общем случае никаких идентификаторов пар не требуется. Нет принципиальной разницы в какой паре играют "Динамо" и "Спартак" - в первой или последней. Ни на результат их противостояния, ни на будущее распределение в следующей стадии в общем случае это не влияет.
В общем нужно осознать зачем нам нужен идентификатор пары и результат пары. И если получится найти причины использования этих понятий, то конечно требуется как-то отобразить их в БД, но обычно эти вещи никому не нужны.

VashaMashaMr.FontaineНу дык три поля: одно текстовое для ввода названия, и два выпадающих списка: один со списком существующих турниров и второй с номерами свободных стадий. В чём проблемы-то? Проблема в том, что для одного розыгрыша лиги чемпионов допустим это нормально. Всё понятно. Даже для нескольких турниров - это тоже покатит, если в название ЛЧ включить сезон, например. Включение сезона в название турнира никак не изменит выборки дочерних предметов. Это просто текст.
VashaMashaНо если спуститься уровнем ниже, например группа, то как определить к какому турниру она относится? Мы можем выбрать только групповой турнир, а к какому турниру ЛЧ относится нам уже выпадающий список не покажет. Тут уже надо строить всю цепочку на верх к родителю в выпадающем списке. Разве это проще? Или же ограничить таблицу всего двумя уровнями? Но тогда смысл в ней? Или же в названии указывать принадлежность каждой стадии к какому то сезону? Вот здесь не понятно.
я вас понимаю, ваше решение в принципе отличное для какой то очень заковыристой задачи и тогда программно можно строить всякие списки. Но здесь имея всего несколько уровней, имеет ли смысл лезть в программный код?
было б здесь одинаковое количество уровней в каждом турнире, тогда можно было бы создать и постоянный запрос с вложенными уровнями. Но сейчас, именно для данной задачи может имеет смысл создать дополнительную таблицу? Я смотрела, может вот такой вариант можно рассмотреть? http://rdbms.narod.ru/article/tree/index.html Я видела немного другую статью, но сразу не смогла её найти. Но там тоже рассматривается эти варианты. Я говорю о таблице где указать всех предков. Стоит посмотреть такой вариант более подробно или пока это не нужно?
Вложенные уровни элементарно определяются рекурсивными запросами с использованием connect by. если по какой-то причине рекурсивный запрос использовать нельзя, но требуется использовать один запрос, то чё уж - делайте дополнительную таблицу. Хотя конечно нет проблем построить дерево несколькими запросами, используя рекурсивную функцию для каждого узла.