Инструменты. База данных

[Мозговой Роман]

Мой вопрос больше касался тех ситуаций, когда в разных источниках приводятся разные данные:
- в источнике 1) : "Феррари-100"
- в источнике 2) : "Феррари-101"
Какой выбрать? Один из двух, а второй указать в примечании (и источники).
 
И второй вопрос. Не увидел названий команд в твоей базе. Это намеренное умалчивание?

[Александр Кульчицкий]

И второй вопрос. Не увидел названий команд в твоей базе. Это намеренное умалчивание?

Я тоже не вижу команды (заявителя).

[Владимир Коваленко]

Мой вопрос больше касался тех ситуаций, когда в разных источниках приводятся разные данные:
- в источнике 1) : "Феррари-100"
- в источнике 2) : "Феррари-101"
Какой выбрать? Один из двух, а второй указать в примечании (и источники).

Да, поле "Примечание" нужно для подобных ситуаций, но выход из положения я вижу в несколько иной форме. Я планирую создавать отдельную запись для каждого различающегося события, а вот в примечаниях можно указать объяснение.
Помимо противоречивой информации сюда можно отнести ситуации с попеременным вождением одного и того же автомобиля. Например, если Фанхио стартовал на автомобиле под номером 1, затем сошёл и пересел на автомобиль под номером 2, которым управлял Коллинз, то в БД будут три записи:
№1; "Феррари"; Фанхио;
№2; "Феррари"; Коллинз;
№2; "Феррари"; Фанхио.
И тут для каждой из записей в примечаниях надо указать, при каких обстоятельствах гонщик был за рулём автомобиля. Вероятно, можно сделать ещё одно поле, в котором указать диапазон кругов участия.
А что касается предложенной тобой ситуации, то будут две записи с разными вариантами автомобиля. Поскольку нет гарантии, что какой-то из двух источников - более корректный, то и обоим вариантам надо дать равные права, верно? А такое возможно, только если будут две записи. В противном случае какой-то из вариантов нужно признать главным и указать в основном поле, а другой - в примечании.
Но бывают ситуации, когда все источники дают один вариант, а какой-то ещё источник - другой. Тогда, я думаю, новой записи не требуется, а противоречащую запись можно указать в примечаниях, как ты и предлагаешь.

И второй вопрос. Не увидел названий команд в твоей базе. Это намеренное умалчивание?

Да, это я пока упустил, но сделаю. Спасибо за замечание.
Александр правильно заметил насчёт заявителя. Я ориентируюсь на автоспорт системы классов и чемпионатов, который существовал до нынешней системы серий, а тогда понятие команды практически не существовало. Вместо него было как раз такое важное явление, как "заявитель".

[Владимир Коваленко]

Ещё я намереваюсь ввести такой пункт, как тип гонки:
а) в общим стартом;
б) с раздельным стартом;
в) гандикап с общим стартом;
г) гандикап с раздельным стартом;
д) гандикап комбинированный;
е) гандикап по длине круга.
В некотором смысле, современные гонки с добавлением некоторым участникам балласта можно было бы назвать гандикапом по массе, но тут на самом деле работают несколько иные механизмы.

[Владимир Коваленко]

Добавил заявителей, статус и тип гонки:

[Владимир Коваленко]

Важный вопрос: можно ли в "Асессе" дату вводить не точную, а приблизительную. Например, если известно, что какая-нибудь редкая гонка проходила в апреле, скажем, 1932 года, но точная дата неизвестна, то можно ли сохранить дату как хх.04.32 или 00.04.32?

[Владимир Коваленко]

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

[Владимир Мальчиков]

 

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

Может тогда просто поле оставлять пустым лучше?

[Владимир Коваленко]

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

[Владимир Мальчиков]

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

[Владимир Коваленко]

На "Аксессе".

[Владимир Коваленко]

Вот как выглядит схема данных на сегодняшний день:

У меня есть большое подозрение, что я что-то не так делаю. Скорее всего, мне надо переходить от заполнения таблиц к заполнению форм, но с формами я ещё не разобрался.
Я разобрался с подстановками и необходимыми для заполнения полями, и теперь процесс заполнения таблиц выглядит следующим образом (пока что я ограничился таблицей соревнований).
1. Надо оценить, в какой стране проводилась планируемая с внесению в БД гонка, и вписать в таблицу языков язык этой страны, если его там ещё нет.

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

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

