Как вы определяете, как далеко нормализовать базу данных?

Question

При создании структуры базы данных, какие руководящие указания следует соблюдать или как определить, насколько далеко следует нормализовать базу данных? Должны ли вы создать ненормализованную базу данных и разделить ее на части по мере продвижения проекта? Стоит ли создавать его полностью нормализованным и комбинировать таблицы, необходимые для производительности?

Answer 1

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

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

Есть пара хороших статей:

http://www.agiledata.org/essays/dataNormalization.html

Answer 2

@ GrizzlyGuru Один мудрец однажды сказал мне "нормализуйся, пока не болит, денормализуй, пока не заработает".

Это меня еще не подвело:)

Я не согласен с тем, чтобы начинать с него в ненормализованной форме, однако, по моему опыту, было легче адаптировать ваше приложение для работы с менее нормализованной базой данных, чем с более нормализованной. Это также может привести к ситуациям, когда он «работает» достаточно хорошо, поэтому вы никогда не сможете его нормализовать (пока не станет слишком поздно!)

Answer 3

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

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

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

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

Answer 4

База данных, нормализующая, я чувствую, является формой искусства.

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

Хорошее практическое правило, которому я следую, - нормализовать одну и ту же информацию, повторяемую снова и снова.

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

Однако, если у вас есть только 2 типа контактов, Деловые или личные, нужна ли вам таблица типов контактов, если вы знаете, что у вас будет только 2? Для меня нет.

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

Пусть тестирование скажет вам, если вам нужно объединить таблицы. Хорошо написанный запрос может покрыть любую чрезмерную нормализацию.

Answer 5

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

Answer 6

Оригинальный плакат никогда не описывал, в какой ситуации будет использоваться база данных. Если это будет проект хранилища данных любого типа, где в какой-то момент вам понадобятся кубы (OLAP), обрабатывающие данные для некоторого внешнего интерфейса, было бы разумнее начать со звездообразной схемы (таблицы фактов + измерение), а не рассматривать нормализация. Книги Кимбалла очень помогут в этом случае.

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Если вы денормализуете, то вам нужно либо согласиться с тем фактом, что вы можете получить аномалии обновления, либо вам нужно самостоятельно выполнить проверку ограничения в коде приложения. Это лишает много преимуществ использования СУБД, которая позволяет декларативно определять эти ограничения.

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

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

Answer 10

Правда в том, что "это зависит". Это зависит от многих факторов, в том числе:

• Код (с ручным кодированием или с приводом от инструмента (например, пакеты ETL))
• Основное приложение (обработка транзакций, хранение данных, отчетность)
• Тип базы данных (MySQL, DB / 2, Oracle, Netezza и т. Д.)
• Архитектура базы данных (табличный, столбчатый)
• Качество DBA (проактивное, реактивное, неактивное)
• Ожидаемое качество данных (хотите ли вы обеспечить качество данных на уровне приложений или базы данных?)