Что такое нормализация и денормализация

О нормализации и денормализации данных

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

И все вроде бы хорошо: приводи базу как минимум к третьей нормальной форме и будет всем счастье. ) Однако всегда есть НО.

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

Однако в последнее время положение дел стремительно меняется. Предметные области усложняются, количество сущностей, описывающих предметную область, увеличивается, а с применением нормализации, их число возрастает как минимум в 2-3 раза. Объемы хранимой информации постоянно растут, таблицы с десятками и сотнями тысяч записей никого не удивляют. В современных СУБД все больше появляются и активно используются специализированные типы данных (например, универсальные уникальные идентификаторы UUID, xml, json, геометрические типы), которые могут занимать большие объемы памяти. Сами таблицы уже не хранятся в одной папке одного диска, а могут быть распределены по нескольким дискам, находящимся на разных серверах. В результате, выборка и анализ данных из таких таблиц становится уже дорогостоящим занятием. Объединение распределенных таблиц с большим количеством записей и объемными полями может занимать большое количество времени и ресурсов.

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

Важным моментом денормализации является то, что она используется НЕ вместо нормализации, а ПОСЛЕ ее. Здесь нужно найти золотую середину: до каких пор мы можем разбивать данные, чтобы облегчить выполнение команд insert, update и delete, и когда можно допустить некоторую избыточность для ускорения выполнения команды select.

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

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

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

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

В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.

Недавно мы писали об использовании Clojure и MongoDB, а сегодня речь пойдет о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки.

Что такое денормализация?

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

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

Рассмотрим нормализованную модель для простейшей CRM-системы:

Пробежимся по имеющимся здесь таблицам:

• Таблица user_account хранит данные о пользователях, зарегистрированных в приложении (для упрощения модели роли и права пользователей из нее исключены).
• Таблица client содержит некие базовые сведения о клиентах.
• Таблица product — это список предлагаемых товаров.
• Таблица task содержит все созданные задачи. Каждую из них можно представить в виде набора согласованных действий по отношению к клиенту. Для каждой есть список звонков, встреч, предложенных и проданных товаров.
• Таблицы call и meeting хранят данные о заказах и встречах с клиентами и связывают их с текущими задачами.
• Словари task_outcome , meeting_outcome и call_outcome содержат все возможные варианты результата звонков, встреч и задания.
• product_offered хранит список продуктов, которые были предложены клиентам;
• product_sold — продукты, которые удалось продать.
• Таблица supply_order хранит информацию обо всех размещенных заказах.
• Таблица writeoff содержит перечень списанных по каким-либо причинам товаров.

Когда полезно использовать денормализацию

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

1. Сохранение исторических данных. Данные меняются с течением времени, но может быть нужно сохранять значения, которые были введены в момент создания записи. Например, могут измениться имя и фамилия клиента или другие данные о его месте жительства и роде занятий. Задача должна содержать значения полей, которые были актуальны на момент создания задачи. Если этого не обеспечить, то восстановить прошлые данные корректно не удастся. Решить проблему можно, добавив таблицу с историей изменений. В таком случае SELECT-запрос, который будет возвращать задачу и актуальное имя клиента будет более сложным. Возможно, дополнительная таблица — не лучший выход из положения.
2. Повышение производительности запросов. Некоторые запросы могут использовать множество таблиц для доступа к часто запрашиваемым данным. Пример — ситуация, когда необходимо объединить до 10 таблиц для получения имени клиента и наименования товаров, которые были ему проданы. Некоторые из них, в свою очередь, могут содержать большие объемы данных. При таком раскладе разумным будет добавить напрямую поле client_id в таблицу products_sold .
3. Ускорение создания отчетов. Бизнесу часто требуется выгружать определенную статистику. Создание отчетов по «живым» данным может требовать большого количества времени, да и производительность всей системы может в таком случае упасть. Например, требуется отслеживать клиентские продажи за определенный промежуток по заданной группе или по всем пользователям разом. Решающий эту задачу запрос в «боевой» базе перелопатит ее полностью, прежде чем подобный отчет будет сформирован. Нетрудно представить, насколько медленнее все будет работать, если такие отчеты будут нужны ежедневно.
4. Предварительные вычисления часто запрашиваемых значений. Всегда есть потребность держать наиболее часто запрашиваемые значения наготове для регулярных расчетов, а не создавать их заново, генерируя их каждый раз в реальном времени.

