Сама постановка вопроса мне кажется ошибочной. Такой вопрос по-моему не должен возникать, если всё делать правильно)
Ну вот смотрите, вы пишите
тверской2. таблицу отделов/сотрудников можно объединить в одну (дерево) или две сотрудник-отдел
Но если вы начнёте с анализа предметной области и выделения в ней ключевых сущностей, то вы непременно выделите две разные сущности: сотрудник и отдел. Соответственно эти же сущности (плюс связь между ними) окажутся сначала в вашей логической схеме, а затем и в физической (уже в виде двух отдельных таблиц). Тут вариантов быть не может по-моему)

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

тверскойbeef,
типов сущностей может быть две и больше, но таблица сущностей (id, тип, ...) может быть одна + таблица свойств (id сущности, тип свойства, свойство) т.е., грубо, две таблицы (сущности и свойства) на все типы сущностей
Это выше моего понимания)

тверскойiljy,
ошибки ввода данных возможны в любых системах, это, имхо, в значительной мере решается на уровне прикладного ПО
Решать косяки схемы прикладным ПО - это, мягко говоря, плохо) Нормальная схема должна самостоятельно поддерживать свою целостность.

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

Представил - не понравилось) Я просто не понимаю, зачем так делать? Не говорю, что так вообще нельзя делать. Можно. Можно вообще все данные в текстовом файле хранить, а прикладным ПО их оттуда вытаскивать. Только нафик оно нужно, если у нас есть СУБД. Предметная область сама диктует схемы хранения данных в "человечных" отношениях сущность-связь, и благо, современные СУБД позволяют такие схемы реализовывать.

тверскойbeef,
пример выше - автопарк
иерархическое распределение таблиц, как предлагает ChA, и есть "баланс должен быть, к этому итогу придем"
при большом кол-ве таблиц может возникнуть (и возникает) проблема - приобрели новый тип авто - автовышка, у которой новые параметры - вылет стрелы и т.д.
добавляем новую таблицу? и как следствие переписываем код прикладного ПО и хранимые процедуры на сервере, чтобы они знали о новой таблице
Каждая конкретная задача имеет конкретное решение. Общего рецепта нет и быть не может.
А если автопарк захочет в автосервис преобразоваться или вообще в ресторан? Что тоже будем таблички добавлять/переделывать?)
Я к тому, что работаем то, как правило, по ТЗ. Если в ТЗ написано сделать параметр вылет стрелы - сделаем. Если в ТЗ написано сделать так, чтобы при необходимости список параметров можно было расширить - тоже сделаем.
А так можно до бесконечности строить схемы "на все случаи жизни"...

тверскойbeef,
ТЗ пишет разработчик, заказчик, обычно, не силен в технической части, хорошо если в предметной всё понимает
мы, как разработчики, стараемся выбрать схему, которая оптимальна по производительности и простоте сопровождения
обсуждаем разные схемы на примере крайних случаев - мало таблиц <-> много талиц - в боевых системах всегда компромис
ТЗ определяет уж никак не схему БД, а требования к ПО. Более того, на стадии написания ТЗ, как правило, о схеме БД речи вообще не идёт (разве что какие-то общие требования определяются). Схема БД строится уже по согласованному с заказчиком ТЗ, в котором чётко определены требования к функционалу. Конечно, проектировщик может заложить в схему какие-то возможности её дополнения в случае необходимости (кстати, в нормально спроектированную схему, как правило, несложно внести небольшие изменения), но, повторюсь, он не то, что не обязан - он просто не должен - "предусмотрительно" делать схему "на все случаи жизни".