22
Когда дизайн базы данных будет описан как переопределенный? Является ли эта характеристика абсолютной? Или это зависит от того, как он используется в приложении? Благодарю.Overnormalization
A
ответ
4
Когда стоимость исполнения превышает выгоду по назначению приложения.
25
В общем смысле, я считаю, что чрезмерно нормировано, когда вы делаете так много JOINs, чтобы извлекать данные, которые вызывают заметные штрафы за производительность и взаимоблокировки в вашей базе данных, даже после того, как вы настроили вывод из своих индексов. Очевидно, что для огромных приложений и сайтов, таких как MySpace или eBay, де-нормализация является требованием масштабирования.
Как разработчик для нескольких малых предприятий, я рассказываю вам, что по моему опыту всегда было легче перейти от нормализованного -> денормализованного, а не наоборот - и наоборот - наоборот (во избежание дублирования данных теперь, когда требования к бизнесу изменились примерно через год) намного сложнее.
Когда я читаю общие утверждения, такие как «вы должны поместить адрес в таблицу ваших клиентов вместо отдельной таблицы адресов, чтобы вы могли избежать объединения», я содрогаюсь, потому что вы просто знаете, что через год кто-то собирается попросите вас сделать что-то с адресами, которые вы полностью не предвидели, например, поддержание контрольного журнала или хранение нескольких клиентов. Если ваша база данных позволяет вам создавать индексированное представление, вы можете обойти эту проблему, пока не дойдете до такой степени, когда ваш набор данных настолько велик, что он не может существовать или обслуживаться одним сервером или набором серверов в 1- пишите, много читайте. Для большинства из нас, я не думаю, что сценарий случается очень часто.
В случае сомнений, я направляюсь к третьей нормальной форме с некоторыми исключениями (например, имея поле содержит CSV-список разделенных строк, потому что я знаю, что никогда не буду смотреть на данные с другого угла). Когда мне нужно консолидироваться, я сначала посмотрю на свои взгляды или индексы. Надеюсь это поможет.
+0
Вы должны стремиться, по крайней мере, к BCNF (в основном версия 3NF, которая устраняет краевой случай, который не используется официальным 3NF), и очень часто вы обнаружите, что данные фактически находятся в 5NF в этом месте. – 2008-11-16 04:58:27
+0
Стоит отметить, что с SQL Server 2005 вы можете использовать Inline-Table-Valued-Functions (ITVF). Вы можете присоединиться к ним, как таблица, и передать несколько параметров. Может показаться слишком сложным предположить, что вы даже можете запросить из представления и обслуживать его в ITVF, но если вы снова и снова используете одни и те же параметры и присоединяетесь к нескольким sprocs, тогда может иметь смысл инкапсулировать его в призыв к ITVF. – MikeTeeVee 2012-02-15 17:45:51
+1
@JonathanLeffler Каждая БД отличается, поэтому правило, «всегда нацеленное на BCNF», противопоказано. Нормализация имеет преимущества, но она также может иметь недостатки. Знаете ли вы, что в вставке тяжелая среда, вставляемая в индексированные столбцы, может иметь значительное ограничение производительности (не хотите присоединяться без индекса) в зависимости от типа индекса? Кроме того, объединение не является свободной операцией, поэтому, если вы присоединяетесь к 1 таблице, чтобы получить подмножество другого и так далее по цепочке 8, производительность соединения может добавить некоторые неприятные накладные расходы для больших таблиц (> 100M записей). Иногда денормализация имеет преимущества. – hsanders 2012-12-04 15:22:24
14
Это всегда вопрос о домене приложения. Обычно это вопрос правильности, но иногда вопрос производительности.
Существует один случай, когда я могу представить пример prima facie overnormalization: скажем, у вас есть заказ + orderitem, а orderitem ссылается на productID и оставляет цены на товар. Поскольку это вводит временную связь, вы неправильно нормализовались, потому что чрезмерная нормировка влияет на уже отправленные заказы, если цены абсолютно не меняются. Вы, конечно же, можете утверждать, что это просто ошибка моделирования (как в комментариях), но в большинстве случаев я вижу недостаточную нормировку как ошибку моделирования.
Другая категория - характеристики, связанные с производительностью. В принципе, я думаю, что в целом есть лучшие решения для производительности, чем денормализация данных, таких как материализованные представления, но если ваше приложение страдает от последствий для производительности многих подключений, возможно, стоит оценить, может ли денормализация помочь вам. Я думаю, что эти случаи часто чрезмерно подчеркиваются, потому что люди иногда достигают денормализации, прежде чем они должным образом профилируют свое приложение.
Люди также часто забывают об альтернативах, таких как сохранение канонической формы базы данных и использование складирования или других стратегий для часто читаемых, но редко изменяемых данных.
+1
Временная связь - хороший момент, и это то, что легко пропустить до 30 дней после того, как ваша реализация идет вживую. Не то чтобы я был там. – 2008-11-15 17:49:25
1
10
Нормализация является абсолютным. База данных следует за нормальными формами, или нет. Есть полдюжины нормальных форм. В основном, у них есть имена, такие как от первого до пятого. Плюс есть нормальная форма Boyce-Codd.
Нормализация существует только для одной цели - предотвратить «аномалии обновления».
Нормализация не является субъективной. Это не суждение. Каждая таблица и отношения между таблицами либо выполняются, либо не соответствуют нормальной форме.
Следовательно, вы не можете быть «чрезмерно нормализованным» или «недостаточно нормализованным».
Сказав это, нормализация имеет стоимость исполнения. Некоторые люди предпочитают денормализовать различными способами, чтобы улучшить производительность. Наиболее распространенной разумной денормализацией является разрыв 3NF и включение полученных данных.
Общей ошибкой является разрыв 2NF и дублирование копии функциональной зависимости между ключом и неключевым значением. Это требует дополнительных обновлений или, что еще хуже, триггеров для параллельного копирования копий.
Денормализация транзакционной базы данных должна быть в каждом конкретном случае.
Хранилище данных также редко следует каким-либо правилам транзакционной нормализации, поскольку оно (по существу) никогда не обновляется.
«Over-normization» может означать, что база данных слишком медленная из-за большого количества объединений. Это также может означать, что база данных переросла аппаратное обеспечение. Или что приложения не предназначены для масштабирования.
Наиболее распространенная проблема заключается в том, что люди пытаются использовать транзакционную базу данных для отчетности во время транзакций. Блокировка транзакций мешает отчетности.
«Под нормализацией», однако, означает, что существуют нарушения NF, и ненужная обработка выполняется для обработки реплицированных данных и исправления аномалий обновлений.
1
Мое мнение по этому вопросу:
Всегда нормализуют столько, сколько вы в состоянии сделать. Я обычно схожу с ума от нормализации и пытаюсь разработать что-то, что может обрабатывать все мыслимые будущие расширения. То, что я получаю, - это дизайн базы данных, который является чрезвычайно гибким ... и невозможно реализовать.
Затем начинается настоящая работа: де-нормализация. Здесь вы решаете то, что, как вам известно, было бы проблематичным для реализации и/или замедляло бы запросы из-за слишком большого количества объединений.
Таким образом, вы знаете, что скарифицируете, чтобы использовать дизайн.
Редактировать: Документация! Я забыл упомянуть, что документирование де-нормализации очень важно. Это чрезвычайно полезно, когда вы берете на себя проект, чтобы узнать причину выбора.
0
Если на производительность влияет слишком много объединений, создание де-нормированных таблиц для целей отчетности может ускорить процесс. Скопировав данные в новые таблицы, можно будет запускать отчеты без каких-либо объединений.
0
По моему опыту, я никогда не видел нормализованную базу данных, содержащую почтовые адреса, так как обычно принято хранить адрес в виде строки. В идеале, были бы таблицы для стран, уездов/штатов, городов, районов и улиц. Я не встречал никого, кто должен был сообщить об уровне улицы, поэтому он не был необходим. Адреса используются только для почтового контакта, поэтому они рассматриваются как единое целое.
3
Многие люди говорят о производительности. Я думаю, что ключевой проблемой является гибкость. В целом, чем более нормализована ваша база данных, тем она более гибкая.
В настоящее время мы используем «перенастроенную» базу данных, так как в нашей операционной среде требования клиентов меняются ежемесячно. Под «нормализацией» мы можем соответствующим образом адаптировать наше программное обеспечение, не меняя структуру базы данных.
2
Нормализовать базы данных OLTP и денормализовать базы данных OLAP. У каждой есть миссия, которая диктует свою схему. Подобно нормализованным базам транзакций, хранилища данных существуют по какой-то причине. Полная система требует и того, и другого.
0
Третья нормальная форма (3NF) считается оптимальным уровнем нормализации для многих приложений с рациональной базой данных. Это состояние, в котором as Bill Kent once summarized, каждое «» «не-ключевое поле [в каждой таблице в конкретной системе управления реляционными базами данных или РСУБД] должно обеспечивать факт о ключе, ключе целиком и ничего, кроме ключа. " 3NF - это термин, который был introduced by E.F. Codd, изобретателем реляционной модели для управления базой данных. Как правило, данные, которые зависит от программного приложения, особенно приложение, используемое для системы онлайн-обработки транзакций (OLTP), будут хорошо работать в 3NF. Эта нормальная форма по определению уменьшает размер базы данных, вызывая минимальное повторение данных строки/столбца и максимизирует эффективность запросов и простоту обслуживания приложений. 3NF достигает этого, требуя, чтобы таблицы базы данных (т. Е. Ее схема) были разбиты на отдельные таблицы, связанные с первичными/внешними ключами - в основном до тех пор, пока правило Кента не будет истинным (ну, я сказал это таким образом для удобства чтения, но фактическое определение 3NF гораздо более подробно, чем это). Напротив, переоценка подразумевает увеличение количества соединений, необходимых в запросе между связанными таблицами. Это происходит в результате разрушения схемы базы данных на гораздо более узкий уровень, чем 3NF. Однако, хотя нормализация, прошедшая 3-ю степень, часто может считаться чрезмерной нормой, отрицательная коннотация термина «чрезмерная нормировка» иногда может быть необоснованной. В некоторых приложениях может потребоваться чрезмерная нормировка, которая по дизайну требует 4NF (и за ее пределами) из-за сложности и универсальности прикладного программного обеспечения. Примером этого является очень настраиваемая и расширяемая программа коммерческих баз данных для какой-либо отрасли, в которой она продается конечным пользователям, требующим открытого API. Но тогда и наоборот может быть желательным - т. Е. Денормализация - в первую очередь при разработке базы данных Online Analytical Processing (OLAP), используемой строго для суммирования данных из базы данных OLTP только для запросов/отчетов - таких как данные склад. В этом случае данные должны по необходимости находиться в сильно денормализованном формате (то есть 1NF или 2NF). Часто под этими ограничениями - когда есть высокие требования к эффективному запросу и отчетности, - мы находим, что программисты баз данных и приложений, вызывающие базу данных, «переопределены». Но как Redgate's Tony Davis once said - принимая во внимание сегодняшнее гораздо более совершенное и эффективное программное обеспечение и системы хранения баз данных - «производительность, вызванная несколькими объединениями в запросе, ничтожна. Если ваша база данных работает медленно, это происходит не потому, нормализуется!» Итак, в заключение, эта характеризация - сверхнормализация - не является абсолютной, и она зависит от того, как она используется в приложении. In Kent's words, «Правила нормализации предназначены для предотвращения аномалий обновлений и несогласованности данных. [Но] нет обязательства полностью нормализовать все записи, когда учитываются фактические требования к производительности ... Нормализованный дизайн повышает целостность данных, минимизируя избыточность и несогласованность, но при некоторых возможных эксплуатационных расходах для некоторых поисковых приложений ... [Таким образом, желательность нормализации должна оцениваться с точки зрения ее влияния на результаты поиска. «
I всегда нравилась фраза «Нормализовать», пока это не повредит, не денормализовать, пока она не сработает ». :) – vfilby 2008-11-15 18:32:37
Точно - идеальный баланс. – 2008-11-16 01:35:22
Очень приятное заявление vfilby.Он суммирует мой комментарий ниже в одном ясном и простом предложении. :) – Eigir 2008-11-16 16:35:29