В реляционной БД нет связей, есть таблицы и ограничения ссылочной целостности. В процессе реижиниринга схемы БД в ER модель в зависимости от наших целей, мы можем обозвать одни таблицы связями, другие сущностями.

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

Фактически связи отношений (таблиц и представлений) реляционной БД возникают только в процессе выполнения SQL запроса. Как напишем условия соединения таблиц в запросе, такая связь и получиться. Она может быть отражена в ER модели, но может и отсутствовать. Более того, она может быть совершенно бессмысленной, с точки зрения бизнес логики, как например соединение поставщика и товара по № телефона и артикулу изделия. Иногда связь может иметь атрибуты, которых нет в БД, например, нужно получить исторические сведения о сотруднике и его зарплате на определённую дату в прошлом. Без этой даты связь будет 1:*, с датой, 1:1.

Очень хорошо связи (ассоциации) развиты в UML.

Что касается множественности связи, то иметь таблицу без PK не хорошо. Но и вводить суррогатный ключь, или счётчик кратности связи тоже не всегда удобно. Если использовать счётчик кратных связей, то он может стать узким местом, когда одновременно многие процессы создают связи некоторых объектов. Без счётчика может возникнуть ситуация, когда два пользователя пытаются уменьшить число связей на 1, например из 10 связей получить 9, но каждый удаляет по одной связи и в итоге получается не 9 а 8 связей. Здесь, для принятия решения нужно проанализировать предметную область.