mdl Ennor Tiegael
Если же отложенная проверка не поддерживается, то можно перевернуть схему с ног на голову, примерно так:

так ведь тогда могут появляться паспорта, никому не принадлежащие :) Проблема просто переехала в другую таблицуТак может просто совместить их в одной таблице, так как в примере паспорт является обязательным атрибутом клиента ? И вместо сущностей "Клиент", "Паспорт" ввести одну - "Клиент с паспортом".

mdl ChA
Так может просто совместить их в одной таблице, так как в примере паспорт является обязательным атрибутом клиента ? И вместо сущностей "Клиент", "Паспорт" ввести одну - "Клиент с паспортом".вроде как рекомендуемым подходом к проектированию является выделение каждой сущности в отдельную таблицу, тут даже не так давно была ветка, где это обсуждали. Например, если человек сменил паспорт, то я просто добавлю новую запись в Паспорта, а старый паспорт останется для истории (можно ввести флаг Актуальный, что-бы различать, какой паспорт действующий).Сущность не является абсолютом, а всего лишь отражает взгляд аналитика на предметную область, которую он моделирует. В вашей ситуации, IMHO, обязательность паспорта для клиента подразумевает, что клиент вне паспорта попросту не существует. Поэтому вполне разумно не разделять их, а, наоборот, объединить. mdlНапример, если человек сменил паспорт, то я просто добавлю новую запись в Паспорта, а старый паспорт останется для истории (можно ввести флаг Актуальный, что-бы различать, какой паспорт действующий).В этом случае совсем не обязательно рассматривать паспорт как отдельную сущность, а просто добавить, например, таблицу содержащую предыдущие состояния атрибута., т.е., рассматривать как историю атрибута "Паспорт". mdlКроме того, если сущностей несколько, то базовая таблица начнет приобретать ненормальные размеры (в смысле количества столбцов). Да и когда каждая сущность в отдельном месте - то это воспринимается легче.Нет никаких теоретических ограничений на количество атрибутов сущности. Если пытаться свести проектирование к минимизации, то можно и вовсе придти к модели EAV, и считать его идеальным решением. Но такая модель уже будет относиться к чему угодно, но только не к моделированию вашей предметной области.
Вы, IMHO, как раз можете сильно усложнить ситуацию, когда начнете разбрасывать обязательные атрибуты по разным таблицам, эмулируя однозначные связи. В практическом смысле иногда это можеть иметь смысл, но вольно идти от обратного. На те комбинации, которые используются чаще всего как выборки, сделать, например, "материализованные представления"(indexed views).