Проектирование, думая о материализации отношений ER в SQL - PullRequest
0 голосов
/ 03 октября 2018

Вот мой вопрос.

После опыта работы с ООП и UML моделирование ER кажется немного облачным ...

Одно из самых больших препятствий, с которыми я сталкиваюсь при разработке моделей ER, заключается в том, что японятия не имею, как будет выглядеть материализация:

Позвольте мне привести пример:

Если я нарисую сущность "Студенты", я думаю, у меня будет таблица на SQL с именем "Студенты"с атрибутами студентов.

Но если я подключу сущность "Студенты" к сущности "Курсы" через отношение "Зачислено", каким будет аспект в SQL?

Я угадываютаблица для каждой сущности, но как я могу выразить отношение?Нужно ли мне для некоторых отношений создавать таблицу так же, как мне нужно делать для сущностей?Или это отношение присутствует в обеих таблицах «Студенты» и «Курсы» в зависимости от атрибутов, которые я выбираю для каждого из них?

Это выглядит нечетко, по сравнению с UML.(Я знаю, что это может показаться плохой практикой, беспокоиться о деталях реализации, но я хотел бы иметь более четкое представление, особенно о том, какие отношения получатся в SQL)

спасибо.

1 Ответ

0 голосов
/ 03 октября 2018

Отношения «многие ко многим» также хранятся в виде таблиц.Enrolled будет таблица со столбцами, такие как:

  • StudentId
  • ClassId

Вероятно, будет другая информация, такая как датарегистрация, метод, возможно информация об оплате.

Сравнение с объектным моделированием сложно.ER моделирование обычно начинается с основных объектов.Часто отношения превращаются в сущность, потому что доступна другая информация, помимо связи между сущностями.

...