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

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

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

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

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

@GrizzlyGuru Один мудрый человек однажды сказал мне «нормализовать, пока не станет больно, денормализовать, пока не заработает».

Меня это еще не подвело :)

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

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

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

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

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

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

Я считаю, что нормализация баз данных - это искусство.

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

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

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

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

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

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

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

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

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

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

Я согласен с тем, что обычно лучше начать с нормализованной БД, а затем денормализовать для решения очень конкретных проблем, но я бы, вероятно, начал с Нормальная форма Бойса-Кодда вместо 3-ей нормальной формы.

Правда в том, что «это зависит от обстоятельств». Это зависит от множества факторов, в том числе:

• Code (Hand-coded or Tool driven (like ETL packages))
• Primary Application (Transaction Processing, Data Warehousing, Reporting)
• Type of Database (MySQL, DB/2, Oracle, Netezza, etc.)
• Database Architecture (Tablular, Columnar)
• DBA Quality (proactive, reactive, inactive)
• Expected Data Quality (do you want to enforce data quality at the application level or the database level?)

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

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

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

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

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

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

Например, при использовании технологии объектно-реляционного сопоставления у вас будет богатый набор семантики для различных отношений «многие-к-одному» и «многие-ко-многим». Под капотом, который предоставит объединяемые таблицы с двумя первичными ключами. Хотя настоящая нормализация относительно редка, она часто дает вам отношения с 3 или более первичными ключами. В подобных случаях я предпочитаю придерживаться O / R и накатывать свой собственный код, чтобы избежать различных аномалий БД.

Просто постарайтесь руководствоваться здравым смыслом.

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