Что такое нормализация данных в базе данных
BestProg
Нормализация. Понятие и необходимость применения. Аномалии модификации. Примеры
Содержание
Поиск на других ресурсах:
1. Нормализация. Назначение и необходимость применения
Нормализация – это процесс (процедура) приведения таблиц базы данных к ряду нормальных форм (НФ) с целью избежания избыточности в базе данных, аномалий вставки, редактирования и удаления данных. Таблицы могут иметь неэффективную или не подходящую структуру, которую нужно нормализовать. Нормализация предусматривает разбивку исходной таблицы (отношения) на несколько новых таблиц (отношений).
Правильное применение механизма нормализации к базе данных дает следующие взаимосвязанные преимущества:
Процесс нормализации включает в себя использование так называемых нормальных форм. На сегодняшний день известны следующие нормальные формы (рисунок 1):
База данных считается правильно спроектированной (оптимальной или приближенной к оптимальной), если она отвечает требованиям нормальных форм. Не обязательно применять все 5 нормальных форм. Если количество атрибутов (столбцов) в базе данных небольшое, то достаточным есть применение первых трех нормальных форм. Взаимосвязь нормальных форм изображена на рисунке 1.
Рисунок 1. Взаимосвязь нормальных форм
2. Понятие избыточности данных. Пример
Избыточность данных возникает при неправильном проектировании таблицы базы данных. В этом случае таблица содержит повторяющиеся группы данных. Такие группы данных возникают, когда осуществляется попытка записать в одну ячейку таблицы более одного значения.
Пример. Пусть задана база данных учета учебного процесса в некотором учебном заведении, которая описывается таблицей (одной из таблиц) со следующей структурой
Рисунок 2. Структура таблицы базы данных учебного заведения
Для примера в таблицу внесены следующие данные (фрагмент таблицы).
Рисунок 3. Таблица с заполненными данными. Избыточность данных
В вышеприведенной таблице избыточность данных проявляется в следующих определениях:
3. Аномалия вставки. Пример
Аномалия вставки проявляется в случаях, когда нужно добавить данные к таблице. Здесь может возникнуть ситуация, когда для вставки данных нужно добавлять (выгадывать) лишние (несуществующие) данные. Иными словами, в базу данных невозможно записать данные об одной сущности, не указав данных о другой сущности. Значит, аномалия вставки – это добавление нежелательной или несуществующей (выдуманной) информации об одной сущности в момент вставки информации о другой сущности.
Рисунок 4. Таблица с данными об успеваемости в учебном заведении
Пусть в эту базу данных нужно добавить нового преподавателя математики (столбцы Преподаватель, Дисциплина), который недавно принят на работу. Для этого необходимо, чтобы новый преподаватель обязательно оценил хотя бы одного студента. Иначе, в таком представлении базы данных, добавить данные будет невозможно. Значит, при добавлении преподавателя, нужно выгадывать несуществующие данные оценивания студента. Это и есть аномалия вставки.
Рисунок 5. Пример аномалии вставки. Добавление преподавателя в базу данных требует указания информации о студенте
То же самое можно сказать и о студенте. Если в базу данных нужно добавить студента, который будет оценен спустя некоторое время (в конце семестра), то нужно выгадывать оценку, которую он получит из дисциплины, которая еще только изучается. Преподаватель на этот момент может быть уже известен.
4. Аномалия редактирования. Пример
Бывают случаи, когда в таблице базы данных данные в некоторой ячейке нужно отредактировать (поправить). Причиной этому могут быть, например, ошибки ввода или изменение некоторых названий с течением времени через весомые причины. Если корректируемые данные сохранены в одном экземпляре, то проблем нет. Если же корректируемые данные сохраняются во многих ячейках таблицы, то возникает так называемая аномалия редактирования.
Значит аномалия редактирования возникает в случаях, когда в таблице базы данных существуют повторяющиеся данные. Такие данные тяжело обновлять при их редактировании, поскольку нужно вносить изменения во все ячейки таблицы, в которых эти данные фигурируют. Если при изменении повторяемых данных в одной ячейке не изменить так же эти данные в других ячейках, то компьютер будет воспринимать эти данные как разные (в отличие от человека).
Аномалия редактирования – это вынужденная необходимость изменения (обновления) данных во всей таблице в случае их изменения (обновления) в одной ячейке таблицы с целью избежания их двузначного трактования.
Пример. Задана таблица базы данных учета успеваемости в учебном заведении. Пусть преподаватель физики Петренко М.М. вышла замуж и изменила фамилию на Маркевич. Теперь во всех ячейках столбца (атрибута) Преподаватель нужно изменить имя преподавателя Петренко М.М. на Маркевич М.М. (рисунок 4).
Рисунок 6. Аномалия редактирования. Редактирование одних и тех же данных в одной ячейке требует изменения этих данных в других ячейках
5. Аномалия удаления. Пример
Аномалия удаления проявляется в случаях, когда нужно удалить данные из таблицы. Аномалия удаления – это потеря одних данных в таблице при удалении других данных в таблице.
Рисунок 7. Аномалия удаления. При удалении информации об оценивании студента теряется информация о преподавателе кафедры
Нормализация отношений. Первая и вторая нормальные формы
Предисловие
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Любому специалисту, по роду своей деятельности так или иначе связанному с проектированием реляционных баз данных, полезно понимать и уметь осуществить нормализацию отношений. И этим постом хотелось бы начать небольшую серию публикаций, посвящённых нормальным формам, имеющую целью дать тем читателям Хабрахабра, которые по различным обстоятельствам ещё не освоили эту тему, возможность легко заполнить этот пробел в знаниях.
Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе. Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами. Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение:
Первая нормальная форма
Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности.
Будем называть исходное отношение основным, а значение неатомарного атрибута — подчинённым.
Для того, чтобы нормализовать исходное отношение, атрибуты которого неатомарны, необходимо объединить схемы основного и подчинённого отношений. Кроме того, если, например, таблица, соответствующая ненормализованному отношению уже содержится в БД и заполнена информацией, задача усложняется тем, что значение неатомарного атрибута может в свою очередь содержать несколько кортежей.
Следует пояснить сказанное на примере. Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.
Код сотрудника | ФИО | Должность | Проекты |
1 | Иванов Иван Иванович | Программист | ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011 ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011 ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011 |
Легко заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение этого атрибута для сотрудника Иван Иванович Иванов содержит несколько кортежей — информацию о трёх проектах.
Примечание: с некоторой точки зрения атрибут «ФИО» можно также считать неатомарным и в таком случае его также следует разделить на более простые, как «Фамилия», «Имя», «Отчество».
Результат будет выглядеть так:
Код сотрудника | ФИО | Должность | Код проекта | Название | Дата сдачи |
1 | Иванов Иван Иванович | Программист | 123 | Система управления паровым котлом | 30.09.2011 |
1 | Иванов Иван Иванович | Программист | 231 | ПС для контроля и оповещения о превышениях ПДК различных газов в помещении | 30.11.2011 |
1 | Иванов Иван Иванович | Программист | 321 | Модуль распознавания лиц для защитной системы | 01.12.2011 |
Вторая нормальная форма
Ясно, что отношение, находящееся в 1НФ, также может обладать избыточностью. Для её устранения предназначена вторая нормальная форма. Но прежде чем приступить к её описанию, сначала следует выявить недостатки первой.
Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.
Код поставщика | Город | Статус города | Код товара | Количество |
1 | Москва | 20 | 1 | 300 |
1 | Москва | 20 | 2 | 400 |
1 | Москва | 20 | 3 | 100 |
2 | Ярославль | 10 | 4 | 200 |
3 | Ставрополь | 30 | 5 | 300 |
3 | Ставрополь | 30 | 6 | 400 |
4 | Псков | 15 | 7 | 100 |
Заранее известно, что в этом отношении содержатся следующие функциональные зависимости:
< <Код поставщика, Код товара>-> < Количество>,
<Код поставщика>-> <Город>,
<Код поставщика>-> <Статус>,
<Город>-> <Статус>>
Такое разбиение устранило аномалии, описанные выше: можно добавить информацию о поставщике, который ещё не поставлял товар, удалить информацию о поставке без удаления информации о поставщике, а также легко обновить информацию в случае если поставщик переехал в другой город.
Теперь можно сформулировать определение второй нормальной формы, до которого, скорее всего, читатель уже смог догадаться самостоятельно: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
Нормализация баз данных простыми словами
Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами поговорим о нормализации базы данных, узнаем, что это такое, какие нормальные формы базы данных существуют и зачем вообще проводить нормализацию базы данных.
Постоянные посетители данного сайта знают, что я здесь публикую достаточно много различных материалов, связанных с языком SQL и системами управления базами данных, однако статей, связанных с теорией баз данных, на текущий момент, к сожалению, нет, поэтому я решил это исправить, и начать цикл статей, посвященных теории баз данных.
Начну я с нормализации баз данных. В этом материале мы поговорим в целом о процессе нормализации, узнаем, зачем проводить нормализацию базы данных, что такое нормальная форма базы данных, а также какие нормальные формы существуют. В следующих материалах я подробно и с примерами расскажу про каждую нормальную форму.
Реляционная база данных
В целом под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных и воспользоваться ей, однако если говорить в контексте SQL, то речь будет идти, конечно, о реляционных базах данных, а что же это такое?
Реляционная база данных – это упорядоченная информация, связанная между собой определёнными отношениями.
Логически такая база данных представлена в виде таблиц, в которых и лежит вся эта информация.
Примечание! Если Вас интересует язык SQL, рекомендую пройти мой онлайн-курс по основам SQL, который ориентирован на изучение SQL как стандарта, таким образом, Вы сможете работать в любой системе управления базами данных. Курс включает много практики: онлайн-тестирование, задания и многое другое.
Нормализация баз данных
В реляционных базах данных есть такое понятия, как «Нормализация».
Нормализация – это процесс удаления избыточных данных.
Также нормализацию можно рассматривать и с позиции проектирования базы данных, в таком случае мы можем сформулировать определение нормализации следующим образом.
Нормализация – это метод проектирования базы данных, который позволяет привести базу данных к минимальной избыточности.
Избыточность устраняется, как правило, за счёт декомпозиции отношений (таблиц), т.е. разбиения одной таблицы на несколько.
Зачем нормализовать базу данных?
У Вас может возникнуть вопрос – а зачем вообще нормализовать базу данных и бороться с этой избыточностью?
Дело в том, что избыточность данных создает предпосылки для появления различных аномалий, снижает производительность, и делает управление данными не гибким и не очень удобным. Отсюда можно сделать вывод, что нормализация нужна для:
Теперь давайте поговорим о самой избыточности данных, что же это такое.
Избыточность данных – это когда одни и те же данные хранятся в базе в нескольких местах, именно это и приводит к аномалиям.
Так как в этом случае необходимо добавлять, изменять или удалять одни и те же данные в нескольких местах. Например, если не выполнить операцию в каком-нибудь одном месте, то возникает ситуация, когда одни данные не соответствуют вроде как точно таким же данным в другом месте.
Давайте рассмотрим пример. Допустим, у нас есть следующая таблица, она хранит информацию о предметах мебели, в частности наименование предмета и материал, из которого изготовлен этот предмет.
Идентификатор предмета | Наименование предмета | Материал |
1 | Стул | Металл |
2 | Стол | Массив дерева |
3 | Кровать | ЛДСП |
4 | Шкаф | Массив дерева |
5 | Комод | ЛДСП |
А теперь допустим, что у нас возникла необходимость подкорректировать название материала, вместо «Массив дерева» нужно написать «Натуральное дерево», и чтобы это сделать нам необходимо внести изменения сразу в несколько строк, так как предметов, изготовленных из массива дерева, несколько, а именно 2: стол и шкаф.
А теперь представьте, что по каким-то причинам мы внесли изменения только в одну строку, в итоге в нашей таблице будет и «Массив дерева», и «Натуральное дерево».
Идентификатор предмета | Наименование предмета | Материал |
1 | Стул | Металл |
2 | Стол | Натуральное дерево |
3 | Кровать | ЛДСП |
4 | Шкаф | Массив дерева |
5 | Комод | ЛДСП |
Какое из этих названий будет правильным? А если представить, что мы можем внести еще какое-то новое значение при добавлении новых записей, например, просто «Дерево».
В этом случае в нашей таблице в скором времени будет и «Массив дерева», и «Натуральное дерево», и просто «Дерево», и вообще, что угодно, ведь это просто текст.
Идентификатор предмета | Наименование предмета | Материал |
1 | Стул | Металл |
2 | Стол | Натуральное дерево |
3 | Кровать | ЛДСП |
4 | Шкаф | Массив дерева |
5 | Комод | ЛДСП |
6 | Тумба | Дерево |
Однако по своей сути это один и тот же материал, мы просто решили или подкорректировать его название, или ошиблись при добавлении новой записи. Это и есть аномалия, когда одни данные в одном месте не соответствуют вроде как точно таким же данным в другом месте. Это всего лишь один вид аномалии, однако в процессе добавления, изменения и удаления данных может возникать много других противоречивых ситуаций, т.е. аномалий.
При этом, обязательно стоит отметить, что в нашей таблице всего 5 записей, а теперь представьте, что их миллион!
Именно поэтому мы должны устранять избыточность данных в базе, т.е. проводить так называемую нормализацию базы данных.
В данном конкретном случае мы должны название материала, из которого изготовлены предметы мебели, вынести в отдельную таблицу, а в таблице с предметами сделать всего лишь ссылку на нужный материал, тем самым, соотнеся эту ссылку с исходной записью, мы будем понимать, из какого материала сделан тот или иной предмет.
Идентификатор предмета | Наименование предмета | Идентификатор материала |
1 | Стул | 2 |
2 | Стол | 1 |
3 | Кровать | 3 |
4 | Шкаф | 1 |
5 | Комод | 3 |
Материалы, из которых изготовлены предметы мебели.
Идентификатор материала | Материал |
1 | Массив дерева |
2 | Металл |
3 | ЛДСП |
В этом случае когда нам потребуется изменить название материала, мы будем вносить изменение только в одном месте, т.е. править только одну строку.
Таким образом, представляя материалы в виде отдельной сущности и создавая для нее отдельную таблицу, мы устраняем описанную выше аномалию.
Другими словами, каждая сущность должна храниться отдельно, а в случае необходимости использования этой сущности в другой таблице на нее делается всего лишь ссылка, т.е. выстраивается связь.
Нормальные формы базы данных
В целом процесс нормализации базы данных выглядит следующим образом: мы, следуя определённым правилам и соблюдая определенные требования, проектируем таблицы в базе данных.
При этом все эти правила и требования можно сгруппировать в несколько наборов, и если спроектировать базу данных с соблюдением всех правил и требований, которые включаются в тот или иной набор, то база данных будет находиться в определённом состоянии, т.е. форме, и такая форма называется нормальная форма базы данных.
Иными словами, следуя определённым правилам и соблюдая определенные требования мы приводим базу данных к определенной нормальной форме.
Нормальная форма базы данных – это набор правил и критериев, которым должна отвечать база данных.
Каждая следующая нормальная форма содержит более строгие правила и критерии, тем самым приводя базу данных к определённой нормальной форме мы устраняем определённый набор аномалий.
Отсюда можно сделать вывод, что чем выше нормальная форма, тем меньше аномалий в базе будет.
Процесс нормализации – это последовательный процесс приведения базы данных к эталонному виду, т.е. переход от одной нормальной формы к следующей.
Иными словами, процесс перехода от одной нормальной формы к следующей – это усовершенствование базы данных. Так как если база данных находится в какой-то определённой нормальной форме – это означает, что в базе данных отсутствует определенный вид аномалий.
Существует 5 основных нормальных форм базы данных:
Однако выделяют еще дополнительные нормальные формы:
Если объединить оба этих списка и упорядочить нормальные формы от менее нормализованной до самой нормализованной, т.е. начиная с формы, при которой база данных по своей сути не является нормализованной, и заканчивая самой строгой нормальной формой, то мы получим следующий перечень:
База данных считается нормализованной, если она находится как минимум в третьей нормальной форме (3NF).
В реальном мире нормализация до третьей нормальной формы (3NF) является обычной, стандартной практикой, так как 3NF устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство ее использования не снижается, что нельзя сказать о всех последующих формах.
Ситуации, при которых требуется нормализовать базу данных до четвертой нормальной формы (4NF), в реальном мире встречаются достаточно редко.
Заметка! Если Вас интересует язык SQL, рекомендую почитать мою книгу «SQL код», которая ориентирована на изучение SQL как стандарта, после прочтения книги Вы сможете писать SQL запросы в любой системе управления базами данных.
Если говорить о всех последующих нормальных формах (5NF, DKNF, 6NF), то в реальной жизни трудно даже представить ситуации, при которых потребуется нормализовать базу данных до этих форм.
Иными словами, 5NF, DKNF, 6NF – это в большей степени теоретические нормальные формы, немного отстраненные от реального мира.
Стоит отметить, что приведение базы данных к какой-то конкретной нормальной форме, обязательно требует, чтобы эта база данных уже находилась в предыдущей нормальной форме. Другими словами, если Вы хотите нормализовать базу данных до третьей нормальной формы, то база уже должна находиться во второй нормальной форме, т.е. нельзя нормализовать базу данных до третьей формы, если она еще не нормализована до второй.
Описание нормальных форм базы данных
В следующих статьях представлено подробное описание каждой нормальной формы и приведены примеры.
На сегодня это все, надеюсь, материал был Вам полезен и интересен, пока!