4. Внести в таблицу населённых пунктов город, близ которого располагалась трасса, а в случае с линейными трассами между городами - город, откуда гонка стартовала.

5. Ввести запись в таблицу названий соревнований.

6. В таблице типов трасс указать тип.

Основные типы трасс я внёс, так что пока что этот шаг также можно пропускать.
7. Внести трассу в таблицу трасс.

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

Ну и как? Что я делаю неправильно (а что-то тут действительно не так).

[Владимир Коваленко]

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

[Владимир Коваленко]

С помощью трёх книжек мне удалось довольно далеко продвинуться в работе над базой данных. Теперь я обратился к интерфейсу. Вот как предварительно выглядит главное окно:

[Владимир Коваленко]

А вот и сам файлик БД: motorsports.rar (http://disk.tom.ru/fksldl4).

[Владимир Коваленко]

Файлик был скачан четыре раза. Каковы мнения, замечания, предложения?

[Александр Кречетов]

У меня при выборе 1894, 1895 и 1896 годов вылезают в "Аксессе" четыре такие окна:
 
=================================================
Неизвестные приложению 'Microsoft Access' единицы измерения
Задайте допустимые единицы, например дьюмы (") или сантиметры (см).
=================================================
 
После нажатия на "Ок" открывается запрос.
 
И ещё немного напрягает достаточно темный синий цветАлександр Кречетов39628,7543981482

[Владимир Коваленко]

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

[Владимир Коваленко]

Для 1894 и 1895 годов по кнопочкам теперь открываются формы. Мне помогает разобраться один добрый человек. Будем ковырять дальше.
motorsports-2008.07.01.rar (http://disk.tom.ru/jfqfnbu)

[Владимир Коваленко]

В сегодняшнем варианте БД при нажатии всех годовых кнопок выдаётся форма списка соревнований, но записи есть только для 1894 и 1895 годов.
motorsports-2008.07.02.rar (http://disk.tom.ru/6px1qqh)
В форме списка я убрал выпадающий список, но при этом не исправил отображение кодов вместо названий. Это сделаю позже.
Просто добавление новых записей будет происходить по иной схеме: при нажатии кнопки "Добавить соревнование" будет открываться форма со всеми необходимыми полями для заполнения.

[Владимир Коваленко]

Текущая версия базы данных: motorsports-2008.07.24.rar (http://disk.tom.ru/fgcprlu).
Что в ней можно увидеть? Нажмите кнопку любого года (но пробные записи есть пока только для 1894 и 1895 годов). Появится список соревнований. Его нельзя редактировать прямо в этой таблице. Редактирование пока что вообще не реализовано. Зато мы (мне помогает программист по имени Павел) работаем над добавлением новых записей. Нажмите на кнопку "Добавить соревнование" - откроется специальная форма. Её вид и содержание я буду корректировать. Если в выпадающем списке "Страна" выбрать страну, то в поле "Название по-английски" автоматически появится английское соответствие.
Эта форма предназначена для добавления новых соревнований, но поскольку при этом необходимо выбирать записи из нескольких материнских таблиц, а в случае их отсутствия - добавлять, то я закладываю в форму все необходимые для заполнения поля в той последовательности, в которой они должны заполняться, если этим заниматься вручную через сами таблицы.
Также я продумываю вариант использования БД англоязычными пользователями, для чего некоторые поля надо продублировать английскими соответствиями.

[Владимир Коваленко]

Я предусматриваю указание следующей информации о трассах в БД.
1. Полное официальное название трассы, например: "Автодром имени Жиля Вильнёва".
2. Полное официальное название в оригинале. Для вышеуказанной трассы с ходу назвать не могу, но пусть будет Gilles Villeneuve Circuit.
3. Условное название, то есть то, которое можно было бы использовать в обиходе без потери смысла. В данном примере - просто "Монреаль". Другой пример: "Валенсия ("Рикардо Тормо")" и "Валенсия (городская)".
4. Условное название по-английски (Montreal).
5. Длина круга. Поскольку трассы модифицируются, длина круга меняется, задумано, что каждый вариант будет иметь отдельную запись, в которой четыре названия будут оставаться теми же, а длина круга и годы функционирования - меняться.
6. Период функционирования.
Я изначально закладывал указание характерного населённого пункта, то есть такого, в котором либо близ которого расположена трасса, но сейчас сомневаюсь в том, нужно ли это.
Если смотреть на ситуацию с точки зрения таблиц соревнований, то не нужно. Если предусмотреть БД как обширный источник статистической информации, то можно себе представить путеводитель по трассам, в котором можно было бы указывать самые разнообразные параметры. Тут населённый пункт с географическими координатами могли бы пригодиться.
Какие ещё данные можно представить в "карточке" трассы? Схему, указание страны. Кнопку для выборки из БД по данной трассе. Что ещё?

[Владимир Коваленко]

Посмотрел известные мне статистические сайты о трассах. Вот, например, страницы, посвящённые "Заксенрингу":
http://www.etracksonline.co.uk/Europe/Germany/sachsenring.html
http://www.gdecarli.it/php/circuit.php?var1=395&var2=2
Не нашёл на них ничего существенного, что потребовало бы добавления в таблицу БД.
Всё ещё думаю насчёт добавления характерного географического пункта. Вчера ещё счёл, что в этом смысла нет, а сегодня вспомнил такие примеры, как американские трассы, которые очень часто в публикациях фигурируют как, например, "Чикаголэнд", "Инфинеон", "Кентакки (Спидуэй)", но могут использоваться и имена населённых пунктов: Джолиет, Сонома, Спарта.
Изначально задумывалось, что будут использоваться не только населённые пункты, но и горы (для подъёмов), острова (например, Филлип-Айленд) или сооружения ("Кристал Пэлас"). Также учитывалось, что в английском языке крупные и небольшие города называются по-разному (city и town), но то, что у них town, у нас чаще всего - деревня.

[Александр Кречетов]

Вот ещё пара одинаковых сайтов, трассы там отсортированы по типам
 
http://www.the-fastlane.co.uk/racingcircuits/
http://theracingline.net/racingcircuits/racingcircuits/index.htmАлександр Кречетов39655,7515509259

[Владимир]

 

Я предусматриваю указание следующей информации о трассах в БД.
Какие ещё данные можно представить в "карточке" трассы? Схему, указание страны. Кнопку для выборки из БД по данной трассе. Что ещё?

Да.
Страна.
Город
Далее можно и указать ближайший населеный пункт, как ты и сказал.
Схема трассы - это тоже хорошо. При этом схема будет не одна, так как конфигурация трасс изменяется.
Направление движения (хотя для разных серий оно может быть разным... , поэтому немного спорный параметр.)
Число поворотов.
Названия участков трассы.
Ширина трассы (примерная хотя бы).
Перепад высот.
Тип трассы. Это конечно не очень объективный параметр, но понятно же, что Монца скоростная трасса, Монако медленная. А скажем Хоккенхайм нынешний - имеет и повороты и прямые.
Вид трассы. Например, дорожная (кольцевая), овальная (трек).
Активность трассы. Например, действующая, тестовая, не функционирующая.
Максимальное число мест для зрителей (возможно лишнее).
Покрытие трассы.  Ведь  говорят, что на определенных трассах шины стираются  быстрее, на других износ шин меньше...  Например: абразивное, нормальное.
Дата открытия трассы.

***
Больше ничего пока не вспомнил. Спрошу одного товарища, может что и подскажет еще... .
Да и еще. Предусмотреть поля, это не значит, что все их обязательно нужно  заполнять сразу. Некоторые данные возможно станут известны со временем.




 
 

[Владимир Коваленко]

Большинство из этих параметров относятся к тому, что я называю статистическим подходом. Если ты возьмёшь несколько списков подобных описаний и прочтёшь их, то поймёшь, что ровным счётом ничего не понимаешь. Это задача не для пользователя, а для автора: сделать ради того, чтобы сделать.
Моя цель - несколько иная: предусмотреть базовую информацию для дальнейшей работы. Трассу и её варианты надо как-то уникально идентифицировать по минимальному набору параметров.
Я намереваюсь в ближайшее время попробовать внести в БД разные варианты трассы в Сильверстоуне. Широко известно, что в 1948 году у неё была конфигурация с использованием ВПП, в 1949-м - периметр в петлёй в "Клабе", с 1950-го на лет двадцать - только периметр. Потом было много всяких добавлений и изменений. Но мало кто знает, что ВПП использовались для 100-мильной гонки Ф3 в 1950 году, в 1954 году комбинированный вариант трассы использовался для эстафетной 6-часовой гонки, а в пятидесятые-шестидесятые годы Клуб старинных автомобилей проводил свои соревнования ещё на одном, укороченном, варианте трассы. И это только то, что попадалось мне на глаза.
В наше время есть клубное, южное и другие кольца. Если мне удастся разделить все эти варианты с помощью выбранного набора параметров, хорошо.
Кстати, для обоснованности параметра можно представить себе выборку по нему и её возможное использование. Взять, например, ширину трассы. Представим, что мы задали базе данных выбрать все трассы с шириной полотна 10 метров и получили список. И что? Как будет выглядеть обзорная статья по этим трассам? Глупо или нет? В данной ситуации думаю, что не совсем достойно. Ну и что, что 10 метров? А если 11 - в чём принципиальная разница? Возникнет пёстрый набор из трасс разного типа в разных странах, объединённых только шириной дорожного полотна.
Возможно, об этом и надо было написать в смом начале. То есть параметр должен быть таким, чтобы выборка по нему имела смысл.

[Мозговой Роман]

gp2
Кроме всего перечисленного у трассы есть официальное название, которое тоже со временем может изменяться.

[Владимир Коваленко]

gp2
Кроме всего перечисленного у трассы есть официальное название, которое тоже со временем может изменяться.

Собственно, это я уже заложил.

Я предусматриваю указание следующей информации о трассах в БД.
1. Полное официальное название трассы, например: "Автодром имени Жиля Вильнёва".
2. Полное официальное название в оригинале. Для вышеуказанной трассы с ходу назвать не могу, но пусть будет Gilles Villeneuve Circuit.
3. Условное название, то есть то, которое можно было бы использовать в обиходе без потери смысла. В данном примере - просто "Монреаль". Другой пример: "Валенсия ("Рикардо Тормо")" и "Валенсия (городская)".
4. Условное название по-английски (Montreal).
...

Получается, все параметры (поля) можно разделить на две группы: основные и дополнительные. Основные - это поля, напрямую влияющие на идентификацию трассы. Это официальное название, а также название, которое я назвал условным. То есть, если у трассы длинное название, которое неудобно использовать каждый раз, для него выбирается более короткое название, которое и в обиходе используется достаточно часто.
Также к соновным параметрам можно отнести длину трассы и её тип (линейная, линейно-кольцевая, кольцевая, подъём, спринт); возможно - годы функционирования и направление движения.
Дополнительные параметры не влияют на идентификацию трассы, и выборка по ним, как правило, особого смысла не имеет. Это и уже обсуждавшаяся ширина трассы, и перепады высот, и количество поворотов.

[Мозговой Роман]

Владимир, у тебя получается три, а не две группы параметров:
1. Ссылочные (для перекрёстных ссылок/идентификации)
2. Поисковые (параметры, по которым возможен поиск)
3. Информационные (любая дополнительная информация, не затрагивающая первые две позиции).

[Владимир Коваленко]

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

[Мозговой Роман]

Постараюсь пояснить.
1. Параметры, которые будут ключевыми для обозначения конкретной трассы, на которые будут ссылаться другие поля базы.
2. Параметры, по которым будет возможна выборка из базы (страна / тип трассы / по диапазонам километража / по видам проводимых соревнований)
3. Дополнительная информация, не стоящая выборки, но расширяющая данные по трассе (конфигурация и её изменения, повороты и т.п)

[Владимир Коваленко]

Если я правильно понял, 3 пункта соответствуют трём абзацам объяснения:

Получается, все параметры (поля) можно разделить на две группы: основные и дополнительные. Основные - это поля, напрямую влияющие на идентификацию трассы. Это официальное название, а также название, которое я назвал условным. То есть, если у трассы длинное название, которое неудобно использовать каждый раз, для него выбирается более короткое название, которое и в обиходе используется достаточно часто.
Также к соновным параметрам можно отнести длину трассы и её тип (линейная, линейно-кольцевая, кольцевая, подъём, спринт); возможно - годы функционирования и направление движения.
Дополнительные параметры не влияют на идентификацию трассы, и выборка по ним, как правило, особого смысла не имеет. Это и уже обсуждавшаяся ширина трассы, и перепады высот, и количество поворотов.

[Владимир Коваленко]

Вариант базы на сегодняшний день: motorsports-2008.07.28.rar (http://disk.tom.ru/aursyfw).
Теперь в нём работает автозаполнение полей при выборе трассы. Теперь будем работать над добавлением всего этого добра в таблицу соревнований, добавлением новых записей во все материнские таблицы и редактированием записей.

[Мозговой Роман]

Если я правильно понял, 3 пункта соответствуют трём абзацам объяснения:
 

Понял правильно. Я всего лишь постарался "причесать"

[Владимир]

 

1Основные - это поля, напрямую влияющие на идентификацию трассы. Дополнительные параметры не влияют на идентификацию трассы.

2. и выборка по ним, как правило, особого смысла не имеет. Это и уже обсуждавшаяся ширина трассы, и перепады высот, и количество поворотов.

1. Ты делаешь БД ТОЛЬКО для задачи идентификации трасс или для накопления/систематизации/ и дальнейшего хранения, использования и модификации информации о трассах?

2. Смысл выборки определяет пользователь/заказчик БД.  Просто в данном случае ты выступаешь и в роли разработчика и в роли заказчика/пользователя.

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

[Владимир Коваленко]

1. Ты делаешь БД ТОЛЬКО для задачи идентификации трасс или для накопления/систематизации/ и дальнейшего хранения, использования и модификации информации о трассах?

Трассы сами по себе целью моей БД не являются. В ней три основные таблицы: список соревнований, список гонок и результаты гонок. То есть ты нажимаешь на кнопку, например, "1953" и получаешь список соревнований (напомню, что соревнование - это мероприятие, в рамках которого проводится несколько разных заездов). Каждое такое соревнование определяется уникальным сочетанием из названия соревнования и конкретной даты. То есть сама по себе дата может повторяться, если в один день в мире состоялись несколько соревнований; также соревнования с одинаковым названием проводятся ежегодно и в списке будут повторяться. А вот сочетание регулярного соревнования и конкретной даты - уникальная комбинация.
Кстати, можно отталкиваться не от соревнований, а от трасс, то есть уникальной будет комбинация из даты и трассы, на которой проводятся гонки.
В обоих случаях кажется, что без третьего параметра картина получается абсолютно не полной. Надо либо трассу добавить, либо соревнование.
Раз я выбрал в качестве одного из основных параметров соревнование, то трасса будет необходимым дополнением.
То есть информация о трассе нужна для того, чтобы в таблице соревнований было понятно, с чем мы имеем дело.
У трасс есть тоже свои уникальные комбинации: это её название или местоположение и длина круга (дистанции), а также иногда направление движения. Эти два (три) параметра способны полностью описать любой вариант трассы.
Пусть в таблице соревнований для "Большого приза Великобритании" стоит название трассы "Сильверстоун (1952)". Если тебе любопытно, ты можешь нажать кнопку и узнать, в чём заключается особенность трассы варианта 1952 года, то есть какой была длина круга. В идеале надо добавить изображение схемы трассы. Я постараюсь это сделать.
Так что, как видишь, хранение информации о трассах - это третьестепенная задача такой БД, но я всё равно оцениваю возможность добавления новых полей. В данном случае структура БД такова, что в таблицу трасс любой дополнительный параметр можно будет безболезненно добавть.

[Владимир Коваленко]

motorsports-2008.07.29.rar (http://disk.tom.ru/mnbj1f7)

[Владимир Коваленко]

После более чем полуторагодового перерыва я возобновил работу над базой данных с помощью одного хорошего человека.
Текущая версия: motorsports-2010.04.16.rar (http://disk.tom.ru/jkumhr4).
За два месяца работа продвинулась далеко вперёд.

[Владимир Коваленко]

motorsports-2010.06.11.rar (http://disk.tom.ru/dsb2zp8)
Я начинаю потихоньку переходить от инструментов для заполнения БД к средствам пользования ею. Сейчас мне предстоить разработать самое главное: формы просмотра результатов. А пока что я сделал формы для просмотра справочных таблиц: по гонщикам, трассам, автомобилям и т.п. Точнее, это пока наброски. Понажимайте кнопочки, посмотрите, как это выглядит.

[Владимир Коваленко]

Текущая версия базы данных: motorsports-2010.06.22.rar (http://disk.tom.ru/znrwpjw)
Я вплотную подобрался к оформлению результатов. Взгляните на схему:

Основаня таблица - справа вверху. "Результат" - это результат конкретного участника в конкретном заезде. Участники и заезды берутся из других таблиц, потому что это повторяющиеся данные, то есть и участник фигурирует в нескольких заездах, и заезд указывается для нескольких участников.
"Заезд" - это любая законченная сессия (тренировки, квалификации, разминки, гонки). "Гонка" - это главный заезд, к которому относятся предварительные. Соревнование состоит из гонок, гонки состоят из заездов (предварительных и главных).
"Участник" - это конкретный гонщик на конкретном автомобиле с конкретным номером в конкретной гонке. Заявляются участники на конкретную гонку, поэтому в рамках всех заездов каждой гонки, по идее, составляющие "участника" меняться не должны. Пересаживания с одной машины на другую в гонках или случайные выезды на трассу посторонних гонщиков в тренировках оформляются введением нового участника, для чего в таблицу участников надо ввести ещё признак: основной или дополнительный участник. Основной - это участник в "комплектации" согласно заявочному списку. Дополнительный - любая комбинация, не соответствующая заявочному списку.
Таким образом, каждый "результат" - это результат конкретного участника в конкретном заезде.
Отсюда надо плясать при создании формы протокола каждого заезда, чем я и займусь в самое ближайшее время.

[Владимир Коваленко]

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


Одна и та же трасса может быть в нескольких вариантах. Более того, на одном и том же месте могут быть принципиально разные варианты трасс, как, например, в случае с Кялами, когда трассу перестроили до неузнаваемости (если не ошибаюсь, даже 2 раза), но каждый раз использовали участки предыдущего варианта. Или, насколько я понимаю, на соверменном "Заксенринге" использована старая стартовая прямая. Или после закрытия городской трассы в Уоткинс-Глене несколько лет гонки проводились по дорогам в полях, а потом ровно на этом самом месте была построена современная трасса с совершенно новым профилем.


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


Автомобили. Не всегда в первоисточниках содержится полная информация. Если совершенно точно известно, что гонщик выступал на "Мазерати-250Ф" с таким-то номером шасси и таким-то номером двигателя, то в справочнике можно смело выбирать именно этот вариант. То есть на самом глубоком уровне автомобили должны идентифицироваться по номеру шасси плюс номер двигателя. Уровнем выше - только номер шасси, ещё выше - модель. И если написано, что гонщик выступал на "Мазерати" без указания каких-либо подробностей, выбираем просто эту марку.


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


Я думаю, что выше я написал не совсем корректно. Получается, на первом уровне (самом общем) будет справочник марок, на втором - моделей, на третьем - шасси, на четвёртом - комбинаций шасси + двигатель. Я так понимаю, заполняя базу данных, нельзя в поле "Автомобиль" помещать значения из разных справочников. То есть, если мы знаем максимум информации, то пометстить данные из справочника с шасси и двигателем, а если знаем только марку - данные из справочника марок. Поэтому в справочнике 4 уровня помимо комбинаций "шасси + двигатель" будут три записи общего порядка: марка, модель и шасси.

[Юрий Карасёв]

Я бы предложил немного другую структуру.
1-й вариант - Справочник Автомобиль (комбинация Марка + Модель + Шасси + Двигатель).
При этом в справочнике Автомобиль можно указать только Марку, например Maserati.

Затем когда станет известна модель и Двигатель - можно дополнить.
При этом в справочниках может соблюдаться иерархия. Т.е. Модель подчинена конкретной Марке, а Двигатель и Шасси либо конкретной Модели, либо конкретной Марке (например, дял случаев, когда конкретный номер двигателя устанавливался на несколько разных Моделей).

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


2-й вариант - указывать Марку, Модель, Шасси и Двигатель непосредственно в данных о соревновании. Т.е. вместо колонки "Автомобиль" будет четыре колонки: Марка, Модель, Шасси, Двигатель. Иерархия при этом также может остаться.

[Владимир]

С точки зрения реализации базы данных все проще в плане формирования таблиц,
Проблема повышения уровня решается так.
одной таблицей задаются марки машин - Ferrari, Benetton, Lotus, Williams.
Второй таблицей задаются модификации для каждой машины машины - 1,2,3, неизвестно.
Третьей для каждой модификации - номера шасси  001, 002, 003, неизвестно. 
И затем формируется общая таблица по машинам.
(например, как в базах данных разделяют столбцы фамилия, имя, отчество.
А потом добавляют, напроимер, должность с отношением "один ко многим" - на одной должности может быть от нуля до Х сотрудников с разными ФИО).
 
Аналогично для двигателей.
Но тут же нужно учесть информацию о заявителях, гран-при и их результатов и прочих тонкостей.
Тот же столбец "класс машины", который был предложен Владу  для решения одной проблемы.
Столбец - "зачетная гонка"/"гонка, не входящая в зачет ЧМ Ф-1".
И т.д. в зависимости от конечных целей потребителя это базы.

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

И самое сложное именно в том, чтобы учесть все ньюансы и все данные, и так называемые сложные случаи: вроде тех, когда гонщики менялись машинами.
Иными словами сделать такую структуру - схему базы данных, которая грамотно охватит всё. 
Вот эту схему проверить на корректность могут только специалисты по проектированию БД,

Причем, чем раньше и чем больше им будет предложено сложных случаев, тем лучше.
Сайты типа Forix, Woldsoft и им подобные берут выборки именно из подобных таблиц. 
Сам не специалист. Но в целом примерно так.

[Владимир]

Пока сочинял Юрий привел конкретный пример с примерами интерфейса.
"Вывод на экран" можно реализовать по-разному.
Но основное - изначально корректно заложенная схема таблиц БД.

[Владимир Коваленко]

Я бы предложил немного другую структуру.
1-й вариант - Справочник Автомобиль (комбинация Марка + Модель + Шасси + Двигатель).
При этом в справочнике Автомобиль можно указать только Марку, например Maserati.

Затем когда станет известна модель и Двигатель - можно дополнить.
При этом в справочниках может соблюдаться иерархия. Т.е. Модель подчинена конкретной Марке, а Двигатель и Шасси либо конкретной Модели, либо конкретной Марке (например, дял случаев, когда конкретный номер двигателя устанавливался на несколько разных Моделей).

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


2-й вариант - указывать Марку, Модель, Шасси и Двигатель непосредственно в данных о соревновании. Т.е. вместо колонки "Автомобиль" будет четыре колонки: Марка, Модель, Шасси, Двигатель. Иерархия при этом также может остаться.

Я сам не специалист, но грамотные люди мне объяснили, что делать большую таблицу как в "Экселе" с многократно повторяющимися значениями - неправильно. Суть оптимизации и заключается в том, чтобы в базе данных были только индексы, а соответствующие им данные брались из справочников. Это называется реляционная база данных. Я этому верю и другие варианты не рассматриваю.

[Владимир Коваленко]

И самое сложное именно в том, чтобы учесть все ньюансы и все данные, и так называемые сложные случаи: вроде тех, когда гонщики менялись машинами.

В этом проблемы нет, это я предусмотрел. Поскольку я буду создавать базу данных, не заточенную под зачётные гонки чемпионата мира, а рассчитанную на самый широкий круг соревнований, то и структура её должна быть соответствующей. Для каждого соревнования будет список участников. Не заявочный, а именно участников, то есть комбинаций гонщик + автомобиль. Надо учитывать и варианты, когда гонщик садился в чужой автомобиль и делал пару кругов по трассе, как, например, Мосс на "Скарабе" в Монако. Это было неофициально, но есть фотографии. Этот факт надо зафиксировать в БД, а уж выводить или нет и где выводить - это вопрос другой.

[Юрий Карасёв]

Я бы предложил немного другую структуру.
1-й вариант - Справочник Автомобиль (комбинация Марка + Модель + Шасси + Двигатель).
При этом в справочнике Автомобиль можно указать только Марку, например Maserati.

Затем когда станет известна модель и Двигатель - можно дополнить.
При этом в справочниках может соблюдаться иерархия. Т.е. Модель подчинена конкретной Марке, а Двигатель и Шасси либо конкретной Модели, либо конкретной Марке (например, дял случаев, когда конкретный номер двигателя устанавливался на несколько разных Моделей).

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


2-й вариант - указывать Марку, Модель, Шасси и Двигатель непосредственно в данных о соревновании. Т.е. вместо колонки "Автомобиль" будет четыре колонки: Марка, Модель, Шасси, Двигатель. Иерархия при этом также может остаться.

Я сам не специалист, но грамотные люди мне объяснили, что делать большую таблицу как в "Экселе" с многократно повторяющимися значениями - неправильно. Суть оптимизации и заключается в том, чтобы в базе данных были только индексы, а соответствующие им данные брались из справочников. Это называется реляционная база данных. Я этому верю и другие варианты не рассматриваю.

В этом случае получается первый вариант.
Хотя по сути оба варианта являются реляционными базами данных.

[Владимир]

И самое сложное именно в том, чтобы учесть все ньюансы и все данные, и так называемые сложные случаи: вроде тех, когда гонщики менялись машинами.

1. В этом проблемы нет, это я предусмотрел.
2. Для каждого соревнования будет список участников. Не заявочный, а именно участников, то есть комбинаций гонщик + автомобиль. Надо учитывать и варианты, когда гонщик садился в чужой автомобиль и делал пару кругов по трассе, как, например, Мосс на "Скарабе" в Монако. Это было неофициально, но есть фотографии. Этот факт надо зафиксировать в БД, а уж выводить или нет и где выводить - это вопрос другой.

1. Хорошо, если так... . 
2. "Комбинации" - это уже итоговый вариант вывода на экран.
Но изначально должны быть маленькие таблички и некая общая их структура.

Про индексы сказали правильно - предназначены для более быстрой обработки запросов, для чего и предназначены в основном БД.

[Владимир Коваленко]

2. "Комбинации" - это уже итоговый вариант вывода на экран.
Но изначально должны быть маленькие таблички и некая общая их структура.

Всё правильно, много маленьких табличек и связи между ними. Под комбинацией в данном случае подразумевается условная уникальная совокупность. Допустим, комбинация Мосса и "Лотоса" Роба Уокера будет иметь индекс 4457, а Мосса и "Скараба" - 4469. Они спрятаны внутри базы данных, мы их не видим, а видим текстовую информацию, которая привязана к этим индексам, но каждая такая комбинация должна иметь свой индекс.

[Влад Шайхнуров]

Я очень много и долго занимался базами данных в своей жизни. Последнее, что сделал - БД для работы, поскольку существующая среда не удовлетворяла по своему функционалу, а неповоротливость IT и сложность в адаптации того "мастодонта", что сотворили из Microsoft Navision, привели к тому, что мне отказали в моих просьбах. Пришлось делать самому. В Access. БД в меру сложная , таблиц на 10. Запросов намного больше - штук сорок.
Ну это так, преамбула. Суть в том, что это - уже пятая или шестая версия БД. Все предыдущие были одна сложнее другой. В конце концов пошел по пути упрощения. Отказался от большинства макросов, сократил число запросов, убрал ненужную информацию. База стала надежнее работать и просто радует своей структурой. Но это - итог трехлетнего совершенствования.
Вот и с базой по гонкам следует двести раз подумать. Тщательно отсеять информацию, которую следует заносить в строки/столбцы таблиц. Сократить до минимума количество таблиц, а значит и индексов. Есть много информации, которую можно внести в поле MEMO, т.е. "дополнительная текстовая информация". Например номер двигателя или имя владельца. Поскольку в одной гонке мог стоять двигатель 046-1, через пару гонок - 046-2. До мая 19... г. автомобилем владел Джон Смит, с ноября - Джон Пит. Можно для всего этого завести отдельные таблицы, но проблемы  с индексацией будут. Следует исходить и из того, что номера двигателей - еще менее доступная информация, чем номера шасси.
Сложнее решить, как суммировать все виды тренировочных и соревновательных заездов. Ведь у нас были:
- два полуфинала + финал;
- два полуфинала + агрегатированный по их сумме результат;
- предквалификация;
- пятничная тренировка;
- субботняя тренировка;
- иногда две пятничные тренировки и одна субботняя;
- были тренировки и в день перед гонкой;
- собственно гонка;
- спринт;
- гонка с обратным расположением на решетке;
Как вот это все структурировать? Какими должны быть формы для "универсальной гонки"? Как узнать, какие таблицы (виды тренировок и гонки) заполнять для Большого приза Бельгии 1984 года и какие для Большого приза Макао 1985 года в Ф3? А какие для "Милле Милья" 1927 года, коль скоро БД планируется быть универсальной по всему автоспорту?