VashaMashaБредятина Матч {Дата, Стадион}
Название стадиона для моей задачи не несёт никакой информации. Зато каждый матч имеет "хозяев" поля - это предусматривается регламентом: даётся выбор формы, подготовка поля(каждая команда предпочитает свой тип поля "мокрое" "сухое" и тд(не зря я месяц в футболе разбиралась)
))) Вы, похоже, искренне все это пишете. И никак не можете понять, что Вы в проектировании БД не разбираетесь, а не в футболе. Какие зрители?? Какое поле?? Вы хотя бы свои сообщение читайте про "идентификацию матча с помощью команды хозяев"... Разумеется, матч имеет и "хозяев", и "гостей". А вовсе не только "хозяев")) И голы забивают и те, и другие, а не только "хозяева"))
VashaMashaДля моих задач - стадион не является определяющей сущностью. Голы не зависят от того сколько зрителей может там сидеть или стоять, и чьё имя он носит. Размер ворот тоже одинаков. Для меня даже не важно кто в них стоит. Кому это надо - пусть добавляет.
Вы зачем это написали?) Где вы видите такую сущность?) Это Вы в такой форме обижаетесь на свое непонимание БД?))
VashaMashaВ данном случае - вы ошибаетесь. Название стадиона - значения не имеет. К тому же на стадионе может быть несколько полей и матч может проходить не на стадионе! а в спортивном комплексе и тд. Там много полей при одном названии.
))Умница. Значит место проведения матча (а вовсе не название стадиона, которое, разумеется, уникально для Вашей задачи) Вас не интересует. А если его убрать, то, как Вам кажется, не будет "уникальной идентификации", и поэтому Вы придумали такое экзотическое решение - поместить в свойства матча одну из команд. А если бы это был забег на 100 метров, вы бы, наверное поместили в него участника, который бежит по первой дорожке?)) Маша, вы банально обижаетесь на свое непонимание БД, смысла в этом нет никакого. Я Вам и говорю - оставьте свой вариант)) Раз Вы такая принципиальная идеалистка, и считаете, что футбол существует только в Вашем сознании. Создатели теории БД были материалистами, они считали, что футбол существует и вне нашего сознания, другими словами, сущности существуют не зависимо от значений их свойств. И для это в БД применяются идентификаторы, о которых даже не нужно думать при проектировании. Так что не может быть у Матча таких свойств как КодМатча, и, тем более, КодКоманды...
VashaMashaИзбыточная информация. Не согласна. Оставляю свой вариант
Разумеется!) Именно это я Вам и посоветовал. Я Вас поддерживаю в Вашем упорстве и трудолюбии. И желаю скорейшей и успешной защиты этого этого проекта!)

VashaMashaБредятинаЕсли детализировать, то и Голы могут оказаться вычисляемым свойством... То же самое что и первом вашем случае. Мы это уже обсудили. Сущность События не важна.
Это, к сожалению, неправда. Обсудить с Вами ничего не возможно, потому что Вы не готовы к обсуждению. И случай (первый) исключительно Ваш, а не мой. Вы не понимаете принципы идентификации сущностей в БД. Где Вы видите сущность События???) А "голы" Вы спроектировали не правильно. И сами это чувствуете. Вам обидно, и поэтому решили переключить внимание с сути на примечания)))
VashaMashaМне важен результат матча, а не состав игроков, арбитров, представителей федераций и на каком месте они сидели и какой фирмы у них микрофон с наушниками.
Вы для чего это написали? Просто исправьте ошибки именно с "матчем" и "результатом матча" и все.
VashaMashaТак же по вашему нужно указать какой ногой игрок забил гол, или какой фирмы у него бутсы и сколько он за это получает от производителя. Всё это избыточная информация.
Опять неправда)) А зачем, если не секрет?))
VashaMashaЕсть задание(не точное правда). Турниры - их календарь и таблицы(В,Н,П,Гз,Гп,+/-,Оч,Место- без уточнения при одинаковом количестве очков, хоть за это спасибо) Хотя с распределением по местам при равенстве очков тоже интересно наверное было бы
Вот это чудесно! Убрать эмоции, и Вы уже близки к формулировке задачи, и требованиям функционального заказчика)))

