SanyLПлюсы нормализации:
1)Относительно меньший объем данных (соответственно БД)
Не факт. Если поля из "detail" таблицы сложить в одно поле "master" таблицы, то объем может быть меньше (на размер FK detail таблицы).

SanyL2)Проще прояснить моменты с целостностью данных
Что понимается под этим термином: "целостность данных"?

SanyL3)Модель более близка к реляционной теории
Ничуть...

Остальное не более убедительно.

Единственное (но несомненное!) преимущество нормализации состоит в исключении АНОМАЛИЙ (об этом написано в любом приличном учебнике).
Нормализация - это набор правил, основанных не на какой-то строгой математической теории, а на... здравом смысле. Соответственно, призывы к денормализации - это призыву к отходу от здравого смысла (не более, но и не менее, того). И опасность денормализации состоит только в возможности появления аномалий при "сборке" данных (что, как правило, проявляется не в момент разработки базы данных, а в момент ее эксплуатации).

softwarer SemaphoreСоответственно, призывы к денормализации - это призыву к отходу от здравого смысла
Бред.
Денормализация - это набор правил, основанных на том же самом здравом смысле.
Таким образом, Вы хотите сказать, что здравый смысл лежит в основе и нормализации, и ее отрицании. Вот это действительно бред!
Денормализация - удел тех, кто не понимает очень простого правила: то как задумывалась БД, и то как она (в конечном счете) используется, разные вещи. Любая более или менее серьезная система имеет свою логику развития, которая может быть отличной от логики, заложенной разработчиком. (Дюма-отец говорил: "Не я управляю свими героями, но они водят кончик моего пера"). А, следовательно, велика вероятность того, что в денормализованной БД проявятся аномалии, и пользователи увидят информацию, которой... не существовало и не существует в реальности.
Денормализация основана не на здравом смысле, а на благих пожеланиях, которыми, как известно, "вымощена дорога в ад".

vadiminfo Semaphore
Что понимается под этим термином: "целостность данных"?
Удовлетворение данных некоторым логическим правила во всех состояниях БД.
Вот пример, про сложности нормализации по 3НФБК:
Пусть есть Договоры (Д), отделения (О) и подразделения (П) этих отделений. И пусть есть логическое правило: Только одно подразделение отдела может участвовать в конкретном договоре (Назовем правило S1). Очевидно есть фукциональная зависимость П->O, поскольку подразделение может принадлежать только одному подразделению (тоже логическое правило). Тогда есть функциональная зависмость ДП->О => ДП - ключ (потенциальный). Если нет правила S1, то отношение R(Д,О,П) - не удовлетворяет 3НФ, и схема может быть нормализована декомпозицией на отношения Q(Д,П), T(П,О).
Но поскольку есть S1, и означает по сути ДО->П => атрибут О - первичный (входит в ключ). Отношение R(Д,О,П) - удовлетворяет 3НФ, но не удовлетворяет 3НФБК. Очевидно, там есть избыток: если подр п1 отделения о1 уже участвоало хоть в одном договре, то любое его участие в другом приведет к повторной записи о том что п1 принадлежит о1, хотя эта информация уже есть в БД п1. Однако, если нормализовать по 3НФБК декомпозицей как и раньше, то навязать схеме зависмосить ДО->П с помощью выделения ключей не удастся. Как следствие могут занести данные так, что в одном договоре будет участвовать несколько подразделений одного отделения - нарушение ограничения целостности S1.
Чтобы схема находилась в 3НФ, и в схеме были прописаны ограничения целостности с помощью выделения ключей, ее придется привести к виду:
R(Д,О,П), T(П,О) (и, например, объявить ключами в первом отношении пары {Д,О}, {Д,П}, а во втором {П}).
Вот проектировщик стоит перед выбором:

1) схема R(Д,О,П), T(П,О) - ограничения целостности навязаны с помощью выделение ключей, но она не удовлетворяет 3НФБК и есть соответсвующая этому избыточность

2) схема R(Д,П), T(П,О) в 3НФБК - избытка нет, но нельзя с помощью выделения (обяъвления) ключей навязать правило одного подразденления отделения в договоре. Но могут разные подразделения разных отделений, т.е. с помощью внешних ключей тоже нельзя.

