Если же считать, что лампочка включена по состоянию флага родительской комнаты, получается не очень красиво.
Очень даже красиво получается, зачем делать дублирование информации, при условии, что выключатель действует на все лампочки. Потом пишем просто вьювер:

и когда надо всегда по нему узнаем состояния лампочек.

Первый предложенный вами вариант я считаю не годиться, так как не соотвествует правилам нормализации данных. Если рассматривать такую постановку, где выключатель действует не на все лампочки, значит появиться еще таблица "Выключатели в комнате" и дальше лампочки будут по ним привязываться. Если рассматривать случай, когда выключатель действует на все лампочки, но состояния некоторых из них было изменено вручную (например лампочка сгорела или же ее выкрутили), то можно сделать с помощью как раз наследования аттрибутов дочерних обьектов от родительских:
3 таблицы:
Комнаты (ID_комнаты,Выключатель)
Лампочки (ID_лампочки, ID_комнаты)
РеальноеСостояние(ID лампочки, Выключатель)
В таблицу РеальноеСостояние пишем только те лампочки, которые работают не зависимо от выключателя комнаты. Так же пишем вьювер:

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

Все решается конкретными условиями постановки. Если вешать флаг на лампочки, то недого написать триггер на обновление выключателя и на автопилоте всем лампочкам записывать это состояние. Если лампочек миллионы или они пронумерованны и в постановке сказано, что их могут перемещать из комнаты в комнату, то схема ссылки на выключатель более эффективная, так как при изменении состояния выключателя или же перемещении лампочки из комнаты в комнату не надо лопатить огромные обьемы данных и всем выставлять один и тот же флаг. Если хотят вести учет лампочек - когда и в какой комнате была зарегистрированна, какие были периоды между включением и выключением и т.д. - то структура еще больше усложняется и опять же выгоднее получается ссылаться на информацию родительского обьекта, чем хранить историю включения/выключения каждой лампочки. Ну и т.д. и т.п. Каждое решение имеет право быть, если оно удовлетворяет постановке. Однако честно говоря мне было бы лень даже если в задаче всего 3 лампочки писать из за этого триггер - сказано, что лампочки всегда от выключателя зависят, значит для меня вьювер самое удобное решение.

U-gene
Например в лампочке может появиться флаг "сгорела"(выключатель включен, а лампа не горит)...Или вдруг потребуется в комнате поставить второй(3,4,...) выключатель?
если Вы не против я процитирую самого себя:
Если рассматривать такую постановку, где выключатель действует не на все лампочки, значит появиться еще таблица "Выключатели в комнате" и дальше лампочки будут по ним привязываться. Если рассматривать случай, когда выключатель действует на все лампочки, но состояния некоторых из них было изменено вручную (например лампочка сгорела или же ее выкрутили), то можно сделать ...
Я заметил небольшую разницу в наших высказываниях - я изначально на уровне постановки прогнозирую критические ситуации и проектирую решение, Вы же рассматриваете условия динамического изменения постановки реального проекта.
Мне кажется, что легче чем хранить избыточную информацию на все случаи жизни, легче один раз все четко описать в постановке. Если в постановке "вдруг" что то появлется новенькое, значит постановка изначально не была до конца проанализирована на все критические случаи жизни и соотвествующе структура БД была не правильно спроектированна.