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

1. Очень спорное утверждение "Согласен по поводу анализа null'овых значений, если какие-то составные атрибуты необязательны, то имеет смысл выделить их в отдельные таблицы".
2. "Суть в том, что по смыслу это одна сущность. Например, ОБЪЕКТ. У него есть масса описательных составных атрибутов, там площадь объекта, какие-то технические показатели и т.д. Естественно можно их выделить в отдельные сущности и связать 1:1, или же сделать все атрибуты в одной. Логически это не отдельные сущности, это часть описания большого ОБЪЕКТА. Они существуют только вместе с ОБЪЕКТОМ." - эта фраза говорит о том,что возможно база спроектирована без учета на развитие.Как уже было сказано-довольно часто одинарные атрибуты становятся множественными.
3.единственное правильное решение - описание задачи в студию - по ней и решим!

p.s. неясно,что значит "описательные составные атрибуты"