П-Л
Придется как-то выстраивать отношения.Вот у меня такая ситуация. Путем проб и ошибок пришел к пути выслушивания пожеланий, их записи. А на затем, после оценки трудозатратности обсуждение их первоочередности.
Кстати, спустя некоторое время понимаю, что во многих случая босс был прав, однако я не смог из его слов вынести полезную информацию. На тот момент я не умел за деревьями видеть леса. А сейчас, иногда, получается.

П-ЛКаким образом вообще НАЧАЛЬСТВУ может быть хоть какое-то дело до структуры БД ?

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

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

Все, что ниже, не имеет к начальству никакого отношения.Поправки:
1. ТС как я понял спорит с поставленной целью - переложить работу пользователей на программиста.
2. Исполнитель может ошибаться. По своему опыту, признаю, что во многих моментах, что я спорил с начальником, он был прав. Трудно это понять со своей колокольни.
Крайне в этом полезной для меня оказалась вот эта чья то дипломная работа - http://yurayu.narod.ru/diplomaw1.htm
Особенно интересные замечания по типичным ошибкам при создании систем автоматизирования бэк-офисов, то есть КИС в их обычном виде. Узнал свои ошибки. Было полезно.

ineedyou не смешивайте в кучу проблемы хранения информации и доступа к ней. Денормализация и 3НФ это круто, но за гридовый интерфес к 20(0) таблицам у салес-манагера вас убьют :) Пишите нормальный интерфейс, точка.
Очень хороший совет. Как мне дали совет - интерфейс не должен зависеть от структуры данных. Трудно следовать данной рекомендации, приходится многому учиться.