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

В холодильниках кстати всё намного проще И он тоже предназначен для хранения. Шутка, а то я смотрю с юмором напряг

Бредятина,

Хорошо. Никого не спрашивала. Вас спрошу: как вы организуете хранение информации о матче? Ничего кроме данных для составления подробного календаря, и турнирных таблиц.

Или же подождите немного я выложу свой вариант и вы выложите свой.

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

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

БредятинаЗадайте себе вопрос: правильно ли я понимаю: один построит самолет, а другой будет делать его удобным для пассажиров и обслуживающих организаций?))
Вы не поверите, но как раз этим я и буду заниматься. Только немного уровнем ниже. И абсолютно никогда гоночная машина не будет комфортной! Не думаю что БД будут чем то отличаться. Золотое правило механики никто не отменял. Чем то придёться жертвовать. Так что тут мог возникнуть спор, но он не к чему не приведёт.

vadiminfo,

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

Совсем со светом напряг. Не дают учиться

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

VashaMasha,

Плохо что то видно. А если так?

VashaMasha,

так получше вроде

Ну что ж. буду начинать с нуля.

Итак, для однозначного определения сущности матча использую дату матча и команду Хозяев поля(составной индекс - повторений не допускается). Делаю это исходя из того что одна команда в одно и то же время не может играть два матча. Если. где то в каком то турнире это и возможно - я считаю что для таких турниров пусть составляют другую БД.

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

Определяю, Голы забитые командой "хозяев", голы пропущенные командой "хозяев", и команду соперника.

Итак получаем таблицу МАТЧ :
КодМАТЧА - поле типа счётчик
ДАТАматча (тип ДАТА/время длинный формат даты) и кодКомандыХОЗЯЕВ(длинное целое) - составной неповторяющийся индекс. КомандаХОЗЯЕВ - поле связи с таблицей РегистрацияКоманд
КодЧастиТурнира - длинное целое, поле связи с таблицей ЧастьТурнира для определения принадлежности к какой то самостоятельной части турнира
ГолыЗАБИТЫЕ (байт)
ГолыПРОПУЩЕННЫЕ (байт)
кодКомандыСОПЕРНИКА - длинное целое, поле связи с таблицей РегистрацияКоманд
СТАТУСматча - поле типа логического - сыгран, на сыгран, считать его или не считать, или же организовать его кому как нужно - создать отдельную таблицу со статусами, и через это поле установить связь(например матч не начался; или матч играют, или матч состоялся и имеет результат и тд - кому что надо) Мне достаточно двух значений СЧИТАТЬ его или НЕ СЧИТАТЬ.
КРУГчастиТУРНИРА - поле для календаря - определяет принадлежность к кругу в какой то части турнира(если есть необходимость - необязательное поле)
ТУРчастиТУРНИРА поле для календаря - определяет принадлежность к туру в какой то части турнира(если есть необходимость - необязательное поле)




Итак,таблица ЧастьТУРНИРА
КодЧастиТУРНИРА - поле типа счётчик
НАЗВАНИЕчасти - текстовое поле(50) -, просто название
кодТУРНИРА - длинное целое, определяет принадлежность составляющей к определённому турниру.
кодСистемаРОЗЫГРЫША - это будет поле сввязи, с таблицей в которой присутствуют правила(отдельный регламент) важные для определения расположение команд на конец этой части турнира: то ли правила начисления очков, то ли правила отсеивания или разделения команд на разные группы по окончании этой части турнира
ИндексВЧастиТУРНИРА - байт, поле которое определяет последовательность составляющих в турнире
Например ЛЧ поделена организаторами на КВАЛИФИКАЦИЮ, отбор перед групповым турниром, и потом уже стадии 1/8, 1/4 и тд до финала, который проходит в один матч, в отличии от предыдущих частей турнира

Пока думаю достаточно, потом добавим если надо будет.

КодСОСТАВЛЯЮЩЕЙ вводим в таблицу МАТЧ. Это будет поле связи между двумя сущностями МАТЧ и СОСТАВЛЯЮЩАЯ. Поле КодТУРНИРА поле связи с таблицей ТУРНИР.

