1. Что за надобность иметь 3 таблицы с людьми? Если это (условно) клиенты, сотрудники, поставщики, то нужно имет одну таблицу (people или person) в которой будут храниться ФИО + все что касается именно человека (дата рождения, паспортные данные, адреса и т.д.). Ваши 3 таблицы будут ссылаться на эту таблицу. Таким образом один и тот же человек не будет у вас написан по-разному в разных таблицах и вы не получите непонятных дубликатов.
2. Справочники имен и фамилий действительно делать нелогично. А вот справочник персон (как я написал выше) вполне возможно и, я бы сказал, необходимо.
3. Можно попробовать поиграться с наследованием - постгрес этим выделяется из множества СУБД. Но нужно знать предметную область - подходит ли вам наследование. Как мне кажется, п1 подходит всегда.

KattЕсть такой вариант - не спорю. Но у одной персоны нужны все псп данные, у другой -только ФИО и т.д.
Ну и что. Необязательные поля никто не отменял.

KattКроме того, выходит связь 1:1, а это не есть хорошо в рамках проектирования - не обосновано и требует "разруливания".
Где тут связь 1 к 1? У вас 3 таблицы ссылаются на одну - таблицу персон. Причем, возможны случаи когда на одну запись будут ссылаться разные таблицы (например, автор может же быть сотрудником).

Katt1:1
Это в ER нотации, когда 1 человек к одной персоне!
Ну-и-что?
Зато если у вас в одной таблице будет Иванов Сергей Петрович, а в другой Иванов Сиргей Петрович (ну опечатались) вы наплачетесь, если нужна будет выборка - сотрудники, являющиеся авторами.
Мыслите сущностями - есть человек. Вот его мы и храним в таблицах. А далее мы можем создавать категории - авторы - ссылка на человека+ то, что присуще только авторам (сами решите что). Обучающийся - легко + номер студ билета+дата поступления+факультет/специальность.

Katt pamirМыслите сущностями - есть человек. Вот его мы и храним в таблицах. А далее мы можем создавать категории
Если не ошибаюсь, то сущностями мыслить - это как раз получить авторов, сотрудников и студентов. А то, о чём говорите вы - это ОО подход - классы другими словами!
Но база то релционная! А не каше какая-н...
Как правильно указал 4321ё - авторы, сотрудники и студенты - это есть частные случаи одной сущности - персона. Создайте персону, а остальное навесьте как характеристики этой персоны.

PS. ООП подход с некоторыми оговорками можно применять и к реляционной базе. И проектировать будет легче и поддерживать удобнее.

KattХорошо. Ну а к примеру то, что ФИО студента добывается раз 100 в секунду, а ФИО сотрудника - 1 раз в день, это нормально? Ведь со структурой "персона - студент, персона - сотрудник" мы нагружаем определённое место базы!
Или "table partitioning" и забыть про то,что персона - самое "горячее" место будет?
И что? В вашем случае вы нагружаете другое определенное место базы - таблицу студентов. А если у вас в таблице перосны кроме студентов присутствует еще с сотню редко вытаскиваемых фамилий, то никакой разницы не будет. Понадобится индекс, но он и в вашем случае понадобится. Какие-то фамилии вытаскиваются чаще, какие-то реже.