juventineПрошелестел кучу информации относительно идентифицирующей и неидентифицирующей связях. Вот, так сказать, кратенько о том, что вынес:
Искренне сочувствую. Это пожалуй наиболее дурацкий момент в существующей теории.

Понятие идентифицирующей связи имхо придумал сугубый теоретик просто "чтобы было красиво", никакого практического смысла в таком разделении нет. На практике гораздо удобнее и полезнее думать в терминах "есть атрибут", "есть связь (просто связь - без эпитетов)", "атрибут входит в первичный ключ", "атрибут входит во внешний ключ". То есть - делайте неидентифицирующие связи и не парьтесь; в тот момент, когда почувствуете желание включить атрибут внешнего ключа в первичный - обдумаете и может быть сделаете, вот и всё.

Позволю себе сразу добавить выжимку по остальным "ярким моментам" теории применительно к транзакционным системам (то есть БД, рассчитанным на ввод и редактирование данных пользователями). Пункт первый: первичный ключ таблицы практически всегда должен быть простым (из одного атрибута). Единственное более-менее частое исключение - развязки многие ко многим; иногда нужно сделать таблицу развязки между двумя-тремя другими, и тогда как правило вполне подходит ключ из внешних ключей на эти таблицы. Второе: если на таблицу есть ссылки (то есть у неё есть дочерние), ключ тем более должен быть простым. Третье: ключ практически всегда должен быть суррогатным. По факту, если Вы примете за правило делать у любой таблицы простой суррогатный ключ, то будьте уверены, получившаяся система будет мало отличаться в этом смысле от наилучшей возможной. С ростом опыта Вы нащупаете редкие случаи, когда от такой практики можно или даже стоит отступить, а пока - лучше не делайте этого.

Наконец, стоит упомянуть один особый случай - ромб. Представьте себе, что у нас есть таблица А, на неё ссылаются Б и В. Нам надо сделать таблицу Г, ссылающуюся как на Б, так и на В. В этом случае возможен следующий приём: у таблиц Б и В делается составной первичный ключ, включающий в себя ключ А. В Г, соответственно, внешние ключи, ссылающиеся на эту таблицу и использующие один и тот же атрибут a_id для значения ключа, мигрировавшего из А. Таким образом возможно элегантно реализовать бизнес-правило "Г должно ссылаться на Б и В, ссылающиеся на одну и ту же запись в А". Такая структура востребована, например, если А и Б - мастер и деталь (скажем, счёт и его позиции), а В и Г - другая мастер-деталь, порождённая первой (скажем, расходная накладная и её позиции). Для удобства работы при этом Б и В по-прежнему должны содержать поле суррогатного ключа (то есть их первичный ключ избыточен - из него можно исключить ключ А, и он всё равно останется ключом).