softwarerПреимущества такого ключа - в денормализации.Не понял, какое отношение имеет составной ключ к денормализации. Где и какая нормальная форма нарушается ? Можете пояснить ?

mcureenabНарушается принцип один факт - одна запись.Очень вольная интерпретация нормализации, IMHO.

mcureenabЗапись в table3 - это факт связи записей table1 и table2. Если в table4 создать запись со ссылкой на table3, тот же самый факт связи записей table1 и table2 будет отражён в БД ещё раз.Логика понятна, но предпосылка неверна по причине вышеупомянутой вольности трактовки. Понятие нормализации применимо к конкретной таблице, а не к связям между ними. Нет понятия НФ для БД, они есть только для таблиц.
По сути, вы проверяте, удовлетворяет ли множество атрибутов некоторой таблицы той или иной НФ. Если не удовлетворяют, то можно применить определенные усилия для того, чтобы достигнуть следующей степени нормализации, хотя можно и не применять. Если решили не применять, то так тому и быть, и все последствия в виде появления аномалий, избыточности или нарушения целостности данных будете расхлебывать по мере поступления оных.
В противном случае, если принято решения о повышение степени нормализации исходной таблицы, то вы осмысленно разделяете множества атрибутов исходной таблицы на несколько подмножеств, добиваясь при этом снижения возможности появления различных несуразностей в хранимых данных. При этом, разумеется, между получившимися таблицами появляются некие логические связи, но сами по себе они никакого отношения к нормализации не имеют. Они лишь следствие расщепления, и если подобная связь между данными разных таблиц обеспечивается не одним, а несколькими полями, то так тому и быть.
Конечно, Вы можете добавить суррогатный ключ и считать, что связь по одному полю более нормализована, чем если бы она осуществлялась по нескольким полям. Но исходя из вышесказанного, к нормализации это не имеет ни малейшего отношения и применяется только для решения конкретных практических целей, часть из которых упомянул softwarer.
Теоретически же, скорее наоборот, при таком подходе вы добавляете в свою модель избыточную информацию, смысл которой полностью отсутствует в предметной области.
mcureenabВ итоге мы получаем аномалию обновления.В классическом смысле, насколько мне известно, аномалия обновления возникает в том случае, когда в таблице есть неключевые атрибуты, зависящие друг от друга. Поэтому, обновив лишь один из этих атрибутов, мы можем получить несогласованную информацию. И каскадные обновления не имеют к этому никакого отношения.

softwarerБыть может я неправ, но по моим ощущениям, термин "денормализация" сейчас означает нечто большее, нежели "нарушение нормальных форм", которые, при всей их полезности, избавляют не от всех возможных некорректностей.Какой смысл вносить нечто большее, если сам термин "денормализация" уже говорит о своем происхождении ?
softwarerСкажем, давайте рассмотрим таблицы из моего примера:


Что касается table#, с ним все понятно - самый обычный автоинкрементный ключ. Интерес представляют колонки report# и table_column#. У нас есть выбор:

1. Сделать их уникальными (то есть потенциальными ключами), опять же обычный автоинкремент.
2. Сделать их уникальными в пределах #table, но не гарантируя уникальность вообще.

Полагаю, очевидно, что первое решение "гарантированно не хуже" второго. Гарантированно - в том плане, что это "второе плюс дополнительное требование", а следовательно, любая аномалия, допускаемая первым, допускается и во втором итп. Короче говоря, множество недостатков первого подхода содержится во множестве недостатков второго подхода. Мало того, легко назвать, чем первых подход лучше, то есть включение строгое, множества не равны. Однако! Однако, второй подход строго соблюдает нормальные формы, в то время как первый - нарушает.В меру моего понимания данного примера.
Гарантировано хуже. Сначала о поле table_column# . По первому способу оно становится независимым от table# и, соответственно, поле table# исключается из состава ключа (хотя и может входить в состав суперключа, но это пока неважно в данном случае). Таким образом может возникнуть нарушение целостности данных, т.е., в таблице report_columns может нарушиться соответствие между значениями полями table_column# и table# .
Если же сделать по второму способу, то такая ситуация возникнуть уже не может, именно благодаря составному ключу.
Аналогично в случае поля report# . Если Вы его объявляете независимым и ключом, то в таблице report_columns может возникнуть казус, подобный вышеупомянутому, несоответствие значений полей report# и table# .
Причиной всего этого безобразия стало наличие неявных зависимостей между полями, включенными в таблицу report_columns . Так что если мы хотим воспользоваться уникальностью(суррогатностью) полей table_column# и report# без появления аномалий, то придется приложить некоторые усилия и, в первую очередь, исключить из нее поле table# . Впрочем, это только полумера, IMHO, стоило бы начать проектирование сначала.
softwarerПо этой причине мне кажется правильным рассматривать фактическую ситуацию, не переоценивая формальные критерии соответствия.Ваше безусловное право, но в покер я бы с Вами играть не сел.