Плюсы
Нормализация не является обязательной, но приносит следующие преимущества:
— упрощается процесс выборки. Речь идет об упрощении работы по составлению запросов, то есть пользователь сможет получать нужную информацию относительно простыми запросами;
— обеспечивается целостность данных. Можно говорить о минимизации искажения информации и снижении вероятности потери данных;
— улучшается масштабируемость. При соблюдении правил нормализации формируются благоприятные предпосылки к росту БД;
— отсутствует избыточность (data redundancy). Избыточность — известная проблема непродуктивного использования свободного места на жестком диске, затрудняющая обслуживание БД. В отдельных случаях эту проблему усугубляет и то, что в случае необходимости изменения записей однотипных данных, хранимых в нескольких местах (таблицах), пользователю придется вносить требуемые изменения везде, что весьма трудоемкое занятие. Гораздо проще сделать так, чтобы, к примеру, данные о городах хранились только в таблице Cities и нигде больше. Если подытожить вышесказанное, избыточность предполагает дублирование данных, а это не только усложняет работу с БД, но и увеличивает ее размер;
— отсутствие несогласованных зависимостей. Несогласованные зависимости затрудняют доступ к данным, ведь путь к такой информации может быть неправилен и нелогичен. В той же таблице Cities логично искать города, количество жителей и т. п., но не адреса и имена жителей — для этой информации уже нужна другая таблица — Citizens.
3НФ – третья нормальная форма
Третья нормальная форма (3НФ) означает, что выполнены требования 2НФ, при этом в между атрибутами отношения нет транзитивных зависимостей.
Что такое транзитивная зависимость легко понять на примере уже упоминавшейся выше таблицы продаж — типичного примера ассоциативной таблицы.
Предположим, что продажа каждой товарной позиции имеет своим основанием документ (заказ, счёт и т.д.), а её стоимость характеризуется ценой, количеством и валютой. В этом случае имеем следующие зависимости между атрибутами (колонками):
- «Идентификатор продажи» => «Номер документа»
- «Идентификатор продажи» => «Код валюты»
- «Номер документа» => «Код валюты»
Эти зависимости транзитивны: каждая продажа однозначно определяет свой документ-основание и расчётную валюту, однако, валюта определяется ещё и документом.
Результатом нарушения 3НФ является избыточность хранения и необходимость обновления данных в связанной таблице. Так, если вы оставите колонку «Код валюты» в таблице продаж, то при изменении валюты документа придётся также обновлять все связанные с ним строки продаж.
Что значит провести нормализацию баз данных?
Реляционная база данных это упорядоченная информация, которая связана некоторыми отношениями между собой. Логически реляционная база обычно представлена в виде таблицы, именно в них и хранится вся информация.
Нормализация баз данных
В реляционных базах данных используется такое понятие, нормализация. Нормализация представляет собой процесс удаления ненужных или избыточных данных. Нормализацию баз данных можно рассматривать и с точки зрения проектирования баз, и тогда процесс нормализации можно определить другим образом. В этом случае под нормализацией понимается метод проектирования базы данных, который даёт пользователю возможность привести базу данных к минимальной избыточности.
Для чего же пользователям нужно проводить нормализацию баз, и чем мешает избыточность. Пользователь борется с избыточностью, так как она создает возможность появления различных отклонений в работе базы данных, уменьшает её производительность. Так же в этом случае управление базами данных становится уже не гибким, и достаточно неудобным.
Поэтому можно сказать, что пользователи делают нормализацию для устранения аномалий, увеличения производительности работы, и более удобного управления данными.
Под избыточностью данных пользователь понимает ситуацию, при которой одни и те же данные хранятся в базе одновременно в нескольких местах и таблицах, а это в свою очередь приводит к отклонениям в работе базы. При этом нужно изменять, удалять эти данные в нескольких местах. Если пользователь не выполнит эту операцию в одной из таблиц, то получится что одни данные не соответствуют таким же данным в другом месте.
Например, есть таблица, где записана информация
о том, какая мебель есть в доме. В таблице указаны стол, стул, кровать, шкаф, комод. Также указано, из какого материала сделаны все предметы, например, металл, дерево, лдсп. Может возникнуть ситуация, что нужно вместо слова массив дерева указать натуральное дерево. При этом из дерева сделано несколько предметов мебели, то есть в таблице заполнено несколько строк.
Таким образом, возникают различные противоречивые ситуации, которые появляются из-за изменения и удаления данных в таблицы. А ведь в больших организациях в таблицах миллионы записей. Поэтому пользователям требуется вовремя устранять избыточных данных в базе, это и есть проведение нормализации базы данных.
В рассмотренном примере нужно название материала, из которого сделана мебель, внести в новую таблицу, а в таблице, где указаны предметы мебели, указать только ссылку на требуемый материал. В этом случае будет соотнесена ссылка с исходной записью, и пользователь будет понимать, из какого материала изготовлен предмет мебели.
И в следующий раз, когда пользователю нужно будет изменить название материала, изменения будут вноситься только в одну таблицу, изменять придётся одну строку. Значит, выделяя материалы в виде отдельной таблицы или сущности, будет устранена аномалия, то есть, проведена нормализация.
Нормальные формы базы данных
Процедура нормализации базы данных должна быть такой: пользователь по правилам и определённым требованиям проектирует таблицы в базе данных. Правила и требования по составлению таблиц могут быть сгруппированы, если пользователь создаст базу данных по всем правилам, то база данных будет находиться в состоянии, точнее в форме, которую можно назвать нормальная форма базы данных. Значит, следуя правилам и требованиям базу данных можно перевести к нормальной форме.
Нормальной формой баз данных называют набор правил и критериев, которым должна соответствовать база данных.
Чем выше нормальная форма, тем меньше проблем и аномалий будет в базе данных. Процесс нормализации представляет собой последовательное выполнение действий по проведению базы данных к определенному виду.
Пятая нормальная форма
Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.
Такая вот теория… Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:).
Нормализация базы данных
Нормализация базы данных – это рекомендации по проектированию.
Преимущества нормализованной базы данных:
- Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.
- Целостность данных. Избежание потерь или искажения информации в базе данных.
- Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.
- Благоприятные предпосылки к росту базы.
Как привести базу данных к нормальной форме?
Для приведения базы к нормальной форме необходимо выполнить следующие действия:
- Постараться объединить данные в группы.
- Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.
Существует 3 нормальные формы базы данных:
-
Первая нормальная форма
Таблица представляет сущность которая в ней размещена (например клиенты, заказы и т.д.) Причём в каждой таблице имеется уникальное поле (первичный ключ) например id и каждая таблица состоит из наименьшего количества полей.
Пример №1:id name languages 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript В примере №1. Представлена не удачная структура таблицы, где в поле languages указано перечисление.
Пример №2:id name languages1 languages2 languages3 1 Иван Java C++ PHP 2 Пётр PHP JavaScript NULL 3 Михаил C# JavaScript NULL
В примере №2 тоже не верная структура таблицы для поля languages.
Правильная структура таблиц для решения данной задачи:
Пример №3:
Таблица пользователей
id name languages 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript Таблица языков программирования
id language 1 Java 2 PHP 3 C# 4 JavaScript 5 Java Таблица связей между пользователями и языками программирования
id language_id user_id 1 2 1 2 1 1 3 5 1 4 1 2 -
Вторая нормальная форма
Для второй нормальной формы требуется первая нормальная форма.Пример №4:
id make model 1 bmw X5 2 bmw X6 3 audi A4 4 audi Q5 5 toyota corolla В примере №4 мы видим дублирование некоторых марок автомобилей (Данные избыточны). Требуется сделать разделение на несколько таблиц как в примере №3. На первый взгляд создание новых таблиц кажется более затратным чем реализация в примере №4, но это только до тех пор когда таблица состоит всего из нескольких строк.
Правильная структура таблиц для решения данной задачи: -
Третья нормальная форма
Требуется вторая нормальная форма.
Согласно третьей нормальной форме данные не должны храниться в таблице, которые могут быть получены из не ключевых полей.Пример №5:
Таблица цен и цен с НДС
id price price_nds 1 1100 1243 2 950 1074 Так как цену с НДС можно получить из поля price, то данную задачу нужно переложить на язык программирования.
Отношения
Отношения — это указатели, которые показывают, как соотносятся данные в одной таблице с данными в другой. Проще говоря, ссылка с одного столбца первой таблицы на другой столбец второй таблицы. Бывают трех видов — один-к-одному, один-к-многим, многие-к-многим.
Отношение один-к-одному означает что поле 1 соотносится с полем 2. Пример — у каждого человека свой номер паспорта. 1 человек- 1 паспорт. Тут отношение один-к-одному.
Один-к-многим указывает, что поле 1 может соотносится как с полем 2, так и с полем 3, полемN.
Отношение многие-к-многим бывает, когда нескольким значениям из одной таблицы соответствует несколько значений другой таблицы. Например, в категории блога может быть много постов, а у блога может быть много категорий. Еще такое отношение может встречаться в составных ключах. Такой связи следует избегать, поскольку она ведет к избыточности данных. В том-же вордпрессе категории и посты соотносятся через третью таблицу — wp_relationships.
Создание структуры базы данных (схема) и отношений между таблицами можно ускорить, использую различные CASE-средства. В конце будет ссылка на mysql workbench, бесплатную кроссплатформенную программу.
Нарушения правил нормализации
Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.
Две основных причины, чтобы нарушить правила нормализации — удобство и быстродействие. Меньшим число таблиц проще управлять, чем большим. Кроме того, из-за более сложного характера, нормализованные таблицы более медленные для обновления, изменения и выдачи данных. Читайте еще: Как продавать в Инстаграм.
Вкратце, нормализация это сделка между целостностью/расширяемостью и простотой/скоростью. С другой стороны, есть достаточно способов чтобы улучшить производительность базы данных, но не так много способов чтобы исправить повреждённые данные, возникшие из-за плохого дизайна структуры.
Практика и опыт подскажут, как сделать модель базы данных, но лучше совершайте ошибки пробуя нормальные формы, хотя бы до тех пор, пока не поймете принцип.
Нормализация базы данных и ее формы
Примечание: Во всех статьях текущей категории уроков по SQL используются примеры и задачи, основанные на учебной базе данных.
Приступая к изучению данного материала, рекомендуется ознакомиться с описанием учебной БД.
Материал этой статьи напрямую не относиться к изучению языка SQL, так как имеет отношение к проектированию баз данных (БД), но для общего понимания взаимосвязи хранимой в системе информации она будет полезна.
По поводу того, как должна быть спроектирована база нет 100% решения, потому что конкретный вариант может удовлетворять либо не удовлетворять различным бизнес-процессам и целям
Но не принимать во внимание элементарные правила нельзя, так как их соблюдение сохранит много времени, нервов и денег при работе с данными
Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».
Первая нормальная форма
Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.
Рассмотрим таблицы сотрудников и телефонных линий.
Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:
Но подобная структура не является надежной. Представьте, что Вам необходимо поменять некоторым сотрудникам подключенные линии. Потребуется осуществить разбор составного поля, чтобы определить наличие id сотрудника в каждой записи линий, затем скорректировать перечень. Получается слишком сложный и долгий процесс для такой простой операции.
Организации структуры таблиц с применением дополнительной связывающей избавляет от подобных проблем.
Помимо атомарности к первой нормальной форме относятся следующие правила:
- Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д. Размещение записей в таблице не имеет никакого значения.
- Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
- Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.
Вторая нормальная форма
Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.
Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.
На представленной диаграмме столбцы описания и приоритета зависят от столбца «Линия», входящего в составной ключ. Это значит, что для каждой линии, подключенной разным сотрудникам, потребуется повторно указывать описание и приоритетность. Подобная структура приводит к избыточности данных.
Также велика вероятность возникновения противоречивой информации. Изменяя приоритет или описание для линии, можно по ошибке оставить некоторые строки не обработанными. В таком случае, для одного и того же идентификатора линии значения зависимых полей будут различными.
Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.
Третья нормальная форма
3NF схожа по логике с 2NF, но с некоторым отличием. Если 2 форма ликвидирует зависимости неключевых полей от части ключа, то третья нормальная форма исключает зависимость неключевых полей от других неключевых полей.
На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.
Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.
Денормализация базы данных
Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.
Для баз данных, предназначенных для аналитики, часто выполняют денормализацию, чтобы укорить выполнение запросов.
Вторая нормальная форма
- Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.
- Свяжите эти таблицы с помощью внешнего ключа.
Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.
Ключи
Ключи являются составляющей частью нормализованных таблиц. Бывают двух видов — внешние и первичные.
Первичный ключ — это уникальный идентификатор, отвечающий следующим условиям:
- Он должен иметь значение, не NULL.
- Быть неизменным — значение ключа не должно меняться.
- Иметь уникальное значение для каждой строки.
Внешние ключи — это ссылки на первичные ключи других таблиц, которые удовлетворяют условиям выше.
Для начала нормализации следует указать хотя бы один первичный ключ. В примере это будет message ID.
Для указания первичного ключа, надо найти поле, которое будет подходить под все три условия. Если такого поля нет, его надо создать. В идеале, поле должно иметь тип integer.
Отношения
Отношения — это указатели, которые показывают, как соотносятся данные в одной таблице с данными в другой. Проще говоря, ссылка с одного столбца первой таблицы на другой столбец второй таблицы. Бывают трех видов — один-к-одному, один-к-многим, многие-к-многим.
Отношение один-к-одному означает что поле1 соотносится с полем2. Пример — у каждого человека свой номер паспорта. 1 человек- 1 паспорт. Тут отношение один-к-одному.
Один-к-многим указывает, что поле1 может соотносится как с полем2, так и с полем3, полемN… В книге приведён пример — у одного мужчины может быть много женщин и наоборот Автор юморист Один-к-многим самая распространённая связь между таблицами в нормализованных базах.
Отношение многие-к-многим бывает, когда нескольким значениям из одной таблицы соответствует несколько значений другой таблицы. Например, в категории блога может быть много постов, а у блога может быть много категорий. Еще такое отношение может встречаться в составных ключах. Такой связи следует избегать, поскольку она ведет к избыточности данных. В том-же вордпрессе категории и посты соотносятся через третью таблицу — wp_relationships.
На рисунке приведены условные обозначения всех трех отношений в нотации UML.
Создание структуры базы данных (схема) и отношений между таблицами можно ускорить, использую различные CASE-средства. В конце будет ссылка на mysql workbench, бесплатную кроссплатформенную программу.
Описание нормализации
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше.
Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.
Существует несколько правил нормализации баз данных. Каждое правило называется обычной формой. Если наблюдается первое правило, база данных считается в «первой обычной форме». Если выполняются первые три правила, база данных считается в третьей обычной форме. Хотя возможны и другие уровни нормализации, третья обычная форма считается наивысшим уровнем, необходимым для большинства приложений.
Как и в случае со многими другими формальными правилами и спецификациями, обеспечить полное соответствие реальным ситуациям не всегда возможно. Как правило, для выполнения нормализации приходится создавать дополнительные таблицы, и некоторые клиенты считают это нежелательным. Собираясь нарушить одно из первых трех правил нормализации, убедитесь в том, что в приложении учтены все связанные с этим проблемы, такие как избыточность данных и несогласованные зависимости.
В описаниях ниже приведены соответствующие примеры.
Кейс «Задание на разработку»
Рассмотрим ситуацию постановки задачи СВОЕМУ программисту. Т.е. пишем техническое задание не для клиента, а своему, такому же раздолбаю, который сидит в соседнем отделе и носит гордое имя «программист». Ах, у Вас он даже в офис не ходит? Дома работает? Что ж, скайп нам в руки. А у Вас? Вы вообще его лично никогда не видели? Значит ситуация сложнее.
И ведь он, поганец такой, требует, чтоб ему дали конкретную работу. И не грузили всякой ерундой и не лили воду на мельницу.
В идеале, было бы вообще замечательно, если бы можно было бы из технического задания, которое мы подготовили для клиента, нарезать небольшие задания и раздавать их разным исполнителям. А затем в проджекте галочки об исполнении ставить.
Но ведь нет, на практике же приходится давать устные пояснения по каждому пункту. Объяснять, что имелось в виду вот в этом предложении ТЗ в тот момент, когда его формулировал для клиента.
Вот и предлагаю способ сохранить нервы себе и уверенность в Вас со стороны программиста.
1 стартмани
45
Чтобы привести базу к третьей нормальной форме, надо:
1. Определить, в каких полях каких таблиц имеется взаимозависимость. Как только что говорилось, поля, которые зависят больше друг от друга (как город от штата), чем от ряда в целом. В базе форума такой проблемы нет. Взглянув на таблицу сообщений, увидите, что каждый заголовок, каждое тело сообщения относится к своему message ID.
2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.
3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.
4. Создайте необходимые внешние ключи, которые образуют любое из отношений. В нашем примере нужно добавить state ID в таблицу городов и city ID в таблицу клиентов. Это свяжет каждого клиента с городом и штатом, где они живут.
Рассмотренная в качестве примера база данных с записями о клиентах, созданы две новых таблицы для хранения информации о городах и штатах.
Подсказки:
Вообще, можно было бы и не нормализовывать базу с клиентами до такой степени. Если оставить города и штаты в таблице клиентов, самое страшное, что могло бы случиться — если бы город изменил название, нужно было бы менять его во всех записях о клиентах, которые живут в этом городе. Но города редко меняют свои имена.
Несмотря на то, что имеются правила как нормализовывать базы данных, разные люди сделают это разными способами. Проектирование баз данных допускает личные предпочтения и интерпретации
Важно, чтобы в базе не было явных нарушений нормальных форм, которые могут привести в дальнейшем к проблемам
Примеры правил нормализации базы данных
Первая нормальная форма – 1НФ
Согласно установленным правилам, атрибуты в таблице должны иметь простой и понятный вид, а все сохраненные данные в строках и столбцах должны содержать скалярные значения. Здесь не допускается наличие повторяющихся строк. В качестве примера можно рассмотреть таблицу с автомобилями
Следует обратить внимание на нарушение нормализации в моделях BMW. В таблице в одной ячейке находится перечень сразу из трех элементов – М5, Х5М и М1
Это свидетельствует об отсутствии атомарности. После проведенного преобразования 1НФ таблица будет иметь другой вид.
Вторая нормальная форма 2НФ
Отношения в таблице будут соответствовать 2НФ при условии, что база данных находится в 1 НФ и каждый ее столбец зависит от первичного ключа. Рассмотрим еще одну таблицу.
Представленная выше таблица приведена в форму 1НФ, но не в форму 2НФ. Здесь стоимость автомобилей зависит от производителя и модели. Также размер скидки зависит от производителя, поэтому прямая функциональная зависимость от самого первого ключа будет неполной. Это можно исправить, если выполнить декомпозицию сразу на 2 отношения, где не ключевые атрибуты будут зависеть только от первого ключа.
Третья нормальная форма 3НФ
В данном случае таблица должна находиться в форме 2НФ, а каждый лишний столбец, не являющийся ключом, должен зависеть от первичного ключа.
В представленной таблице в отношении атрибут первым ключом является «Модель». Поскольку свои телефоны у автомобилей отсутствуют, то необходимо указывать номера продаваемых их магазинов. В результате создается связь функционального типа или зависимость следующего вида:
Такая модель транзитивна, поэтому ее отношение не отражается в 3НФ. Если разделить исходное отношение, то можно получить два отношения, которые будут отражены в форме 3НФ.
1С:Розница 8. Магазин автозапчастей
Нормализация нормативно-справочной информации (НСИ)
Заказать помощь специалиста 1С
Нарушения правил нормализации
Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.
Две основных причины, чтобы нарушить правила нормализации — удобство и быстродействие. Меньшим число таблиц проще управлять, чем большим. Кроме того, из-за более сложного характера, нормализованные таблицы более медленные для обновления, изменения и выдачи данных. Вкратце, нормализация это сделка между целостностью/расширяемостью и простотой/скоростью. С другой стороны, есть достаточно способов чтобы улучшить производительность базы данных, но не так много способов чтобы исправить повреждённые данные, возникшие из-за плохого дизайна структуры.
Практика и опыт подскажут, как сделать модель базы данных, но лучше совершайте ошибки пробуя нормальные формы, хотя бы до тех пор, пока не поймете принцип.
Ссылки на оригинал:
- Введение
- Первая нормальная форма
- Вторая нормальная форма
- Третья нормальная форма
Заключение
Продолжать заниматься нормализацией можно и дальше: существуют 4NF, 5NF и DKNF (Domain Key Normal Form). Использование четырех уровней нормализации, рассмотренных в этой статье, является вполне достаточным в большинстве случаев проектирования баз данных. Таблицы могут быть нормализованы и до более высоких типов, но на практике это бывает не всегда возможно. Недостатком при стремлении к более высоким уровням нормализации является то, что таблицы могут быть разложены на более меньшие, чтобы отразить все возможные зависимости.
В результате получается, что даже для простого поиска по базе данных, требуется делать множество операций объединения таблиц. Это является слишком «дорогостоящей» процедурой и приводит к снижению производительности. Тем не менее, использовать четыре уровня нормализации баз данных, описанные в этой статье, не только желательно, но и необходимо в большинстве случаев.
Источник статьи — Источник статьи — http://www.developer.com/db/understanding-database-normalization.html
