@Notagenie

Задание - создать БД про Формулу 1. Сущностей, которые уже созданы, вполне достаточно. Помогите, пожалуйста, разобраться с их связями, потому что никак не могу скомпоновать схему данных.

Вложения

F1.rar (23.3 Кб, 29 просмотров)

0

@bliznets

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

0

@Notagenie

В БД будет хранится информация за 14 сезонов(2000-2013).
Каждый сезон состоит из разного количества Гран-При, что утверждаются перед началом сезона. Гран-При проходит на определенной трассе. После каждого Гран-При в сущностях "Личный зачет" и "Кубок конструкторов" информация обновляется в зависимости от результатов заезда(RaceMember).
Количество команд, что берут участие в борьбе за Кубок конструктора, может быть разным в каждом сезоне. Команда может участвовать в нескольких сезонах. В команде должно быть минимум два пилота, также могут быть запасные. В одном сезоне пилот может быть только в одной команде, в следующем он может начать выступать за другую(контракт подписывается на сезон).
Как-то так. Достаточно полное описание?
Если будут какие-то идеи по поводу изменения самих сущностей, а также связей, буду очень признательна.

0

@bliznets

Пока что, опираясь на имеющуюся информацию, у меня такое видение всего. Сущность пилоты превратилась в сущность участники, потому что среди них ведь еще могут быть и конструкторы. На счет результатов - на сколько я понял, они относятся скорее к конкретным участникам, нежели команде (из описания) . Новая сущность races содержит информацию о том, какой пилот за какую команду выступал на каком грандпри и с какими результатами. Таким образом, он может выступить и за другие команды и в другом грандрпи( как и требуется в предметной области) Кстати эта сущность заменяет две сущности DriverChampionship и ConstuctorChampionship. Атрибут type в сущности races как раз и говорит о роли участника, и может быть либо со значением Racer, либо Constructor(кстати этот атрибут можно было бы даже перенести в описание самого участника, а если оставить как есть, то какой-то водила может выступить в роли конструктора на грандпри , ну или наоборот=) ). Убрал некоторые атрибуты лишние. например атрибут team_Name в сущности Participants (бывший пилот) не уместен, так как пилот может участвовать за сезоны в разных командах. Сущность RaceMember вообще мне не нравится, может быть потому, что не очень понятен. Подозреваю, большинство атрибутов из этой сущности можно перенести в Races. В общем, пока вот такое видение, предлагаю двигаться в таком направлении.. Кстати, сущность Races еще называется ассоциативной таблицей, она решает проблему множества связей "много-ко-многим".

Вложения

F_1.rar (28.9 Кб, 14 просмотров)

1

@Notagenie

Спасибо! Суть уловила. Единственное, сущности DriverChampionship и ConstuctorChampionship нужно учесть, потому что конструктор-это команда, то есть очки гонщиков идут им в личный зачет после каждого ГП, а вот в Кубок конструкторов зачисляются результаты двух гонщиков, которые выступают за команду. Грубо говоря, после гонки
Личный зачет: Алонсо 15, Масса 12 (выступают за Феррари);
Кубок: Феррари 27.

0

@bliznets

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

1

@Notagenie

А если все же создавать новую сущность для личного зачета и Кубка конструкторов, нужно DriverChampionship связать с Races, а ConstuctorChampionship в свою очередь с DriverChampionship?

0

@bliznets

