Вопрос поставлен неправильно.

База данных должна быть нормализована всегда. Но, при определенных задачах, имеет смысл подумать о денормализации.

Т.е. идти надо в противоположную сторону.

"Писать большой запрос" - это один из аргументов, который может являться причиной денормализации. Но подобную проблему надо очень тщательно продумывать. Из нормализованной базы сделать ненормализованную очень просто, а вот обратный процесс, зачастую невозможен.

Насчет удаления ссылок - это вопрос целостности базы данных и к нормализации вообще-то имеет весьма косвенное отношение.

Например, если у тебя все тот же справочник, но в основной таблице храниться не код записи из справочника, а название. И ты удаляешь запись справочника. Ведь все-равно встанет вопрос, что делать с записью в основной таблице.

Krushinskaya OlgaВ том то и дело, что я столкнулась с проблемой. Создала базу по всем правилам нормализации. А оказалось, что не стоило так делать. Например, при обновлении данных в справочниках (переименование, удаление) записи в основной таблице, касающиеся информации из справочника никак не должны меняться. И что делать? Разнормализировать?
Опять, это другая задача. Не имеющая отношения к нормализации. Я так понимаю, что речь идет о неких выходных (бумажных) формах (акты, накладные, счета-фактур и т.п). Некий контрагент раньше имел одно название, а затем был переименован. Но все старые документы должны остаться со старым названием.

Проблема здесь в следующем.

Если ты сделаешь привязку "по значению", т.е. в сам документ вставишь название контрагента, а не его код, то ты никогда не получишь баланс, полную отчетность, по этому контрагенту. Ты просто не найдешь части документов.

Существуют 2 стратегии решения данной проблемы:

Создавать отдельную таблицу (или директорию) для хранения распечатанных документов.

Т.е. вот распечатали документ, делается ее копия, например, в формате PDF. И если возникает необходимость распечатать ее "задним" числом, то берем этот файл из архива и печатаем. А что там есть сейчас в базе нас уже не интересует.

Недостаток такой стратегии очевиден - слишком много лишних файлов. Придется сохранять копии после каждой печати документа. Ведь неизвестно в какой имеенно момент произайдет замена реквизита.


Создавать историю реквизитов.

Это уже требует более сложного программирования. Для каждого такого реквизита заводится дополнительная таблица, где хранится его значение и период действия.

Например, один и тот же контрагент с 01.01.2000 по 01.01.2005 назывался "Рога и Копыта", а начиная с 02.01.2005 - "Копыта и Рога".

Вот в этой отдельной таблице и делаем дополнительную запись для "архивных" значений. Текущие значения оставляем в самом справочнике.

Когда возникает необходимость печатать документ задним числом, то смотрим, есть ли за указанную дату запись в истории реквизита. Если есть, то ее и используем вместо текущего значения.

Такая стратегия используется в 1С.

На всякий случай повторюсь: хранится история не для всей записи справочника, а для значений его отдельных полей. Тут надо серьезно подойти к вопросу, какие именно реквизиты "заслуживают" своей истории.

Krushinskaya OlgaИ еще вопрос, зачем создавать связи между таблицами непосредственно в конструкторе БД? Если можно в ДЕ форме указать эти связи, или вообще, работать с курсором.
Это разные типы связи. У них разное назначение.

Подробнее об этом почитай здесь

Связи и отношения между таблицами