>>Ещё один вопрос: как спроектировать эту БД так, чтобы работать с несколькими чемпионатами?

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


В общем что-то типа этого. Все конечно от специфики зависит. Например, я не знаю нужена ли вообще сущность Матчи_в_конкурсе... Зависит от статистики, которую планируешь собирать. Если один матч может участвовать в нескольких конкурсах, тогда нужно обязательно.

YuriyVTo NF
Огромное спасибо! Осталось несколько вопросов. Если не трудно, ответьте пжлста.
1) авторКоманды_в_чеммпионатах (Идентификатор команды, Идентификатор чемпионата, ...)
По-моему тут нужно еще одно поле (Идентификатор команды_в_чемпионатах, Идентификатор команды, Идентификатор чемпионата, ...)
2)Ещё если можно подскажите, как связать эти все таблицы(первичные(вродь понятно) и внешние ключи )
3) календарь(расписание) матчей с результатами сыгранных матчей будут находится в одной таблице Матчи для всех чемпионатов?

1. Это называется суррогатный ключ. Его можно вводить, а можно не вводить. Я бы не вводил.

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

Теперь про суррогатные ключи. Это такие поля, которые не являются характеристиками объекта, но которые тем не менее УДОБНО использовать разработчику. Например, у тебя в таблице Команда ключем являеся Название команды. Ведь не может же быть двух команд с полностью идентичными названиями? Однако если мы начнем связывать по этому полю, то во все подчиненные таблицы придется добавлять по длинному текстовому полю, что увеличит размер БД. Кроме того, если ты вдруг обнаружишь, что ошибся в названии команды, то тебе придется менять название во всех таблицах, где оно присутствует (вручную или триггером). Но стоит ввести идентификатор команды, как все эти проблемы сразу решаются - в подчиненных таблицах лежит маленькое числовое поле и в случае изменения названия команды тебе нужно поменять его только в одном месте (справочнике команд).
Минус такого решения - немного усложняются запросы. Сравни:

select *
from Календарь
where Команда1 = 'Барселона'

или

select *
from Календарь
where ID_Команды1 = (select ID_Команды1 from Команды where Наименование_команды = 'Барселона')

В случае "Команды_в_чемпионатах" аналогично. Использовать суррогатного ключа в ней даст преимущества только если от этой таблицы ты будет наследовать еще что-то... Иначе особого выигрыша это не даст и неоправданно усложнит запросы. Смотри сам по ситуации.

Написал все это, не подумав, что может быть ты и так все это знаешь, но удалять уже как-то жалко... ;)


2) Я глубоко над схемой не думал. А навскидку не смогу четко сказать (привык схемы рисовать).
Пара правил: бывают связи один ко многим и многие ко многим.
Например, если Команда может принимать участие только в одном чемпионате, то имеем связь Один ко Многим между таблицами Чемпионаты и Команды. Такая связь реализуется путем переноса ключевого поля из одной таблицы в другую. В данном случае из таблицы Чемпионаты в таблицу Команды. В итоге получаем:

Команды (ID_Команды, Name, ID_Чемпионата)
Чемпионаты (ID_Чемпионата, Name)

Т.е. таблица Команды могла бы выглядеть так:
1, Спартак, 1
2, Россельмаш, 1
3, Химик, 1
4, Ливерпуль, 2

А таблица Чемпинаты:
1, Российская премьер лига
2, Английская
3, Итальянская

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

Т.е.
Команды (ID_Команды, Name)
Чемпионаты (ID_Чемпионата, Name)

Команды_в_чемпионате (ID_Команды, ID_Чемпионата, ...)

Например:

Команды
1, Спартак
2, Химик
3, ЦСКА
4, Ливерпуль

Чемпионаты
1. Российский
2. Английский
3. Кубок УЕФА

Команды в чемпионате
1, 1 (Спартак в Российской)
1, 3 (Спартак в Кубке УЕФА)
4, 2 (Ливерпуль в Английской)
4, 3 (Ливерпуль в Кубке УЕФА)...


3. Я бы вел в одной.

Матчи (Идентификатор чемпионата, Идентификатор команды1, Идентификатор команды2, Дата, Счет, ...)

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

Ну раз тебе нужен, значит так тому и быть ;)
Он же все равно суррогатный, значит в принципе можно и без него обойтись. Это вопрос лично твоего удобства, а уж моя точка зрения никогда не претендовала на истину. Так что вводи. Если непонравится, потом базу перекроить будет не сложно (добавить в таблицы ниже, если таковые будут пару новых колонок, сделать туда Update, после чего прибить Идентификатор).

Заполнять таблицу Матчи можно как угодно. Не вижу никаких препятствия для заведения на автомате из текстового файла. Приложение будет идти по файлу и подготавливать из его строк необходимые insert'ы и исполнять их.
Что конкретно не понятно с полями Идентификатор1 и Идентификатор2? В матче играют две команды. Это идентификаторы этих двух команд (кстати, в качестве идентификатора ты можешь выбрать Наименование команды).
Тут опять же надо знать что за текстовый файл? Этот файл ты будешь готовить сам или скачивать откуда-то из сетки? Если второе, тогда надо под него подстроиться заранее. Например, в справочник команд занести наименования в строгом соответствии с этим файлом.

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

insert into Команда_в_чемпионате values (1,1)
insert into Команда_в_чемпионате values (1,2)

Обычная вставка.

Или ты не понимаешь как тебе наименование преобразовать в идентификатор? Так ведь справочник команд есть - select Идентификатор from Команды where Наименование = 'Спартак'...


Если ты имеешь ввиду как это будет выглядеть на форме в Дельфях при ручном заполнении, тогда юзай DBLookupCombobox.
Это выпадающий список интересный. Он связан с двумя таблицами: с Командами_в_чемпионате и с таблицей Команды.
В нем ты видишь список команд из таблицы Команда, но вся фишка в том, что когда ты какую-то команду выбираешь, этот DBLookupCombobox во вторую таблицу подставляет уже Идентификатор этой команды, а не ее название.

Если опять не угадал, что тебе нужно, извиняй :) Задавай вопрос более подробно тогда.

Блин, набирал набирал... нечаяно нажал обновить страницу и все пропало :(

Вставка
insert into Таблица (список полей которые надо заполнить) values (значения этих полей)

Если у тебя нет значений идентификаторов, а есть наименования, тогда делай селект из справочника как я уже писал выше. Его можно прямо внутри инсерта спользовать: Insert into матчи (команда1, команда2) values (select id from Команды where name='Спартак',select id from Команды where name='Динамо')

Счет поменять, update

update матчи
set Счет='2:1'
where ID_матча=1

В разделе where надо перечилять все поля, которые однозначно идентифицируют строку. Иначе может обновиться сразу несколько строк, а нам этого не надо. Т.е. после where должны идти все поля первичного ключа.

Юра, помоему пора бы тебе почитать теорию, а то мы так долго будем общаться :)
То что ты задумал, делают триггеры, хотя я не знаю будет ли поддерживать твоя СУБД триггеры.

Триггер - это программа, автоматически выполняющаяся на сервере БД в момент опред. событий (вставка, удаление, изменение таблицы). При этом триггер может выполнять ДО событие и ПОСЛЕ.

Т.о. тебе нужны триггеры на удаление записей, которые перед удалением (т.е. ДО) удалят соответствующие записи из таблица Матчи.