КодТУРНИРА - поле типа счётчик
НАЗВАНИЕтурнира - текстовое поле(50)
РЕГЛАМЕНТ - каждый может организовать по своему как поле для хранения файла, как поле для хранение большого текста, как гиперссылка на страницу интернета с регламентом.

Итак, получились у нас такие таблицы:
таблицаТУРНИР
таблица ЧастьТУРНИРА
таблица МАТЧ


таблица КОМАНДЫ
КодКОМАНДЫ - поле типа счётчик
НазваниеКОМАНДЫ текстовое поле(25), принятое сокращённое название клуба в мире. Если команда молодёжная или ещё какая, принадлежащая одному клубу рядом можно поставить U-19, например. Для сборных можно ставить сокращение сб.АНГЛИИ U-19, ветеранов тоже можно обозначить вет.ДИНАМО К и тд
НазваниеКЛУБА - текстовое поле(100) здесь уже официальное международное название(я и не знала что клубы имеют столько слов в названии.
ДАТАоснования - можно включить, число(целое). Тут каждый может создать какие угодно атрибуты для описания команд
кодСТРАНЫ - байт, поле связи для таблицы СТРАНЫ

Таблица СТРАНЫ
КодСТРАНЫ - байт, думаю достаточно будет, кому нехватит может целое поставить
НАЗВАНИЕстраны - текстовое(50)
Международн.ОБОЗНАЧЕНИЕ - текстовое(3)
ПринадлежностьКонфедерацииФИФА - организовать можно по разному, я буду через таблицу справочник, значит это будет поле связи с таблицей КОНФЕДЕРАЦИЙ.



Таблица РегистрацияКоманд
КодКомандыВЧастиРозыгрыша - поле типа счётчик
кодКоманды - длинное целое, поле связи с таблицей КОМАНДЫ
Группа - текстовое(15) заполняется если она есть в MLS например есть конференции в начале турнира, в России потом происходит разделение на группы и тд
НомерЖРЕБИЯ - везде есть жеребьёвка, например для составления календаря Например, при распределении команд по парам в плей офф ЛЧ, этим полем можно задать пару команд и тд
ПРЕЗИДЕНТклуба - решила поставить в эту таблицу. Так как возможна смена владельца клуба по ходу турнира. Мне в принципе для работы это поле не важно. Выброшу его совсем. Кому это необходимо, думайте. Но я бы поставила сюда. Вообще то есть много вариантов для Access/ Можно поставить этот атрибут в справочник команд, наряду с тренером, капитаном и создать отдельную таблицу ЗАМЕНвМЕНЕДЖМЕНТЕ,например. И в неё програмно или через Макросы данных(access2010) заполнять её. Это такое подобие триггеров в access/ Пусть они отслеживают изменения в управлении команд и при смене кого бы то ни было вносят новые записи в таблицу
СТАТУСкоманды - по окончанию этой части турнира, можно организовать по разному, мне хватит и трёх значений(можно создать справочник для определения итогов выступления команды в этой части турнира - проходит дальше, вылетает, так продолжая и установить связь через это поле.

Бредятина Матч {Дата, Стадион}
Название стадиона для моей задачи не несёт никакой информации. Зато каждый матч имеет "хозяев" поля - это предусматривается регламентом: даётся выбор формы, подготовка поля(каждая команда предпочитает свой тип поля "мокрое" "сухое" и тд(не зря я месяц в футболе разбиралась) Для моих задач - стадион не является определяющей сущностью. Голы не зависят от того сколько зрителей может там сидеть или стоять, и чьё имя он носит. Размер ворот тоже одинаков. Для меня даже не важно кто в них стоит. Кому это надо - пусть добавляет

В данном случае - вы ошибаетесь. Название стадиона - значения не имеет. К тому же на стадионе может быть несколько полей и матч может проходить не на стадионе! а в спортивном комплексе и тд. Там много полей при одном названии. Избыточная информация. Не согласна. Оставляю свой вариант

Таблица СистемаРозыгрышей не нормализована . Не обращайте на неё внимания. Я её потом переделаю. Спешила.