"Очистить таблицу получателей, сохраняя только общие данные;"
Именно то, что нужно сделать.
"Добавить суррогатный первичный ключ в таблицу получателей, назовем его BeneficiaryID;"
Может быть полезно, но не забывайте, что ЕСЛИ существует «естественный» идентификатор, то его уникальность также должна быть обеспечена.
«Разделить таблицу получателей, создав две дочерние сущности(CorporateBeneficiary & PhysicalBeneficiary "
Да. Заметьте, что будет трудно обеспечить" абсолютную "целостность данных (при одновременном обеспечении того, что все NaturalBeneficiaries являются Бенефициарами, что все NonNaturalBeneficiaries также являются Бенефициарами, и что все Бенефициары являютсялибо естественные, либо ненатуральные бенефициары).
"различается по флагу в основной таблице бенефициаров"
Нет. Не будет этого. Этот флаг является избыточным, а избыточность добавляет сложности без добавления значения.Если вы хотите узнать, является ли бенефициар натуральным или ненатуральным, проверьте таблицу,если этот факт записан.
"Найти (значимые) первичные ключи для CorporateBeneficiary & PhysicalBeneficiary;"
Если вы вводите суррогат для бенефициаров в целом, вам не нужно копировать естественныйидентификаторы в этих других таблицах.Это снова избыточность, добавление сложности без добавления ценности.
«Реальная проблема, с которой я столкнулся, заключается в следующем: как я могу / должен справиться с дополнительным усложнением, добавленным атрибутом« foreign »в этой модели?» «
Вы могли бы применять один и тот же подход, различая национальный и вненациональный (как для корпоративных, так и для физических лиц), и это может быть что угодно, от рекомендуемого до абсолютно необходимого, если целостность данных имеет ключевое значение, когда это касается, скажем, по крайней мере, национальные бенефициары. Например, может применяться законодательство, которое заставляет проверять, являются ли национальные номера SSN или идентификационные номера национальной корпорации «действительными» в соответствии с национальными правилами.Вероятно, крайне важно, чтобы такие правила проверялись в СУБД и , а не только в вашем приложении. Конечно, для неграждан подобные проверки обычно не требуются, или вообще невозможны.
Если вы возьмете такое различие между NПринимая во внимание то, что в вашей структуре базы данных учитываются национальные и не национальные, вы, скорее всего, также захотите создать представление, объединяющее два (национальные и не национальные) вместе, а затем вам придется «преобразовать» свои данные в«унифицированный» «общий» формат, который, вероятно, будет просто CHAR (даже если вы знаете, что, скажем, для National PhysicalBeneficiaries, содержимое будет номером их SSN, который, как вы знаете, состоит из некоторого фиксированного числа цифр).
Если вам не нужно учитывать в своей структуре базы данных такое различие между национальными и не национальными, то вы будете вынуждены использовать тот же «унифицированный» «общий» формат в вашей отдельной таблице, который будетхранение данных как для национальных, так и иностранных.