Делаю в Access, получаю три таблицы: Люди, Связи, ТипыСвязи.
В Люди два поля - face_id (счётчик, ключевое поле) и face_name,
В Связи - четыре - Код (счётчик, ключевое поле), Лицо1 (числовое, длинное целое), Лицо2 (числовое, длинное целое), ТипСвязи (числовое, длинное целое
В ТипыСвязи - КодСвязи (счётчик, ключевое поле) и Связь (короткий текст)

Надеюсь, схема связей прикрепится нормально, и не придётся ничего объяснять. Код SQL-запроса дублирует схему связей между таблицами.

SELECT Связи.Код, ТипыСвязи.Связь, Люди.face_name, Люди_1.face_name
FROM ТипыСвязи INNER JOIN (Люди INNER JOIN (Люди AS Люди_1 INNER JOIN Связи ON Люди_1.face_id = Связи.Лицо2) ON Люди.face_id = Связи.Лицо1) ON ТипыСвязи.КодСвязи = Связи.ТипСвязи;

Обращаю внимание, что таблица Люди на схеме и в запросе присутствует в двух экземплярах - отдельно для поля Лицо1 и отдельно для поля Лицо2 таблицы Связи.
Собственно, таблица Связи отвечает за отношение многие-ко-многим людей, а ТипыСвязи - для нормализации данных.

Да я и не спорю. Привычка просто нормализовать то, что можно нормализовать.

Ну и своим студентам за её отсутствие снял бы балл, если бы задание давал на разработку такой БД. Ну или, наоборот, добавил бы - смотря насколько в предмет углубиться успели.

Групповая связь - это уже добавлять сущности групп придётся, хм? И взаимоотношения групп между собой заодно.
А связь без иерархии - по идее, эта проблема решается в запросе поиска добавлением условия OR, нет?

vmag,

тогда уж не избыточна, а недостаточна. :-) Ну а периоды и прочее - это уже добавлять по вкусу, необходимости, ТЗ и т.п.