softwarerБыть может я неправ, но по моим ощущениям, термин "денормализация" сейчас означает нечто большее, нежели "нарушение нормальных форм", которые, при всей их полезности, избавляют не от всех возможных некорректностей.Какой смысл вносить нечто большее, если сам термин "денормализация" уже говорит о своем происхождении ?
softwarerСкажем, давайте рассмотрим таблицы из моего примера:
1.
2.
3.
create table "tables" ( table#, ...) ;
create table "table_columns" ( table_column#, table#, ...) ;
create table "reports" ( report#, table#, ...) ;
create table "report_columns" ( report#, table#, table_column#, ...) ;
Что касается 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По этой причине мне кажется правильным рассматривать фактическую ситуацию, не переоценивая формальные критерии соответствия.Ваше безусловное право, но в покер я бы с Вами играть не сел.
