Здравствуйте, Qulac, Вы писали:


Q>Собственно это и есть наследование поведения — и факультет и группа могут содержать в себе студентов, т.е. у них есть общность.

Ну в общем-то да. В императивном языке явно напрашивается interface StudentHolder и Group и Faculty extends его.

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

Хотя...

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



PD>>А вот это решение вообще снимает все проблемы легко и изящно

PD>>https://rsdn.org/forum/db/8843919.1

Автор: m2user
Дата: 30.10 15:51

Q>Мое дело было предложить вариант решения. Вообще как известно используя реляционную модель можно смоделировать любую структуру данных в нормальной форме. Как это сделать в этом случае?

Не знаю, я не большой специалист в теории БД и тем более в реляционной алгебре. Может, другие скажут ?