Простенький пример. Составляем словарь базы данных - таблицы, поля, связи между таблицами. Храним это добро в следующей структуре:
Tables ( TableID , Name, Owner, other attributes)
TableFields ( TableID , FieldID , Name, Type, Size, other attributes)
Relations ( RelationID , TableID , ForeignTableID , Name, other attributes)
RelationFields ( RelationID , TableID , FieldID , ForeignTableID , ForeignFieldsID )

PK выделены болдом
TableFields.TableID, Relations.TableID, Relations.ForeignTableID - внешние ключи на Tables
RelationFields.(RelationID & TableID & ForeignTableID) - внешний ключ на Relations
RelationFields.(TableID & FieldID) и RelationFields.(ForeignTableID & ForeignFieldID) - внешние ключи на TableFields

Relations является реализацией связи многие-ко-многим с дополнительным ключевым аттрибутом (RelationID, необходим для возможности задания множественных реляций между одной парой таблиц). Для простоты можно принять, что между парой таблиц может быть только одна связь, выкинуть RelationID отовсюду, и получить классическую связь многие-ко-многим.
Ну да не суть. Пытаемся избавиться от составного PK в таблице Relations, чтобы не тянуть его дальше по всем связанным таблицам (в нашем случае это RelationFields).

Если в Relations составной PK заменить суррогатным несоставным, и соответствующим образом переделать RelationFields, то получим:
Tables ( TableID , Name, Owner, other attributes)
TableFields ( TableID , FieldID , Name, Type, Size, other attributes)
Relations ( RelationID_Ersatz , RelationID, TableID, ForeignTableID, Name, other attributes)
RelationFields ( RelationID_Ersatz , TableID , FieldID , ForeignTableID , ForeignFieldsID )

TableFields.TableID, Relations.TableID, Relations.ForeignTableID - внешние ключи на Tables
RelationFields.RelationID_Ersatz - внешний ключ на Relations
RelationFields.(TableID & FieldID) и RelationFields.(ForeignTableID & ForeignFieldID) - внешние ключи на TableFieldsПри этом имеем очевидную кривизну - в RelationFields могут быть ссылки на TableFields, относящиеся к каким угодно таблицам, в том числе и не входящим в реляцию.

Правда пример не очень красивый получился, т.к. от замены составного PK не несоставной в связанной таблице ключ не сократился, ну да ничего. Если избавится от составного ключа в таблице TableFields, то получим сокращение ключа в таблице RelationFields до (RelationID_Ersatz, FieldID_Ersatz, ForeignFieldID_Ersatz). Только вот данные все равно кривые будут.
Так что аккуратнее надо избавляться от составных ключей.

2 zdraste
Но не стоит ли здесь задуматься над использованием альтернативных способов обеспечения целосности (тех же триггеров напримет) дабы не тащить за собой эти составные ПК?
Задуматься - можно и нужно.
Описанный случай - это пример нарушения 4-й нормальной формы. В принципе можно всякими триггерами, хранимками, констрейнтами и прочей лабудой компенсировать отсутствие 4-й НФ. И даже 3-ей. И даже 1-ой, если очень хочется :).
Иногда так и приходится делать.
Только я вряд ли пойду на то, чтобы сознательно устраивать денормализацию только из-за того, что лениво составные ключи таскать за собой.

2 Роман Дынник
Бизнес-логику пытаемся навесить на структуру данных?
Причем здесь бизнес-логика?
Если уж ее упоминать, то не "бизнес-логику" на структуру навесить, а сделать нормальную структуру исходя для затребованной логики.