Не все так гладко

Очевидная цель денормализации — повышение производительности. Но всему есть своя цена. В данном случае она складывается из следующих пунктов:

• Место на диске. Ожидаемо, поскольку данные дублируются.
• Аномалии данных. Необходимо понимать, что с определенного момента данные могут быть изменены в нескольких местах одновременно. Соответственно, нужно корректно менять и их копии. Это же относится к отчетам и предварительно вычисляемым значениям. Решить проблему можно с помощью триггеров, транзакций и хранимых процедур для совмещения операций.
• Документация. Каждое применение денормализации следует подробно документировать. Если в будущем структура базы поменяется, то в ходе этого процесса нужно будет учесть все прошлые изменения — возможно, от них вообще можно будет к тому моменту отказаться за ненадобностью. (Пример: в клиентскую таблицу добавлен новый атрибут, что приводит к необходимости сохранения прошлых значений. Чтобы решить эту задачу, придется поменять настройки денормализации).
• Замедление других операций. Вполне возможно, что применение денормализации замедлит процессы вставки, модификации и удаления данных. Если подобные действия проводятся относительно редко, то это может быть оправдано. В этом случае мы разбиваем один медленный SELECT-запрос на серию более мелких запросов по вводу, обновлению и удалению данных. Если сложный запрос может серьезно замедлить всю систему, то замедление множества небольших операций не отразится на качестве работы приложения столь драматических образом.
• Больше кода. Пункты 2 и 3 потребуют добавления кода. В то же время они могут существенно упростить некоторые запросы. Если денормализации подвергается существующая база данных, то потребуется модифицировать эти запросы, чтобы оптимизировать работу всей системы. Также понадобится обновить существующие записи, заполнив значения добавленных атрибутов — это тоже потребует написания некоторого количества кода.

Денормализация на примере

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

Что изменилось и почему?

Единственное нововведение в таблице product — строка units_in_stock . В нормализованной модели мы можем вычислить это значение следующим образом: заказанное наименование — проданное — (предложенное) — списанное (units ordered — units sold — (units offered) — units written off). Вычисление повторяется каждый раз, когда клиент запрашивает товар. Это довольно затратный по времени процесс. Вместо этого можно вычислять значение заранее так, чтобы к моменту поступления запроса от покупателя, все уже было наготове. С другой стороны, атрибут units_in_stock должен оновляться после каждой операции ввода, обновления или удаления в таблицах products_on_order , writeoff , product_offered и product_sold .

В таблицу task добавлено два новых атрибута: client_name и user_first_last_name . Оба они хранят значения на момент создания задачи — это нужно, потому что каждое из них может поменяться с течением времени. Также нужно сохранить внешний ключ, который связывает их с исходным пользовательским и клиентским ID. Есть и другие значения, которые нужно хранить — например, адрес клиента или информация о включенных в стоимость налогах вроде НДС.

Денормализованная таблица product_offered получила два новых атрибута: price_per_unit и price . Первый из них необходим для хранения актуальной цены на момент предложения товара. Нормализованная модель будет показывать лишь ее текущее состояние. Поэтому, как только цена изменится, изменится и «ценовая история». Нововведение не просто ускорит работу базы, оно улучшает функциональность. Строка price вычисляет значение units_sold * price_per_unit. Таким образом, не нужно делать расчет каждый раз, как понадобится взглянуть на список предложенных товаров. Это небольшая цена за увеличение производительности.

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

