Lionel,

Как только возникает упоминание связей в контексте нормализации,
речь автоматически идет о нормальных формах выше третьей.
Ни 3НФ ни БКНФ (обычно) недостаточно для разборки с нормализацией связей.
Два родителя - это слишком, почти запредельно сложно, давайте сначала попробуем сначала разобраться с одним.

Вот ваша исходное отношение, в котором пока оставлен только один родитель.
Animal
PK id_animal
FK id_father
...
name

начнем добавлять в него строки, способом, не противоречащим определению отношения (таблицы)
1'Папа Бизон'21'Первый сын'31'Второй сын'

В смысле 3НФ здесь все в порядке, а что с унарными связями?
Каждый сын здесь видит своего единственного родителя, то есть на стороне родителя стоит 1.
Но у родителя здесь оказывается два ребенка, т.е. на стороне ребенка стоит N, а унарность предполагает единственность
с обеих сторон отношения.

Технически в sql-таблице это можно было бы поддержать определением уникального индекса на id_father.
Но в реляционной теории нет понятия об индексах, есть только отношения и их ключи, такие или сякие.
Здесь у одной таблицы получается два ключа, значит в одну таблицу оказались замешаны два отношения.
Вот и разделим их на два явным образом.

В исходном останется:

Animal
PK id_animal
...
name

и появится новое, допустим такое:
Parent1
PK id_father, FK Animal(id_animal)
id_animal, FK Animal(id_animal)

Такое разделение позволяет автоматически поддерживать связь 1:1 между родителем и потомком

Ладно, а что со вторым родителем, как его появление взрывает мозг и ломает базу?
ммм... it depends...

В отсутствие дополнительной информации, естественным образом появляется,
или может появиться вторая таблица-отношение:

Parent2
PK id_mother FK Animal(id_animal)
id_child FK Animal(id_animal)

И для каких-то ситуаций это может и сгодиться.
Однако...
Однако, в каких-то других ситуациях предметная область может оказаться описанной
с учетом, например, следующего дополнительных бизнес требования:
- animal, однажды появившийся в Parent1, не может существовать Parent2 и наоборот.

Возникновение такого требования к связям означает, что Parent1 и Parent2 дальше не могут быть независимыми друг от друга отношениями.
У animal появляется роль, определяющая кем (в каком отношении) он должен оказаться - parent1 или parent2.
Тогда два отношения Parent1 и Parent2 должны быть слиты в одно - parent и роль становится его атрибутом:
Parent
PK id_parent FK Animal(id_animal)
role
id_child FK Animal(id_animal)

Так составленное отношение позволит поддержать связи вида 1:1 для родителей обоих типов,
с усилением бизнес-требований до единственности роли родителя.

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

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

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

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