Откуда вы знаете, какое отношение использовать?

Question

Я понимаю, что между сущностью, скажем, Клиентом и Орденом, может существовать связь, но я не понимаю, к какой таблице принадлежит 1, m или n, когда я создаю свой собственный ERD ... Есть ли какие-либо правила, чтобы понять, какую связь я должен использовать, и в каком порядке я должен поместить символы (так же это 1: n или n: 1) ?.

На следующем изображении я знаю, что каждый заказ имеет 1 клиент, так как order_id является первичным ключом таблицы заказов. Это причина, почему существует связь 1: n, а не n: 1? Или это потому, что один и тот же клиент может разместить заказ несколько раз, поэтому клиент будет сохранен в таблице заказов несколько раз?

Другой пример:

Тот же вопрос здесь. Почему существует связь 1: n между t_course и t_course_taken? и почему это соотношение 1: n между t_student en t_course_taken?

Answer 1

Уже есть принятый ответ на этот вопрос, но я хотел обратить внимание на один аспект этого вопроса на благо будущих посетителей. Это разница между анализом предмета и проектированием базы данных.

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

Как только реальный мир (в некоторой степени) понятен, он готов начать разработку базы данных. Дизайн базы данных представляет собой процесс изобретения, но изобретение лучше ориентироваться на результатах ранее сделанного открытия.

Начальный проект базы данных включает в себя таблицы, ключи и внешние ключи. Здесь нормализация вступает в игру, и я рекомендую вторую рекомендацию jbutler изучить ее. Отметим также, что анализ выявил два объекта с отношением «многие-ко-многим» между ними, в то время как проект приводит к трем таблицам с несколькими отношениями «один-ко-многим» между внешними двумя (сущностными) таблицами и средой (отношения) Таблица. Это то, как отношения «многие ко многим» моделируются в реляционной модели.

Это различие между анализом и дизайном часто упускается из виду людьми, которые просто подходят к работе на базе данных. Здесь можно ошибиться. Более акцент на анализе может привести к «анализу паралича». Под акцентом может быть «готов, огонь, цель».

Answer 2

Moving это к ответу:

Последний комментарий Ответ: В общем, да.

Однако в первом примере это не имеет смысла. У одного клиента может быть много заказов, но один заказ не может принадлежать многим клиентам.

В вашем втором примере

Один студент может записаться на многих курсах, и один курс может иметь много студентов. (Отсюда много-много отношений). Чтобы бороться с этим, мы включаем таблицу детей . Назовите это studentsCourse для простоты.

Студент может иметь много курсов для студентов, но теперь курс для студентов будет специфичным для них.

Курс может иметь много studentCourses, но опять же, single studentCourse будет принадлежать одному курсу.

---

Теперь какой-либо смысл?

---

BTW, я думаю, вы могли бы использовать для чтения на базы данных Нормализация (http://holowczak.com/database-normalization/), который, мы надеемся объяснить лучше, как ломаются таблицы (ваш учебник может даже содержать раздел или два на subject!)