Overnormalization

Question

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

Answer 1

В общем смысле, я думаю, что сверхнормализация - это когда вы делаете так много JOIN для извлечения данных, что это вызывает заметные потери производительности и взаимоблокировки в вашей базе данных, даже после того, как вы отключили свои индексы. Очевидно, что для огромных приложений и сайтов, таких как MySpace или eBay, ненормализация является требованием масштабирования.

Как разработчик для нескольких малых предприятий, я говорю вам, что по моему опыту всегда было легче перейти от нормализованного -> денормализованного, чем наоборот, и на самом деле все было наоборот (чтобы избежать дублирования данных сейчас что бизнес-требования изменились через год или около того) гораздо сложнее.

Когда я читаю общие утверждения, такие как «вы должны поместить адрес в таблицу ваших клиентов вместо отдельной таблицы адресов, чтобы вы могли избежать объединения», я содрогаюсь, потому что вы просто знаете, что через год кто-то спросит Вы должны делать что-то с адресами, которые вы совершенно не предвидели, например, вести журнал аудита или хранить несколько клиентов. Если ваша база данных позволяет вам создавать индексированное представление, вы можете обойти эту проблему, пока не достигнете точки, в которой ваш набор данных настолько велик, что он не может существовать или обслуживаться одним сервером или набором серверов в 1- пишите, много читайте. Для большинства из нас я не думаю, что такой сценарий случается очень часто.

В случае сомнений, я стремлюсь к третьей нормальной форме с некоторыми исключениями (например, наличие поля, содержащего CSV-список разделенных строк, потому что я знаю, что никогда не посмотрю на данные с другой стороны). Когда мне нужно будет объединиться, я сначала посмотрю на свои представления или индексы. Надеюсь, это поможет.

Answer 2

Это всегда вопрос домена приложения. Обычно это вопрос правильности, но иногда вопрос производительности.

В одном случае я могу вспомнить случай чрезмерной нормализации prima facie: скажем, у вас есть элемент order + orderitem, и элемент order ссылается на productID и оставляет цены на product.price. Поскольку это вводит временную связь, вы неправильно нормализовали, потому что чрезмерная нормализация влияет на уже отправленные заказы, если цены не изменяются абсолютно. Вы, конечно, можете утверждать, что это просто ошибка моделирования (как в комментариях), но я вижу недостаточную нормализацию как ошибку моделирования и в большинстве случаев.

Другая категория связана с производительностью. В принципе, я думаю, что в целом решения для производительности лучше, чем для денормализации данных, таких как материализованные представления, но если ваше приложение страдает от последствий для многих объединений, возможно, стоит оценить, может ли денормализация помочь вам. Я думаю, что эти случаи часто переоцениваются, потому что люди иногда пытаются денормализовать, прежде чем они должным образом профилируют свою заявку.

Люди также часто забывают об альтернативах, таких как сохранение канонической формы базы данных и использование хранилищ или других стратегий для часто читаемых, но редко изменяемых данных.

Answer 3

Нормализация является абсолютной. База данных следует нормальным формам или нет. Есть полдюжины нормальных форм. Главным образом, у них есть имена, как с первого по пятый. Плюс есть нормальная форма Бойса-Кодда.

Нормализация существует только с одной целью - предотвратить "аномалии обновления".

Нормализация не субъективна. Это не суждение. Каждая таблица и взаимосвязь между таблицами либо соответствует, либо не соответствует обычной форме.

Следовательно, вы не можете быть "чрезмерно нормализованными" или "недостаточно нормализованными".

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

Распространенной ошибкой является разрыв 2NF и дублирование функциональной зависимости между ключом и неключевым значением. Это требует дополнительных обновлений или, что еще хуже, запускает параллельные копии.

Денормализация транзакционной базы данных должна быть индивидуальной.

Хранилище данных также редко следует каким-либо из правил нормализации транзакций, поскольку оно (по сути) никогда не обновляется.

«Чрезмерная нормализация» может означать, что база данных слишком медленная из-за большого количества объединений. Это также может означать, что база данных переросла оборудование. Или что приложения не были разработаны для масштабирования.

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

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

Answer 4

Когда стоимость производительности превышает выгоду по отношению к предполагаемой цели приложения.

Answer 5

Нормализуйте базы данных OLTP и денормализуйте базы данных OLAP. У каждого есть миссия, которая диктует свою схему. Подобно нормализованным базам данных транзакций, хранилища данных существуют по определенной причине. Полная система нуждается в обоих.

Answer 6

Многие люди говорят о производительности. Я думаю, что ключевым вопросом является гибкость. В целом, чем более нормализована ваша база данных, тем она более гибкая.