1) Личный зачет рейсера собственно содержится в races.( все атрибуты бывшего DriverChampionship перешли в эту сущность т.е. points и position.Чтоб вам было понятнее - я переименовал Races в DriverChampionship. Просто в Вашем варианте DriverChampionship у рейсера может быть только один показатель очков и один показатель места. В моей же сущности там еще появился ключ GrandPrix, которые еще указывает очки рейсера для каждого GrandPrix. Т.е. если есть рейсеры "первый" и "второй", участвовавшие в ГП 1 и 2, то будут записи <первый | 1 |4 очка|5 место|> <первый | 2 |4 очка|5 место|> <второй | 1 |7 очков|6 место|> <второй | 2 |2 очка|1 место|> (синим помечены первичные ключи)
2) Дальше - немного сложнее.. Эм.. С сущностью ConstuctorChampionship я решил сделать таким образом : сделал ее тоже ассоциативной таблицей, у которой составной ключ состоит из двух частей - имя команды и гранд при. Т.е. тот же принцип, что и выше описан с рейсерами : каждая совокупность команды и ГП содержит какие-то очки и позиции.) Кстати таблицу DriverChampionship я отвязал от таблиц team и Grandprix и привязал её к сущности ConstuctorChampionship, и теперь DriverChampionship получает два своих первичных ключа получает оттуда (имя команды и ГП).Я понимаю, что может не совсем понятно объясняю)) Хотите пользуйтесь тем, что предлагаю, а хотите - нет) В общем лучше сами взгляните и посмотрите, что вам будет непонятно в новой версии)
З.Ы. Таблицы, не связанные ни с какими другими в модели - не нужны)
З.Ы.2 Зато у вас будет крутая модель! Главное - сумейте её объяснить (если вы это для преподавателя делаете) ,а то может он никогда не видел, как связывается составной ключ с другой сущностью))

Вложения

F_1.rar (30.0 Кб, 19 просмотров)

1

@bliznets

*В версии БД, что скинул выше, забыл переименовать Races в DriverChampionship..

0

@Notagenie

Изначально я что-то подобное и подразумевала
А подскажите, как перенести связи с той же сущности DriverChampionship на модель "сущность-связь"? Все связи только "один-ко-многим"? Просто насколько я знаю, связи "много-ко-многим" немного по-другому выглядят в реляционной модели.

0

@bliznets

Ну, чтоб решить задачу, мне же нужно было сначала разобраться, что вы подразумевали, а потом и придумать, как помочь ( Странно команды называть "конструктором" например). Честно говоря не понял, что вы собираетесь там переносить) Если вы имеете в виду вот такую модель :

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

0

mobile

Вы не могли бы пояснить сказанное? Например, есть сущности Сотрудники и Отделы. Сотрудники могут переходить из отдела в отдел. История, разумеется, должна записываться. Как в вашей модели будет описана структура данных?

И второе. В чем Вы видите преимущество связи "один-к-одному" перед одной таблицей, содержащей оба набора данных?

Добавлено через 2 минуты
И да, забыл. Какого рода "неопределенности" существуют в связях "многие-ко-многим" ?

0

@Notagenie

Я проектирую информационную систему, и да, мне нужно создать модель "сущность-связь", как на изображении. Просто я решила, что так будет проще - начать с конца)

0

@bliznets

