Вы поднимаете действительные баллы, однако вы не совсем ясно о нормализации и что это означает, например, в
1) Заявление о том, что сохранение счетов в том виде, в котором они были денормализованы, полностью и полностью неверно.
Возьмем, к примеру, цену - если у вас есть бизнес-требование, в котором говорится, что вы должны вести историю цен, то сохранение только текущей цены является неправильным, и это нарушает требования. И это не имеет ничего общего с нормализацией, оно просто не разработано хорошо. Денормализация - это привнесение в вашу модель (и других артефактов) возможностей для неоднозначности, и в этом случае вы просто неправильно моделируете свое проблемное пространство.
Нет ничего плохого в моделировании вашей базы данных для поддержки временных данных (или управления версиями и / или разделения областей базы данных на архивные / временные и рабочий набор).
Просмотр нормализации без учета семантики (с точки зрения требований) невозможен.
Кроме того, если ваш старший разработчик не видит разницы, то, я думаю, он не получил своего стажа в разработке СУБД;)
2) Вторая часть - это действительно денормализация. Однако, если вы когда-нибудь встретите старшего аналитика по БД, который серьезно проповедует нормализацию, вы услышите, как он / она скажет, что вполне допустимо денормализовать, если вы делаете это сознательно и гарантируете, что выгода от недостатка веса и аномалии не будут вас кусать. Они также скажут вам нормализовать логическую модель и то, что в физической модели вам разрешено отклоняться от идеала для различных целей (производительность, обслуживание и т. Д.). В моей книге основная цель нормализации состоит в том, чтобы у вас не было скрытых аномалий (например, см. Эту статью на 5NF )
Кэширование промежуточных результатов разрешено даже в нормализованных базах данных и даже для крупнейших евангелистов нормализации - вы можете сделать это на уровне приложений (в качестве некоторого вида кэша) или вы можете сделать это на уровне базы данных, или вы можете иметь хранилище данных для таких целей. Все это правильные варианты и не имеют ничего общего с нормализацией логической модели.
Кроме того, что касается вашего бухгалтера - вы должны быть в состоянии убедить его в том, что он утверждает, что не хороший тест, и разработать набор тестов (возможно, вместе с ним), которые автоматизируют тестирование системы без вмешательства пользователя и дает вам большую уверенность в том, что ваша система не содержит ошибок.
С другой стороны, мне известны системы, которые требуют, чтобы пользователи вводили дублирующую информацию, например, для ввода количества строк в счете-фактуре до или после ввода фактических строк, чтобы гарантировать, что ввод завершен. Эти данные «дублируются», и вам не нужно их хранить, если у вас есть процедура, которая проверит ввод. Если эта процедура появится позже, ей разрешается хранить «денормализованные» данные - опять же, семантика оправдывает это, и вы можете рассматривать модель как нормализованную. (полезно обернуть голову вокруг этой концепции)
EDIT:
Термин «денормализованный» в (2) не является правильным, если вы посмотрите на формальное определение нормальных форм и если вы считаете, что дизайн денормализован, если он нарушает любую из нормальных форм (для некоторых людей это очевидно, и другого пути нет) об этом).
Тем не менее, вы можете привыкнуть к мысли, что многие люди и ненужные ненужные тексты будут использовать термин нормализация для любых попыток уменьшить избыточность в базе данных (в качестве примера вы найдете научную статьи, в которых я не говорю, что они должны быть правы, просто как предупреждение о том, что это часто встречается, называют производные атрибуты формой денормализации, см. здесь ).
Если вы хотите сослаться на некоторые более последовательные и признанные авторитеты (опять же, не признанные всеми), возможно, слова C.J.Date могут провести четкое различие:
Большая часть теории дизайна связана с
сокращение избыточности; нормализацияуменьшает избыточность в пределах relvars, ортогональность уменьшает ее по всем relvars.
цитата из Подробная база данных: реляционная теория для практиков
и на следующей странице
Так же, как неспособность полностью нормализовать подразумевает избыточность и может привести к определенным аномалиям, так и неспособность придерживаться ортогональности.
Итак, подходящий термин для избыточностичерез relvars - ортогональность (в основном все нормальные формы говорят об одном relvar, поэтому, если вы строго посмотрите на нормализацию, она никогда не предложит каких-либо улучшений из-за зависимостей между двумя различными relvars).
В любом случае, одна из других важных концепций, когдавы считаете, что проект базы данных - это также разница между логической и физической моделями баз данных.Многие вещи, которые полезны на физическом уровне, такие как таблицы с промежуточными итогами или индексы, не имеют места в логической модели - где вы пытаетесь установить и исследовать отношения между концепциями, которые вы пытаетесь смоделировать.И именно поэтому вы можете сказать, что они допустимы, и они не портят дизайн.
Линии иногда могут быть немного размытыми, что такое логическая модель и физическая модель.Особенно хорошим примером является таблица с промежуточными итогами.Чтобы считать это частью физической реализации и игнорировать ее на логическом уровне, вы должны:
- гарантировать, что пользователи (и приложения) не смогут напрямую обновить таблицу промежуточных итогов способом, не совместимым с ихпредикат (другими словами, есть ошибка в процедуре подытога)
- гарантирует, что пользователи (и приложения) не смогут обновить таблицу, от которой они зависят, без обновления подытога (другими словами, некоторые приложения не будут удалятьстрока из таблицы сведений без обновления итогов)
Если вы нарушите любое из вышеперечисленных правил, вы получите несовместимую базу данных , которая предоставит противоречивые факты .(В таком случае, если вы хотите формально разработать процедуру для исправления или изучения вызванных проблем, вы не рассматриваете это как просто дополнительную таблицу, она будет существовать на логическом уровне; там, где ее не должно быть).
Кроме того, нормализация всегда зависит от семантики и бизнес-правил, которые вы пытаетесь смоделировать.Например, DBAPerformance приводит пример, в котором сохранение TaxAmount в таблице транзакций не является денормализованным дизайном, но он не упоминает, что это зависит от того, какую систему вы пытаетесь смоделировать (это очевидно?);например, если транзакция имеет другой атрибут с именем TaxRate, он обычно будет денормализован, поскольку существует функциональная зависимость от набора неключевых атрибутов (TaxAmount = Amount * TaxRate => FD: Amount, TaxRate -> TaxAmount) и одиниз них должны быть удалены или гарантированно согласованы.
Очевидно, вы могли бы сказать, но если система, которую вы строите, предназначена для аудиторской компании, то у вас может не быть функциональной зависимости - они могут проверять кого-то, кто использует ручные вычисления или имеет неисправное программное обеспечение или должену вас есть возможность записывать неполные данные, и изначально расчеты могут быть неверными, и, как аудиторская компания, вы должны регистрировать факт, как это произошло.
Таким образом, семантика (предикаты), которые определяются требованиями, будут влиять, если какая-либо из нормальных форм нарушается, - влияя на функциональные зависимости (другими словами, правильное установление функциональных зависимостей является довольно важной частью моделирования, когда вы стремитесь кнормализованная база данных).