Какие типы связей могут быть в системе объектов, как называется соотв. раздел математики или может не математики? В теории множеств есть например бинарная связь. Или в графах, могут быть связи с не просто "весами", а с разными свойствами?

ПОПРОБУЮ ПРИВЕСТИ НЕЙТРАЛЬНЫЙ ПРИМЕР, В ЧЕМ ВОПРОС
Пусть есть два типа объектов, например "учитель в школе" и "факультатив в школе", пусть между ними есть отношение "принадлежность(?) - не совсем то, но назовем так" many to many: учитель преподает несколько факультативов, а факультатив могут вести разные учителя, подменяя друг друга. Почему беру факультатив, а не класс - чтобы была вещь изменчивая: то есть регулярно создаются новые, завершаются старые факультативы.

На эту связь нужно "навесить" еще расписание: конкретный учитель преподает конкретный факультатив по таким то дням и часам. "Расписание" само по себе - не уверен: логически это отдельное отношение, или "это свойство" отношения "принадлежность"?

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

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

И пусть логика вычисления "расписания" тоже меняется, оно может быть по умолчанию (напр хранится в таблице факультативов), а может быть явно указанным.

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

Тогда, как я понимаю, надо разделить логические отношения "принадлежность" и "расписание" по двум разным таблицам.
На основании одной таблицы вычисляется "принадлежность" по какой-то логике (флага инвертации нет - берем все записи из THAT_RELATION_TABLE, есть - берем всех учителей кроме записей из THAT_RELATION_TABLE),
А на основании другой таблицы вычисляется расписание: если запись есть, берется оно, если нет, берется по умолчанию из таблицы факультативов.

ВОПРОСЫ В СЛЕДУЮЩЕМ:
Это верная цепь рассуждений, или ошибочная.
Является ли "расписание" отношением, или я использую неверную терминологию.
Как формально языком математики описать необходимость разделения отношений на два, или их изначально и было два, но по началу они были тождественны, и укладывались в одну таблицу THAT_RELATION_TABLE, а с добавлением бизнес логики стали не тождественны.
Что тут чему тождественно, что нет.
Что будет если добавить третье отношение типа конкретный учитель на конкретном факультативе использует какой-нибудь объект Z (типа костюм, который зависит от лунной фазы, которое определяется по расписанию), и мы хотим вести и список Z и отношения с ним тоже.

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

И еще, боле философский, вопрос, какие еще виды отношений бывают в природе в принципе, и сводятся ли все они в случае бинарных отношений к бинарному отношению из теории множеств, зачем тогда встречается например "принадлежность" (не в том смысле, что выше написал, а в смысле 1 to many), где об этом можно почитать.