Таблица statistics_per_year (статистика за год) в тестовой модели — абсолютно новый элемент. По сути, это денормализованная таблица, поскольку все ее данные могут быть рассчитаны из других таблиц. Здесь хранится информация о текущих задачах, успешно выполненных задачах, встречах, звонках по каждому заданному клиенту. В данном месте также хранится общая сумма проведенных начислений за каждый год. После ввода, обновления или удаления любых данных в таблицах task , meeting , call и product_sold приходится пересчитывать эти данные для каждого клиента и соответствующего года. Так как изменения, скорее всего, касаются лишь текущего года, отчеты за предыдущие годы теперь могут оставаться без изменений. Значения в этой таблице вычисляются заранее, поэтому мы сэкономим время и ресурсы, когда нам понадобятся результаты расчетов.

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

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

Наш опыт

Мы в Латере много занимаемся оптимизацией производительности нашей биллинговой системы «Гидра», что неудивительно, учитывая объемы наших клиентов и специфику телеком-отрасли.

Один из примеров в статье предполагает создание таблицы с промежуточными итогами для ускорения отчетов. Конечно, самое сложное в этом подходе — поддерживать актуальное состояние такой таблицы. Иногда можно переложить эту задачу на СУБД — например, использовать материализованные представления. Но, когда бизнес-логика для получения промежуточных результатов оказывается чуть более сложной, актуальность денормализованных данных приходится обеспечивать вручную.

«Гидра» имеет глубоко проработанную систему привилегий для пользователей, операторов биллинга. Права выдаются несколькими способами — можно разрешить определенные действия конкретному пользователю, можно заранее подготовить роли и выдать им разные наборы прав, можно наделить определенный отдел специальными привилегиями. Только представьте, насколько медленными стали бы обращения к любым сущностям системы, если бы каждый раз нужно было пройти всю эту цепочку, чтобы убедиться: «да, этому сотруднику разрешено заключать договоры с юридическими лицами» или «нет, у этого оператора недостаточно привилегий для работы с абонентами соседнего филиала». Вместо этого мы отдельно храним готовый агрегированный список действующих прав для пользователей и обновляем его, когда в систему вносятся изменения, способные на этот список повлиять. Сотрудники переходят из одного отдела в другой намного реже, чем открывают очередного абонента в интерфейсе биллинга, а значит вычислять полный набор их прав нам приходится настолько же реже.

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

Другие технические статьи в нашем блоге:

• За и против: Когда стоит и не стоит использовать MongoDB
• Мнение: Почему стоит изучать и использовать Clojure
• DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных
• Архитектура open source-приложений: Как работает nginx
• Как повысить отказоустойчивость биллинга: Опыт «Гидры»

• денормализация
• базы данных
• администрирования

Денормализация БД. Зачем? Когда? Как?

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

Что хотелось понять

• Когда нужна денормализация? Признаки и запахи.
• Как определить, когда денормализация оправдана?
• Как грамотно реализовать денормализацию

Когда нужна денормализация? Признаки и запахи.

Рассмотрим некоторые распространенные ситуации, в которых денормализация может оказаться полезна.

Большое количество соединений таблиц.

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

Расчетные значения.

Зачастую медленно выполняются и потребляют много ресурсов запросы, в которых производятся какие-то сложные вычисления, особенно при использовании группировок и агрегатных функций (Sum, Max и т.п.). Иногда имеет смысл добавить в таблицу 1-2 дополнительных столбца, содержащих часто используемые (и сложно вычисляемые) расчетные данные.
Предположим, что необходимо определить общую стоимость каждого заказа. Для этого сначала следует определить стоимость каждого продукта (по формуле «количество единиц продукта» * «цена единицы продукта» – скидка). После этого необходимо сгруппировать стоимости по заказам.
Выполнение этого запроса является достаточно сложным и, если в базе данных хранятся сведения о большом количестве заказов, может занять много времени. Вместо выполнения такого запроса можно на этапе размещения заказа определить его стоимость и сохранить ее в отдельном столбце таблицы заказов. В этом случае для получения требуемого результата достаточно извлечь из данного столбца предварительно рассчитанные значения.
Создание столбца, содержащего предварительно рассчитываемые значения, позволяет значительно сэкономить время при выполнении запроса, однако требует своевременного изменения данных в этом столбце.