VashaMashaБредятинаА если бы это был забег на 100 метров, вы бы, наверное поместили в него участника, который бежит по первой дорожкеПоместила бы, если бегут один раз и в одно время. Вы бы как я понимаю, поместили бы номер дорожки?!...Вы (вероятно, нарочно) неправильно понимаете. Место проведения соревнования - это не номер дорожки. Это слишком очевидно, поэтому - вероятно, нарочно))... А может быть и вполне искренне не понимаете принципы идентификации.
VashaMashaПочему, например, недостаточно команды "хозяев"? Ведь достаточно для идентификации какого то метода(способа) решения какой то задачи фамилии его автора?)) Потому что команда не является свойством места проведения. И свойством самого Матча (и у Вас там вовсе не Команда). Все участники и их результаты равнозначны. Выделять одного участника для идентификации соревнования - это нелепое решение. Вы это, конечно, уже понимаете. А я, со своей стороны, поддерживаю Вашу настойчивость - лишь бы Вы по-быстрее защитили Ваш, не имеющий никакого смысла результат, и занялись бы тем, что Вам действительно нравится)).. Вопроса "как же так - голы у частника, ведь участник участвует во многих матчах, а мне-то нужны голы именно этого матча" от Вас не дождешься))) А я ведь внял Вашим призывам к образовательному статусу темы)))
VashaMashaВот вы здесь спорили смеялись над другими, а источники идентифицировали по автору монографии!
А, вот подключились к образовательному статусу темы, как бы) Но, вести себя нужно прилично при этом. Источники идентифицируются идентификатором)) Причем, автоматически)) Вы никак не можете понять разницу между идентификаторами и уникальными свойствами. А так же не можете понять, что никакие Ваши усилия не приведут к исключению дубликатов (нескольких информационных объектов, соответствующих одному физическому). Почитайте, в связи с этим, соседнюю тему про идентификацию человека))... И прекратите глупости писать - это же отвлекает от нашей с Вами задачи - образования в области теории и проектирования БД.
VashaMashaВы не говорили о БД, а о том как кто понимает, хотя сути это не меняло. Модель Реляционная существует вне зависимости от того как вы её понимаете.
Опять (умышленно) говорите неправду)) Это Вы говорите - как Вы что-то понимаете, причем не в БД, а в предметной области. Я Ваше внимание все время обращаю именно на теорию БД, которую Вы не знаете). И, очень важно - если Вы говорите не о теории БД, а о "модели реляционной", то, пожалуйста, подтвердите это явно. Раздел форума называется "Проектирование баз данных". Если Вас не интересует проектирование баз данных, а интересует именно проектирование реляционных баз данных, то я еще раз подчеркну, что Вы все делаете правильно! Все "делают как понимают")) А потом решают перманентно бесконечные проблемы "реляционной технологии". Давайте, определяйтесь))
VashaMashaИ если достаточно одной команды что бы сказать, что в этом матче между тем то и тем то был зафиксирован такой счёт, и второго матча с участием этой команды в это время не происходило и не могло произойти - то этого вполне достаточно. Конечно, конечно)) И "на его месте должен был оказаться я" не забудьте, пожалуйста. То есть, и другая команда могла играть такую роль) Но, это же РМД - она все стерпит. Множество "правильных" решений. Бессмысленной задачи)
VashaMashaМожет теоретически это и не правильно. Допускаю, и даже соглашусь, но в данном условии достаточно. Или вы думаете нет стадионов с одним названием? Городов? И первых дорожек думаете мало? А вот человек стоящий на этой дорожке один! Сделаю табличку с ДНК спортсменов и спокойно можно использовать как ключ.
Грандиозно!) Ключ соревнования - ДНК одного из участников)... Напомню, что в БД, в отличие от "реляционной технологии", нет никаких ключей, и, соответственно, никаких, связанных с ними проблем.
VashaMashaТак можно предполагать до бесконечности. Кстати я читала, что и реляционные БД - отнюдь не совершенны, а в некоторых случаях создают больше проблем чем решают. "каждая ложка хороша к обеду..." - думаю в моём случае - это допустимо.
В Вашем случае все допустимо, еще раз повторю)
VashaMashaВы любите самолёты. Вот пример. Зачем спорить о реактивном двигателе на планере? Он и так полетит.
???))) Я не люблю самолеты, а говорю, что самолеты не проектируют, не зная необходимых теорий, или зная только одну из них (потому что неизбежно окажется, что и ее не знают).
VashaMashaИ если есть чёткое описание команды - этого вполне хватит. Второй такой команды не будет. В моём случае команда чётко определена и в сочетании со временем - она чётка определит матч.
Неправда. У Вас вовсе не Команда. И почему Ваше решение с одним из участников (а вовсе не Командой или Человеком в случае соревнования по бегу) не корректно я Вам объяснил.
VashaMashaА то что нужна ещё одна таблица с голами команд - я знаю. Но здесь решили что такого представления будет достаточно - я с ними согласилась. А на словах я смогу сказать почему. Приведу ваш пример с дорожкой номер №1. И скажу что этого не достаточно
Заблуждение и очередная неправда. У меня не было примера с дорожкой номер один. Вы хотите хранить результаты забега в самом забеге, сделав в нем, в частности, восемь "внешних ключей" (один из которых входит в "первичный) и восемь результатов соответствующих участников. Вот это очевидно и всем понятно)) А вот Вы не понимаете что я Вам объясняю. Искренне или умышленно - это не так важно))

VashaMashaБредятина,

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

VashaMashaОтветьте кто нибудь на такой вопрос:
Если бы каждый турнир имел чёткую структуру(она бы никогда не изменилась), все баллы очки считались бы одинаково и тд, то есть одинаковый регламент ВСЕГДА, но разный между собой, имело бы смысл создать на каждый турнир свою БД? А уже в какой то отдельной БД объединить всё эти данные?

Я хочу сказать, что уже в этой отдельной базе данных обрабатывать результаты?

Например.
Есть филиалы некого концерна(FIFA)/ Каждый филиал(Серия А, MLS,...) имеет свою БД. А потом FIFA просто присоединяет нужные таблицы и уже у себя обрабатывает их.
Все ровно наоборот. Как всегда)) Если бы "одна и та же структура", то не было бы смысла "создавать на каждый турнир свою БД"))

