Доброго времени суток всем, дамы и господа, и гости форума.
 Я не профессионал - аналитик, но... суммируя всё, что видел, всё, чему преподаватели в универе учили, всё, что сам делал... делаю вывод совершенно однозначный: логическую структуру БД необходимо поддерживать и сопровождать. АБСОЛЮТНО НЕОБХОДИМО. Но вот как именно и почему - вот где дорожка раздвоилась. Вариантов ровно 2.

Вариант 1. Логическую структуру БД сопровождают и поддерживают крайне неохотно потому, что (как выразился автор вопроса) в этом никто не заинтересован.

Вариант 2. Логическую структуру БД сопровождать приходится крайне редко вследствие того, что изначально при проектировании БД были учтены все требования к структурированию, представлению, хранению и обработке информации, как текущие, так и предполагаемые в ближайшей перспективе (2 - 5 лет развития).

Резюме по варианту 1: ТАК ДЕЛАТЬ НИ В КОЕМ СЛУЧАЕ НЕЛЬЗЯ (если ваша цель не провалить проект или обанкротить фирму; если цель именно такова - это вернейший путь к ней, и довольно короткий). Почему? На какой этап ЖЦПО приходится наибольшее количество времени и затрат? Ответ: на сопровождение. Что приходится сопровождать? Всё, из чего проект состоит: БД, код middle-ware и исполняемый front-end код. А вот теперь вопрос уже не риторический: ошибки на каком уровне обойдутся дороже всего для проекта? Может, для кого-то ответ не самоочевиден, но правильный ответ: на уровне БД. Логическая структура БД - часть, наиболе дорогостоящая в плане внесения изменений в проект: любое её изменение неминуемо повлечёт за собой лавинообразные изменения на всех остальных уровнях. Каждый DDL - оператор в уже работающей БД - это в лучшем случае десятки переработанных или добавленных строк кода на других уровнях, а теперь добавьте сюда отладку, документирование, развёртывание - и вы на тривиальную операцию угрохали, минимум, полный рабочий день (к слову сказать, я аж 6 лет проработал в подразделении крупного предприятия, где такая практика считалась не просто нормальной - она была единственной, о которой начальник отдела имел хоть какое-то представление, и на любое предложение спроектировать нормальную систему вопрошал: "Да разве иначе возможно??? К чему нам эти студенческие глупости???"). Если БД спроектирована правильно, то всё управление уровнем БД сводится к DML-операторам, и схемы БД никогда не затрагивает. И в хорошем проекте такая ситуаця является нормальной из года в год, до тех пор, пока в предметной области не начнут происходить кардинальные изменения. Мне можно возразить, что альтернативой тщательному проектированию БД может быть более сложная обработка информации на стороне сервера (на уровне  middle-ware), но, прошу прощения, хрен редьки не слаще. Только долбёжка кода станет более объёмной, и требоваться будет чаще, со всеми вытекающими последствиями. Не стану своего мнения навязывать, но лично для себя: ТЩАТЕЛЬНОГО ПРОЕКТИРОВАНИЯ ЛОГИЧЕСКОЙ СТРУКТУРЫ БД НЕ ЗАМЕНИТ НИЧТО. Даже если будут сорваны все мыслимые сроки проекта, даже тогда время, затраченное на проектирование БД - точно не затрачено впустую. В дальнейшем, на этапе сопровождения, проект окажется и чрезвычайно дёшев, и чрезвычайно живуч! А чаще всего от неправильного будет отличаться просто тем, что окажется жизнеспособным.

Резюме по варианту 2. Если бы мне предложили использовать в условиях реального бизнеса информационную систему, в которую для добавления одной операции необходимо было бы изменять логическую структуру БД, я бы такую систему не взял. Вообще, мне не представляется нормальным, если в работающей системе приходится делать изменения чаще 1 раза в 6 месяцев (при очень динамично развивающейся предметной области).  На 6 месяцев вперёд увидеть предметную область не удаётся только в исключительных случаях (единственный пример, быстро приходящий на память, - законотворчество в некоторых странах мира). И частота внесения в проект изменений, и объём этих изменений напрямую зависят от того, насколько тщательно спроектирована логическая структура БД. И общие наблюдения за опытом - своим и чужим - подтверждают: если БД сделана правильно, сопровждать её структуру приходится очень редко, но вовсе не потоу, что это никому не выгодно. В этом просто необходимости нет. И затраты на сопровождение такого проекта - просто мизерные по сравнению с попытками заставить нормально работать мастодонтов, где вместо изначального правильного структурирования информации выбрали путь более сложной обработки информации на сервере (думали, сейчас сделаем что-нибудь для отчётности, а уж потом-то мы всё это заставим работать так, как нам надо!... ОЧЕНЬ РАСПРОСТРАНЁННОЕ МНЕНИЕ, И ОЧЕНЬ ОШИБОЧНОЕ...).