Это хороший вопрос, чтобы показать некоторые различия и сходства между объектно-ориентированным мышлением и реляционным моделированием.
Прежде всего, нет строгих правил в отношении создания таблиц, это зависит от проблемного пространства, которое вы пытаетесь смоделировать (однако наличие поля для каждой из таблиц вовсе не является необходимым и представляет собой ошибку проектирования - главным образом потому что это негибко и трудно запросить).
Например, вполне приемлемый дизайн в этом случае должен иметь таблицы
Names (Name, Email, Bio)
Talents (TalentType references TalentTypes, Email references Names)
TalentTypes (TalentType, Description, Parent references TalentTypes)
Приведенный выше дизайн позволит вам иметь иерархические типы талантов, а также отслеживать, какие имена имеют таланты, у вас будет одна таблица, из которой вы можете получить все имена (чтобы избежать регистрации дубликатов), у вас есть одна таблица из который вы можете получить список талантов, и вы можете легко добавлять новые типы талантов и / или подтипы.
Если вам действительно нужно хранить несколько специальных полей для каждого из типов талантов, вы все равно можете добавить их в виде таблиц, которые ссылаются на общую таблицу талантов.
В качестве иллюстрации
Models (Email references Talents, ModelingSalary) -- with a check constraint that talents contain a record with modelling talent type
Обратите внимание, что это только иллюстрация, возможно, было бы разумно иметь Зарплату в таблице талантов, а не таблицы для определенных талантов.
Если в итоге вы получите таблицы для определенных талантов, то в некотором смысле вы можете рассматривать таблицу талантов как своего рода класс, от которого у определенного таланта или субталанта наследуются свойства.