Что касается баз данных, то "Нормализовать для правильности, денормализовать для выполнения" правильную мантру?

Ответ 1

Две наиболее распространенные причины денормализации:

• Производительность
• Незнание

Первое должно быть проверено с профилированием, в то время как последнее должно быть исправлено с помощью свернутой газеты; -)

Я бы сказал, что лучшая мантра будет "нормализовать для правильности, денормализовать скорость - и только при необходимости"

Ответ 2

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

Люди базы данных обучаются тому, что целостность данных является первостепенной проблемой. Нам нравится думать о 100% -ной правильности данных, так что, как только данные будут в БД, вам не нужно думать или иметь дело с тем, что это логично неправильно. Эта школа мышления имеет большое значение для нормализации, потому что она вызывает (усиливает) команду, чтобы справиться с лежащей в основе логикой данных и системы. Рассмотрим тривиальный пример: есть ли у клиента только одно имя и адрес, или у него может быть несколько? Кто-то должен решить, и система будет зависеть от того, чтобы это правило применялось последовательно. Это звучит как простая проблема, но умножьте эту проблему на 500x, поскольку вы разрабатываете достаточно сложную систему, и вы увидите проблему - правила не могут существовать только на бумаге, они должны быть соблюдены. Хорошо нормализованный дизайн базы данных (с дополнительной помощью ограничений уникальности, внешних ключей, проверочных значений, триггеров логики и т.д.) Может помочь вам иметь четко определенную модель данных ядра и правила правильности данных, что действительно важно, если вы хотите, чтобы система работала так, как ожидалось, когда многие люди работают в разных частях системы (разные приложения, отчеты, что угодно) и разные люди работают в системе с течением времени. Или, говоря иначе, если у вас нет возможности определить и оперативно применять надежную базовую модель данных, ваша система будет сосать.

Другие люди (зачастую, менее опытные разработчики) этого не видят. Они видят в базе данных, в лучшем случае, инструмент, который порабощает приложение, которое они разрабатывают, или, в худшем случае, бюрократию, которой следует избегать. (Обратите внимание, что я говорю "менее опытные" разработчики. Хороший разработчик будет иметь такое же понимание необходимости в твердой модели данных и правильности данных как человек базы данных. Они могут отличаться тем, что лучший способ достичь этого, но по моему опыту разумно открыты для выполнения этих вещей в уровне БД, если команда БД знает, что они делают, и может реагировать на разработчиков). Эти менее опытные люди часто являются теми, кто настаивает на денормализации, как более или менее оправдание для быстрой и грязной работы по проектированию и управлению моделью данных. Таким образом, вы получаете таблицы базы данных, которые составляют 1:1, с экранами приложений и отчетами, каждый из которых отражает различные допущения разработчика, а также полное отсутствие разумности/согласованности между таблицами. Я пережил это несколько раз в своей карьере. Это неутешительный и глубоко непродуктивный способ разработки системы.

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

Сказав это, более прямой ответ на исходный вопрос:)

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

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

Завершите свою базовую модель данных, прежде чем перейти к расширенной модели данных. Используйте его и посмотрите, как далеко вы можете с ним справиться. В зависимости от объема данных, количества пользователей и моделей использования вам может не понадобиться расширенная модель данных. Посмотрите, как далеко вы можете получить индексирование, а также 1,001, связанные с производительностью, которые вы можете включить в свою СУБД.

Если вы действительно используете возможности управления производительностью своей СУБД, вам необходимо взглянуть на расширение вашей модели данных таким образом, чтобы добавить денормализацию. Обратите внимание, что речь идет не о денормализации основной модели данных, а о добавлении новых ресурсов, которые обрабатывают данные денорма. Например, если есть несколько огромных запросов, которые подавляют вашу производительность, возможно, вам захочется добавить несколько таблиц, которые прекомпилируют данные, которые будут создаваться этими запросами, - по существу, предварительный запрос. Важно сделать это таким образом, чтобы поддерживать согласованность денормализованных данных с основными (нормализованными) данными. Например, в СУБД, которые их поддерживают, вы можете использовать МАТЕРИАЛИЗИРОВАННЫЙ ПРОСМОТР, чтобы автоматизировать сохранение данных денорма. Если ваша СУБД не имеет этого параметра, возможно, вы можете сделать это, создав триггеры в таблицах, где существуют базовые данные.

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

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

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

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

Ответ 3

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

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

Или "денормализовать только тогда, когда руководство отправляет вам электронное письмо, которое освобождает вас от беспорядка, который будет создан".

Конечно, это предполагает, что вы уверены в своих способностях и ценности для компании.

Ответ 4

Мантры почти всегда упрощают свой предмет. Это пример.

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

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

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

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

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

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

В целом, многие люди, проектирующие звездные схемы, строят вторичную базу данных, которая не взаимодействует с прикладными программами OLTP. Одной из труднейших проблем в поддержании такой базы данных является так называемая обработка ETL (Extract, Transform и Load). Хорошей новостью является то, что вся эта обработка может быть собрана в нескольких программах, а программистам приложений, которые работают с нормализованной базой данных OLTP, не нужно изучать этот материал. Есть инструменты для помощи в ETL, и копирование данных из нормализованной базы данных OLTP в карту или хранилище данных схемы звездочек является хорошо понятным случаем.