Надеюсь, я не вовлекаю себя в спор (не люблю я это дело). Итак, Я не утверждаю, что я гуру в БД и проектировании, но :
По первому пункту : Тут нужны уточнения.
Ситуация первая : Если сотрудник может переходить из отдела в отдел, НО не может одновременно работать в нескольких отделах, то тут и нет связи "много-ко-многим", тут связь "один-ко-многим", так как в одном отделе может быть несколько сотрудников, а вот сотрудник может быть (вступать в связь) только с одним отделом. Всё будет сводиться к тому, что при переходе в новый отдел, у сотрудника в поле "отдел"(FK - внешний ключ, не идентифицирующий) будет меняться значение на нужный новый отдел.
Ситуация вторая : Если сотрудник может работать в нескольких отделах одновременно. Тут нужна ассоциативная таблица, которая будет состоять из двух ключевых полей - сотрудник и отдел. В теме выше я приводил пример записей даже, как это дело получается и для чего нужно. Не будь ассоциативной таблицы - как узнать, какой сотрудник в каком отделе работает? Вот вам и неопределенность.
Еще, по теме : Есть такое понятие, как нормализация базы данных. Сначала таблицы приводятся к первой нормальной форме, затем ко второй и так далее.. Таких форм 4 ,служат они для эффективной компановки данных и уменьшения логических ошибок. (кстати на самом деле их 6, просто первые 4 - основные). Так вот, связи "много-ко-многим" удаляются если не ошибаюсь уже при приведении таблиц ко 2НФ.
По второму пункту :
1) иногда это бывает просто удобно чисто логически и экономно в плане объемов хранения данных. Например, у меня есть сущность договор( на аренду авто) со своим набором атрибутов и сущность возврат с совершенно другим набором атрибутов. В бизнес- правиле указано, что по каждому договору один возврат. Чисто логически это совершенно разные сущности, вторая появляется позже, чем первая, первую я буду использовать при договоренности с клиентами, во второй например штрафы буду исчислять. Всё конечно зависит от описания предметной области, но, если при проектировании видно, что сущности разные по смысловой нагрузке, у них разный набор атрибутов - удобнее их оставлять по отдельности. А теперь представьте, что я объединю эти сущности? Получится куча пустых атрибутов - когда я буду создавать договор, все атрибуты возврата окажутся пустыми, ну и наоборот. Некрасиво и нехорошо! Поэтому делать этого не буду! Так то!
2) Еще такую связь используют, когда есть наследование. Пример.эм.. ну например Есть сущность сотрудники и вторая сущность - Активисты. Сущность сотрудники - родитель для активистов. Не все сотрудники - активисты, но все активисты - сотрудники. Ну и разный набор атрибутов у этих сущностей - для сотрудников например - др, звание, должность и тп, для активистов - заслуги, величина награждения и тп. Вот собственно тут и будет связь один-к-одному оправданной - В обеих сущностях будет один и тот же ключ. Сущность Активисты будет брать первичный ключ из сущности Сотрудники.
P.S. Я не претендую на звание гуру в этой области.. пока что Если интересуют такие вещи - литературу можно найти в интернете достаточно.

0

mobile

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

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

Хотелось бы Вас попросить показать место в теории где показывается удаление таких связей.

1

@bliznets

Перечислите, пожалуйста, мои спорные положения.
в таком случае я бы создал ассоциативную таблицу,связывающую сотрудников и отделы, назвал бы ее скажем "Движение кадров" и добавил бы еще один атрибут-ключ "дата". В итоге у меня бы появилась таблица, в которой показано какой сотрудник какого числа в какой отдел перевелся. Узнать, в каком отделе работает сейчас сотрудник тоже можно - нужно взять из записей в ассоциативной таблице запись с нужным сотрудником и самой свежей датой.

А как бы сделали Вы?
Тут я бы сделал следующим образом.

А как бы сделали Вы?

Покажите тогда, как вы это реализуете со связью "много-ко-многим"? Безумно интересно!

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

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

З.Ы. на счёт нормальных форм - каюсь, перепутал, ошибся. Действительно, при приведении таблиц ко всех этим нормальным формам не решаются никакие проблемы, связанные со связью "много-ко-многим".

0

mobile

Вот то, что Вы показали рисунке и есть связь "многие-ко-многим". Решается именно так, как у Вас показано: созданием третьей таблицы между ними, связанной по ключам с двумя другими по типу "многие-к-одному. Но если в примере на рисунке третья таблица описывает материальную сущность Children, то в связях типа Писатель-Издательство или Магазин-Товары, сущности, описываемой одним понятием может и не быть. В связи Писатель-Издательство это книги писателя X, выпущенные издательством Y. В Магазин-Товары это товары X продаваемые магазином Y.

0

@bliznets

Ассоциативной таблице не обязательно быть осмысленной сущностью. Её главное назначение - связать две таблицы, т.е. мы ею может и не пользоваться вообще напрямую. К тому же, она не занимает никакого места, потому что ключи, которые она "импортирует" из других сущностей , храняться в БД в одном экземпляре, т.е. как ключи головных сущностей. Это только при отображении в схеме для нас, пользователей, они показаны в двух местах : в головной таблице и в ассоциативной таблице, а по сути храниться она один раз.
З.Ы. то, что я показал на рисунке, это не связь "много-ко-многим", там две связи "один-ко-многим"

0

mobile

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

0

@bliznets

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

Добавлено через 5 минут
Я так и не понял что Вас не устраивает и какие решения предлагаете Вы.
Изначально вы вроде как не понимали, откуда неопределенность в связи "многие-ко-многим", только я вроде это объяснил.

0