VashaMashavadiminfo,

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

VashaMashaБредятина,
А что такое МД - модель данных?
Да((
VashaMashaБредятинав реляционной БД среди свойств Матча должно быть все три "идентификатора" - самого матча и двух его участников то есть первая таблица по матчу лучше?
Я Вам детально написал по поводу матча, и спросил: Вы проектируете базу данных (так этот форум называется) или реляционную базу данных? Вы это проигнорировали, как и 90% того, что я Вам написал, и зачем-то в проект реляционной БД поместили отношение не просто плохое, а просто невозможное)) А теперь "наивно" спрашиваете: значит то было лучше. Я Вам написал про "забитые" и "пропущенные", про результат матча, про особенности идентификации сущностей... И могу и дальше все объяснять подробно и столько, сколько нужно. В отличие от всех остальных, которым Вы и Ваши знания безразличны))

VashaMasha... то есть первая таблица по матчу лучше?
Поскольку Вам не интересно разбираться с разницей между участником турнира и участником соревнования внутри турнира, как поступать со связями 1:1 и т.п., просто поправьте формулировки на русском языке:
...
КодКомандаХозяев
КодКомандаГостей
ЗабитоГоловХозяевами
ЗабитоГоловГостями
...

VashaMashaБредятина, Это всего лишь названия от фонаря, даже не из форм.
1) один шаг до "все до фонаря"));
2) в БД это было бы название свойства в интерфейсе, и об этом не стоит забывать, если Вы хотите в БД разобраться (несмотря на то, что в "реляционных системах" - это внутренний идентификатор свойства, для программиста).
VashaMashaКакая разница как их назвать? понятно что мячи забитые одной и другой командой. Вы ведь поняли?
))) Был у меня студент, который делал по несколько ошибок в одном слове (но, очень хороший программист!), и тоже говорил: "Ну, вы же понимаете что написано." Мы сейчас не программируем (потому что приложения БД вообще не следует программировать), и я Вам точно говорю - "в формах" у Вас будет ровно то же самое, и Вам будет стыдно)))
VashaMashaи я понимаю что там будет стоять. Вы вот меня учите учите, как вы говорите, вы бы ещё по китайски писали - смысл был бы один и тот же.
Вы не правы. Вы не для себя создаете БД, и не для меня.
VashaMashaи в чём же разница между участником соревнования и участником турнира?
Это две разные сущности. Человек может быть участником олимпийских игр, с одной стороны, и участником соревнований по прыжкам в длину и по бегу на 100 м на этих олимпийских играх - с другой. В нашем случае, связь между Матчем и Участником матча (но не Участником турнира) 1:1)) И нужно подумать стоит ли сливать два эти типа сущности в один (что, теоретически, возможно при стабильной связи 1:1). То есть, хранить результат участника соревнования непосредственно в соревновании...