В настоящее время мы используем «чрезмерно нормализованную» базу данных, поскольку в нашей операционной среде требования клиентов меняются ежемесячно. Путем «чрезмерной нормализации» мы можем соответствующим образом адаптировать наше программное обеспечение, не меняя структуру базы данных.

Answer 7

Третья нормальная форма ( 3NF ) считается оптимальным уровнем нормализации для многих рациональных приложений баз данных. Это состояние, в котором , как Билл Кент однажды суммировал , каждое "неключевое поле [в каждой таблице в конкретной системе управления реляционными базами данных или СУБД] должно предоставлять факт о ключ, весь ключ и ничего, кроме ключа. " 3NF - это термин, который был введен EF Codd , изобретателем реляционной модели для управления базами данных. Как правило, данные, от которых зависит программное приложение, особенно приложение, используемое для онлайновой системы обработки транзакций (OLTP), будут хорошо стоить в 3NF. Эта нормальная форма по определению уменьшает размер базы данных, вызывая минимальное повторение данных строки / столбца, и максимизирует эффективность запросов и простоту обслуживания приложений. 3NF достигает того, что требует, чтобы таблицы базы данных (т. Е. Ее схема) были разбиты на отдельные таблицы, связанные первичными / внешними ключами - в основном до тех пор, пока правило Кента не будет выполнено (ну, я изложил это так для простоты чтения, но фактическое определение 3NF гораздо более детально). Напротив, сверхнормализация подразумевает увеличение количества соединений, необходимых в запросе между связанными таблицами. Это происходит в результате разбиения схемы базы данных на гораздо более детальный уровень, чем 3NF. Однако, хотя нормализацию после 3-й степени часто можно считать чрезмерной, отрицательная коннотация термина «чрезмерная нормализация» иногда может быть необоснованной. Чрезмерная нормализация может быть желательна в некоторых приложениях, которые по своей конструкции требуют 4NF (и выше) из-за сложности и универсальности прикладного программного обеспечения. Примером этого является настраиваемая и расширяемая коммерческая программа базы данных для некоторой отрасли, в которой она продается конечным пользователям, которым требуется открытый API. Но тогда может быть желательным и обратное, то есть денормализация, особенно при разработке базы данных Online Analytical Processing (OLAP), используемой строго для суммирования данных из базы данных OLTP только для запросов / отчетов - таких как данные склад. В этом случае данные должны обязательно находиться в сильно денормализованном формате (т.е. 1NF или 2NF). Часто под этими ограничениями - когда предъявляются высокие требования к эффективным запросам и отчетам - мы находим разработчиков баз данных и приложений, называющих базу данных, «чрезмерно нормализованными». Но, как однажды Тони Дэвис из Redgate сказал - принимая во внимание гораздо более совершенные и эффективные системы управления базами данных и системы хранения данных, - «снижение производительности от нескольких объединений в запросе незначительно. Если ваша база данных работает медленно, это не потому, что оно «слишком нормализовано»! Итак, в заключение, эта характеристика - сверхнормализация - не является абсолютной и зависит от способа ее использования в приложении. По словам Кента , " Правила нормализации предназначены для предотвращения аномалий обновления и несоответствий данных ... [но] нет необходимости полностью нормализовать все записи, когда принимаются во внимание фактические требования к производительности. ... Нормализованный дизайн повышает целостность данных, сводя к минимуму избыточность и несогласованность, но при некоторых возможных затратах производительности для определенных поисковых приложений ... [Таким образом] желательность нормализации должна оцениваться с точки зрения ее влияния на производительность на поисковых приложениях."

Answer 8

Мой взгляд на это:

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

Тогда начинается настоящая работа: Денормализация. Здесь вы решите, что, по вашему мнению, было бы проблематично реализовать и / или замедлило бы запросы из-за слишком большого количества соединений.

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

Редактировать: Документация! Я забыл упомянуть, что документирование де-нормализации очень важно. Чрезвычайно полезно, когда вы принимаете проект, узнать причину выбора.

Answer 9

.. или ограничение количества соединений, которое будет выполнять ваша СУБД.

Answer 10

По моему опыту, я никогда не видел нормализованную базу данных, содержащую почтовые адреса, поскольку обычно приемлемо хранить адрес в виде строки. В идеале должны быть таблицы для стран, округов / штатов, городов, районов и улиц. Я не сталкивался ни с кем, кто должен отчитываться на уровне улицы, поэтому в этом не было необходимости. Адреса используются только для почтовых контактов, поэтому рассматриваются как единое целое.