Длинные поля.

Если у нас в базе данных есть большие таблицы, содержащие длинные поля (Blob, Long и т.п.), то серьезно ускорить выполнение запросов к такой таблице мы сможем, если вынесем длинные поля в отдельную таблицу. Хотим мы, скажем, создать в базе каталог фотографий, в том числе хранить в blob-полях и сами фотографии (профессионального качества, с высоким разрешением, и соответствующего размера). С точки зрения нормализации абсолютно правильной будет такая структура таблицы:
ID фотографии
ID автора
ID модели фотоаппарата
сама фотография (blob-поле).
А сейчас представим, сколько времени будет работать запрос, подсчитывающий количество фотографий, сделанных каким-либо автором…
Правильным решением (хотя и нарушающим принципы нормализации) в такой ситуации будет создать еще одну таблицу, состоящую всего из двух полей — ID фотографии и blob-поле с самой фотографией. Тогда выборки из основной таблицы (в которой огромного blob-поля сейчас уже нет) будут идти моментально, ну а когда захотим посмотреть саму фотографию — что ж, подождем…

Как определить, когда денормализация оправдана?

Затраты и выгоды.

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

Частота запросов и устойчивость производительности.

Например, 70% из 1000 запросов, ежедневно генерируемых предприятием, представляют собой запросы уровня сводных, а не детальных данных. При использовании таблицы сводных данных запросы выполняются примерно за 6 секунд вместо 4 минут, т.е. время обработки меньше на 2730 минут. Даже с поправкой на те 105 минут, которые необходимо еженедельно тратить на поддержку таблиц сводных данных, в итоге экономится 2625 минут в неделю, что полностью оправдывает создание таблицы сводных данных. Со временем может случиться так, что большая часть запросов будет обращена не к сводным данным, а к детальным данным. Чем меньше число запросов, использующих таблицу сводных данных, тем проще от нее отказаться, не затрагивая другие процессы.

Прочее

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

Как грамотно реализовать денормализацию.

Сохранить детальные таблицы

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

Использование триггеров

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

Программная поддержка

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

Резюме

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

Денормализация базы данных

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

Нормализация базы данных

В предыдущих материалах мы подробно рассмотрели нормализацию базы данных и каждую нормальную форму базы данных, вот соответствующие статьи:

• Ненормализованная форма или нулевая нормальная форма (UNF)
• Первая нормальная форма (1NF)
• Вторая нормальная форма (2NF)
• Третья нормальная форма (3NF)
• Нормальная форма Бойса-Кодда (BCNF)
• Четвертая нормальная форма (4NF)
• Пятая нормальная форма (5NF)
• Доменно-ключевая нормальная форма (DKNF)
• Шестая нормальная форма (6NF)

Сегодня мы с Вами поговорим об обратном процессе, т.е. о денормализации.

Денормализация

Ранее мы выяснили, что данные в базе данных хранятся в таблицах, иными словами, база данных – это набор таблиц.

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

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

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

Иными словами, нормализация — это не процесс целенаправленного приведения базы данных к какой-то определенной нормальной форме, нормализация – это набор принципов, зная и следуя которым, мы можем спроектировать базу данных, структура которой будет гарантировать нам отсутствие определенного рода аномалий.

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

Максимально нормализованная база данных – это плохая база данных.

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

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

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

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

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

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

Методика нормализации базы данных

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

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

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

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

И таким образом, Вы выполняете денормализацию.

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

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

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

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

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

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

Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней язык SQL рассматривается как стандарт, чтобы после прочтения данной книги можно было работать с языком SQL в любой системе управления базами данных.

На сегодня это все, надеюсь, материал был Вам полезен и интересен, пока!