Есть некая БД учета зарплаты.
В ней есть таблица НАЧИСЛЕНИЯ (#ТабНомер, #Дата, НачПоКоду1, НачПоКоду2, НачПоКоду3, НачПоКоду4, .... ,НачПоКоду70).

С точки зрения здравого смысла логично сделать
СПРАВОЧНИК_НАЧИСЛЕНИЙ(#КодНачисления), а таблицу начисления сократить до НАЧИСЛЕНИЯ(#ТабНомер, #Дата, КодНачисления, СуммаНачисления)

Вопрос- как все это соотносится с формальной нормализацией. Какая НФ нарушается при исходной схеме таблицы? Вроде бы 3НФ однозначно присутствует.

mir ЗоринАндрейЯвное нарушение 1НФ.
Не должно быть в записи "nested relation".
Это одно из требований 1NF наряду с атомарностью атрибутов.
Андрей, по-моему 1NF требует атомарности именно атрибутов. То есть с этим здесь порядок. А "nested relation" нарушает 3NF.
IMHO, здесь проблема не с нормализацией, а с негибкостью проекта. То есть с таким проектом нельзя ни избавиться от к-л кода начисления, ни добавить новый (при необходимости).
насколько я знаю 1 НФ говорит только об атомарности атрибутов

2 НФ касается только таблиц с составным ключом, так что её пропускаем

3 НФ говорит о зависимости любого неключевого атрибута от ключа. С этим здесь все нормально, насколько я понимаю. Каждый из кодов начисления зависит только от ключа.

Не уверен, что прав, но что-то про nested relation говорилось в 5НФ. Был бы очень признателен, если бы вы объяснили, что же все таки такое "nested relation". Не уверен, что это вообще относится к моей ситуации.