После того, как вы построили звездообразную схему, и если вы правильно выбрали свои измерения, разумно определили свои столбцы и особенно выбрали свою гранулярность, используя эту звездную схему с инструментами OLAP, такими как Cognos или Business Objects, оказывается почти таким же легко играть в видеоигру. Это позволяет аналитикам данных сосредоточиться на анализе данных, а не на том, как работает контейнер данных.

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

Ответ 5

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

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

Ответ 6

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

Удачи!

Ответ 7

Нормализация базы данных не только для теоретической корректности, но и для предотвращения повреждения данных. Я, конечно, НЕ денормализовал бы "простоту", как предлагает @aSkywalker. Фиксация и очистка поврежденных данных не является чем-то простым.

Ответ 8

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

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

Ответ 9

Вы не нормализуетесь для "правильности" как таковой. Вот что:

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

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

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

Ответ 10

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

Ответ 11

Денормализованные данные гораздо чаще встречаются в местах, где недостаточно нормализации.

Моя мантра "нормализуется для правильности, исключаю для производительности". RDBM - очень гибкие инструменты, но оптимизированы для OLTP-ситуации. Замена RDBMS на что-то более простое (например, объекты в памяти с журналом транзакций) может многое помочь.

Ответ 12

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

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

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

Если вы посмотрите на компромисс между идеальным размером объекта на стороне программирования вещей и размером объекта, который является результатом нормализации вашей базы данных, я дам кивку тем, кто сказал бы, что часто лучше выбирать на основе в базе данных, а затем обойти этот выбор в коде. Тем более, что у вас есть возможность в некоторых случаях создавать объекты из объединений с спящим режимом и подобные технологии. Однако я бы не стал говорить, что это абсолютное правило. Любой слой OR-Mapping написан с идеей сделать самые сложные случаи проще, возможно, за счет добавления сложности к самым простым случаям. И помните, что сложность не измеряется в единицах размера, а скорее в единицах сложности. Там есть всевозможные системы. Ожидается, что некоторые из них вырастут до нескольких тысяч строк кода и останутся там навсегда. Другие должны быть центральным порталом для данных компании и теоретически могут развиваться в любом направлении без ограничений. Некоторые приложения управляют данными, которые читаются миллионы раз для каждого обновления. Другие управляют данными, которые читаются только для аудиторских и специальных целей. В общем правила следующие:

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

• Обновление или выбор из одной таблицы обычно проще, чем работа с несколькими таблицами, однако с хорошо написанным OR эта разница может быть сведена к минимуму для большей части пространства модели данных. Работая с прямым SQL, это почти тривиально, чтобы обойтись для индивидуального использования, хотя и не в объектно-ориентированном виде.

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

В сложных иерархиях объектов есть сложности, которые вы не видите на стороне базы данных, например, каскадирование обновлений. Если вы моделируете реляционные внешние ключи и перекрестные ссылки с отношением владения объектами, то при обновлении объекта вы должны решить, следует ли каскадировать обновление или нет. Это может быть более сложным, чем в sql из-за различия между выполнением чего-то и выполнением чего-то правильно всегда, как разница между загрузкой файла данных и написанием синтаксического анализатора для этого типа файла. Код, который каскадирует обновление или удаление в С++, java или что-то еще, должен будет принять решение правильно для разных сценариев, а последствия ошибок в этой логике могут быть довольно серьезными. Остается доказать, что это никогда не может быть упрощено с небольшой гибкостью на стороне SQL, чтобы сделать любые сложности sql стоящими.

Существует также точка, заслуживающая разграничения с одной из нормативных положений. Центральным аргументом для нормализации в базах данных является идея о том, что дублирование данных всегда плохое. Это часто верно, но не может быть соблюдено рабски, особенно когда есть разные владельцы для разных частей решения. Я видел ситуацию, когда одна группа разработчиков управляла определенным типом транзакций, а другая группа разработчиков поддерживала аудитоспособность этих транзакций, поэтому вторая группа разработчиков написала сервис, который очищал несколько таблиц всякий раз, когда произошла транзакция, и создала денормализованную в действительности, то, что было состоянием системы в момент транзакции. Этот сценарий является интересным прецедентом (для части дублирования данных по крайней мере), но на самом деле это часть более широкой категории проблем. Желания, связанные с постоянством данных, часто создают определенные ограничения на структуру данных в базе данных, которые могут упростить обработку ошибок и устранение неполадок, делая некоторые из неправильных случаев невозможными. Однако это может также повлиять на "замораживание" частей данных, поскольку изменение этого подмножества данных приведет к тому, что прошлые транзакции станут недействительными в соответствии с правилами согласованности. Очевидно, для сортировки требуется какая-то система управления версиями, поэтому очевидный вопрос заключается в том, следует ли использовать нормализованную систему управления версиями (время действия и время истечения) или подход на основе снимка (значение времени транзакции). Для нормализованной версии есть несколько вопросов внутренней структуры, о которых вам не нужно беспокоиться при подходе к снимкам, например:

• Можно ли эффективно выполнять запросы диапазона дат даже для больших таблиц?
• Можно ли гарантировать отсутствие перекрытия диапазонов дат?
• Можно ли отслеживать события статуса для оператора, транзакции или причины изменения? (возможно, да, но это дополнительные накладные расходы)
• Создав более сложную систему управления версиями, задаете ли вы правильные владельцы правильных данных?

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

Ответ 13

Система отчетности и система транзакций имеют разные требования.

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

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

Ответ 14

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