Руслан Федосеенко

Хочется понять на теоретическом уровне.

У вас есть два множества:
1) Person - большее множество, производное.
2) People - родитель, является подмножеством Person и входит него полностью.
Так вот - из большего(производного) множества вы можете выделить подмножество, т.к. это подмножество целиком и полностью входит в производное. А вот из меньшего(родительского) выделить большее(производное) никак нельзя. У вас тупо нет данных об остальных элементах производного множества.

А теперь на пальцах:
У вас есть листок бумаги. Он является составным объектом из всех потенциальных(!!!) произвольных его частей(вырезанных областей, оторванных кусков и т.п.). Получается что физически вы можете из этого листка бумаги выделить/оторвать/вырезать любой кусок, находящийся в его составе(приведение большего к меньшему), а вот из любого меньшего куска этого листка получить общий, производный, уже нет.
Именно по этому приведение базового к производному - некорректная операция с точки зрения логики и является, в вашем случае, ошибкой.

Я считаю логически неверным такой подход, при котором промокоды представляются простым количеством и соответственно одним полем целого пита. Я бы спроектировал систему по-другому: Каждый отдельный промокод - это отдельная сущность со своим уникальным ID, внешним клюем к таблице "Клиенты" и внешним ключем к таблице "Оплаты", значение NULL в этом поле обозначает, что промокод еще не израсходован. Легко написать (под)запрос, который возвращает количество неизрасходованных промокодов для клиента, можно даже в БД сделать view (readonly) с клиентами и количеством неизрасходованных промокодов для них. Расходование промокода осуществятся сопоставлением его с записью в таблице "Оплаты". При удалении соответствующей оплаты для поддержания целостности внешних ключей соответствующее поле в промокоде будет сброшено в NULL автоматически, тем самым промокод вернется в число неизрасходованных.