Overnormalization

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

"Over-normization" может означать, что база данных слишком медленная из-за большого количества объединений. Это также может означать, что база данных переросла аппаратное обеспечение. Или что приложения не предназначены для масштабирования.

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

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

Ответ 4

Когда стоимость исполнения превышает выгоду по назначению, предназначенному для применения.

Ответ 5

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

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

Ответ 6

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

Ответ 7

.. или лимит на количество подключений к вашей РСУБД.

Ответ 8

Мое занятие:

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

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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