Что лучше? Правда, в некоторых случаях на помощь 2 могут прийти триггера.
Но в общем случае есть проблема выбора.
Т.е. теория не может дать точных критериев оптимальной схемы во всех случаях, и потому пректирование может представлять из себя тскусство, наверное.
Что лучше? Давайте разберемся. Итак, подразделение однозначно определяет отделение, которому принадлежит. То есть, П -> О - первая ФЗ. Вторая ФЗ: договор определяет подразделение (правило S1), то есть, Д -> П. В результате приходим к двум отношениям: R1(#П, О) и R2(#Д, П). Отношение R2 не позволит нам иметь более более одного подразделения для данного договора, а отношение R1 поставит однозначное соответствие между подразделением и отделением, которому оно принадлежит.
Ваша ошибка вот здесь: "Тогда есть функциональная зависмость ДП->О => ДП - ключ (потенциальный)". Вы (напрасно) используете superkey, удалите из ключа договор (подразделение само однозначно определяет отделение).

softwarerРяд возможностей денормализации сегодня поддерживаются серверами БД, то есть "без дополнительных усилий". Это materialized view, это calculated fields, это nested tables и varrays, это, наконец, классический вариант включения дополнительного поля в уникальный ключ (приводящий к поддержанию целостности в дочерней таблице FK-constraint'ом). Можно назвать пару вещей, которые хоть формально не денормализация, но очень на нее похожи - на первом месте, безусловно, bitmap join indexes (это индекс который строится для таблицы A по значениям из таблицы B, взятых по внешнему ключу A->B). Это, собственно, умение "брать значения из индекса" - в MSSQL, как мне говорили, появляется специально заточенная под это фича "класть значения некоторых полей только в листья индекса, но не в промежуточные узлы".
Во-первых, хотелось бы заметить, что создатели СУБД стремятся удовлетворить пожелания разработчиков программного обеспечения, далеко не всегда задумываясь о теоретических основах и последствиях своих решений. Об этом много говорилось на разных конференциях, например, посвященных вопросам стандартизации SQL (в частности, Joe Celko техническим редактором комитета стандартизации ANSI X3H2). Поэтому ссылаться на те или иные механизмы какой-то СУБД, надо с большой осторожностью, не забывая при этом, что большинство СУБД - коммерческие продукты и предназначены (в том числе) для получения прибыли (иногда потворствуя популизму). Во-вторых, опасно и то, что создатели СУБД порой весьма агрессивно пытаются "протащить" через стандарт те решения, которые приняты в данных СУБД, то есть, использовать стандарты, как средство конкурентной борьбы.
1. "materialized view" и "calculated fields" - эти два механизма не имеют никакого отношения к нормализации. Есть понятие таблицы и есть понятие представления (View) в полном соответствии со стандартом ANSI SPARC. Нормализация распространяется только на отношения (на концептуальном уровне), структуру таблиц (на физическом уровне), но не на view и не на вычисляемые поля, которые относятся к представительскому уровню. Никто и никогда не рассматривал вопросы нормализации на уровне представления информации.
2. "nested tables и varrays". Рассматривая вопрос о нарушении 1НФ посредством "сложных" структур, необходимо определиться с понятием атомарности атрибута. Например, является ли дата или строка атомарной величиной? Это относится и к вложенным структурам (таблицам) и массивам и BLOb полям. Почему строка, состоящая из символов, атомарна, а массив состоящий из элементов, неатомарен? То, что атомарно на одном уровне, может быть нетомарно на другом (более низком) уровне. Эта простая истина давно известна. Например, удобно хранить рабочий календарь на каждый месяц в массиве из 31 элемента. И если задача, стоящая перед разработчиком, не предусматривает рассмотрения отдельного элемента этого массива, то почему разработчик не может принять атомарность рабочего календаря? Какое же в этом нарушение 1НФ?
3. "классический вариант включения дополнительного поля в уникальный ключ (приводящий к поддержанию целостности в дочерней таблице FK-constraint'ом)". Что-то есть в этой "классике" от лукавого... Нет ни описания примера, ни рассмотрения альтернатив. Можно подробнее рассмотреть эту ситуацию "с поддержанием целостности"?
4. "Можно назвать пару вещей, которые хоть формально не денормализация"... Конечно, можно. Можно поговорить о погоде, например. Это тоже не имеет отношения к денормализации, но зато всегда злободневно.

Cat2Semaphore. Не согласен с Вами. Денормализация - это обычный прием проектирования
Добавлю от себя. Денормализация - это обычный прием проектирования основанный на отсутствии здравого смысла... :)
Cat2Другое дело, что для ее применения нужно сто раз отмерить.
Что отмерять-то будете? Аномалии? Тут есть один "пунктик": бороться с аномалиями придется вне физической схемы БД с помощью триггеров, хранимых процедур, приложений и т.п. Но появится новый разработчик, который не знает об этих "обходных" решениях, и... тогда пользователи, администраторы БД и это самый разработчик скажут Вам большое "спасибо"... на нашем выразительном русском языке.
Разработчики редко задумываются о том, что информация в БД может дорогого стоить! И забота о достоверности информации не бывает избыточной. Вырастут мощности "железа", улучшаться алгоритмы обработки информации, но достоверность информации при этом улучшиться не сможет!
Cat2И, необходимо, что бы проектировщик в полном объеме продумал и реализовал поддержку целостности и непротивороречивости
Не сочтите за труд и объясните, как обеспечить поддержку "целостности" и непротиворечивости. Есть у Вас в "кармане" набор более простых и ясных правил, чем правила нормализации? Можете их сформулировать? Премия Тьюринга Вам гарантирована! Ну, а мое внимание будет самым пристальным :)
Итак, что необходимо сделать для повышения "целостности" и "непротиворечивости" при несоблюдении нормализации? Жду!
Cat2Немного перефразируя Вас () - денормализация - удел тех, кто четко и ясно понимает, к чему приведут ее последствия и знает как с этим боротся.
Ну, вот и раскройте существо этого "четкого и ясного понимания". А мы посмотрим, надо ли выбирать этот удел.