ћерион Ќетворкс

Ќормализаци€ базы данных (Ѕƒ) - это метод проектировани€ рел€ционных Ѕƒ, который помогает правильно структурировать таблицы данных. ѕроцесс направлен на создание системы с четким представлением информации и взаимосв€зей, без избыточности и потери данных.

¬ данной статье рассказываетс€, что такое нормализаци€ базы данных, и объ€сн€ютс€ принципы ее работы на практическом примере.


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

Ќормализаци€ базы данных - это метод создани€ таблиц Ѕƒ со столбцами и ключами путем разделени€ (или декомпозиции) таблицы большего размера на небольшие логические единицы. ¬ данном методе учитываютс€ требовани€, предъ€вл€емые к среде Ѕƒ.

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


«ачем нужна нормализаци€ базы данных?

Ќормализаци€ позвол€ет разработчику Ѕƒ оптимально распредел€ть атрибуты по таблицам. ƒанна€ методика избавл€ет от:

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

Ќеоб€зательно выполн€ть полную нормализацию Ѕƒ. ќднако она гарантирует полноценно функционирующую информационную среду. Ётот метод:

  • позвол€ет создать структуру базы данных, подход€щую дл€ общих запросов;
  • сводит к минимуму избыточность данных, что повышает эффективность использовани€ пам€ти на сервере Ѕƒ;
  • гарантирует максимальную целостность данных, устран€€ аномалий вставки, обновлени€ и удалени€.

Ќормализаци€ базы данных преобразует общую целостность данных в удобную дл€ пользовател€ среду.


»збыточность баз данных и аномалии

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

“ак выгл€дит таблица без нормализации:

“аблица без нормализации

ƒл€ таблицы характерна избыточность данных, а при изменении этих данных возникают 3 аномалии:

  1. јномали€ вставки. ѕри добавлении нового «—отрудника» (employee) в «ќтдел» (sector) Finance, об€зательно указываетс€ его «–уководитель» (manager). »наче вы не сможете вставить данные в таблицу.
  2. јномали€ обновлени€.  огда сотрудник переходит в другой отдел, поле «–уководитель» содержит ошибочные данные.   примеру, ƒжейкоб (Jacob) перешел в отдел Finance, но его руководителем по-прежнему показываетс€ јдам (Adam).
  3. јномали€ удалени€. ≈сли ƒжошуа (Joshua) решит уволитьс€ из компании, то при удалении строки с его записью потер€етс€ информаци€ о том, что отдел Finance вообще существует.

ƒл€ устранени€ подобных аномалий используетс€ нормализаци€ базы данных.


ќсновные пон€ти€ в нормализации базы данных

ѕростейшие пон€ти€, используемые в нормализации базы данных:

  • ключи - атрибуты столбцов, которые однозначно (уникально) определ€ют запись в Ѕƒ;
  • функциональные зависимости - ограничени€ между двум€ взаимосв€занными атрибутами;
  • нормальные формы - этапы дл€ достижени€ определенного качества Ѕƒ.

Ќормальные формы базы данных

Ќормализаци€ базы данных выполн€етс€ с помощью набора правил. “акие правила называютс€ нормальными формами. ќсновна€ цель данных правил - помочь разработчику Ѕƒ в достижении нужного качества рел€ционной базы.

Ќормальные формы

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

—тадии нормализации:

—тади€

јномалии избыточности

Ќенормализованна€ (нулева€) форма (UNF)

Ёто состо€ние перед любой нормализацией. ¬ таблице присутствуют избыточные и сложные значени€

ѕерва€ нормальна€ форма (1NF)

–азбиваютс€ повтор€ющиес€ и сложные значени€; все экземпл€ры станов€тс€ атомарными

¬тора€ нормальна€ форма (2NF)

„астичные зависимости раздел€ютс€ на новые таблицы. ¬се строки функционально зависимы от первичного ключа

“реть€ нормальна€ форма (3NF)

“ранзитивные зависимости разбиваютс€ на новые таблицы. Ќе ключевые атрибуты завис€т от первичного ключа

Ќормальна€ форма Ѕойса- ода (BCNF)

“ранзитивные и частичные функциональные зависимости дл€ всех потенциальных ключей разбиваютс€ на новые таблицы

„етверта€ нормальна€ форма (4NF)

”дал€ютс€ многозначные зависимости

ѕ€та€ нормальна€ форма (5NF)

”дал€ютс€ JOIN-зависимости (зависимости соединени€)

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

„то такое  люч?

 люч Ѕƒ (key) - это атрибут или группа признаков, которые однозначно описывают сущность в таблице. ¬ нормализации используютс€ следующие типы ключей:

  • суперключ (Super Key) - набор признаков, которые уникально определ€ют каждую запись в таблице;
  • потенциальный ключ (Candidate Key) - выбираетс€ из набора суперключей с минимальным количеством полей;
  • первичный ключ (Primary Key) - самый подход€щий кандидат из набора потенциальных ключей; служит первичным ключом таблицы;
  • внешний ключ (Foreign Key) - первичный ключ другой таблицы;
  • составной ключ (Composite Key) - уникальный ключ, образованный двум€ и более атрибутами, каждый из которых по отдельности не €вл€етс€ ключом.

ѕоскольку таблицы раздел€ютс€ на несколько более простых единиц, именно ключи определ€ют точку ссылки дл€ объекта Ѕƒ.

Ќапример, в следующей структуре базы данных:

 лючи ƒЅ

ѕримерами суперключей €вл€ютс€:

  • employeeID;
  • (employeeID, name);
  • email

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

ѕотенциальные ключи выбираютс€ из набора суперключей с минимальным количеством полей. ¬ нашем примере это:

  • employeeID;
  • email

ќба параметра содержат минимальное количество полей, поэтому они хорошо подход€т на роль потенциальных ключей. —амый логичный выбор дл€ первичного ключа - поле employeeID, поскольку почта сотрудника может изменитьс€. Ќа такой первичный ключ легко ссылатьс€ в другой таблице, дл€ которой он будет считатьс€ внешним ключом.

‘ункциональные зависимости базы данных

‘ункциональна€ зависимость Ѕƒ отражает взаимосв€зь между двум€ атрибутами таблицы. ‘ункциональные зависимости бывают следующих типов:

  • тривиальна€ функциональна€ зависимость - зависимость между атрибутом и группой признаков; исходный элемент €вл€етс€ частью группы;
  • нетривиальна€ функциональна€ зависимость - зависимость между атрибутом и группой признаков; признак не €вл€етс€ частью группы;
  • транзитивна€ зависимость - функциональна€ зависимость между трем€ атрибутами: второй атрибут зависит от первого, а третий - от второго. Ѕлагодар€ транзитивности, третий атрибут зависит от первого;
  • многозначна€ зависимость - зависимость, в которой несколько значений завис€т от одного атрибута.

‘ункциональные зависимости - это важный этап в нормализации Ѕƒ. ¬ долгосрочной перспективе такие зависимости помогают оценить общее качество базы данных.


ѕримеры нормализации базы данных.  ак нормализовать базу данных?

ќбщие этапы в нормализации базы данных подход€т дл€ всех таблиц.  онкретные методы разделени€ таблицы, а также вариант прохождени€ или не прохождени€ через третью нормальную форму (3NF) завис€т от примеров использовани€.

ѕример ненормализованной базы данных

¬ одном столбце ненормализованной таблицы содержитс€ несколько значений. ¬ худшем случае в ней присутствует избыточна€ информаци€.

Ќапример:

ѕример ненормализованной базы данных

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

Ўаг 1: ѕерва€ нормальна€ форма (1NF)

ƒл€ преобразовани€ таблицы в первую нормальную форму значени€ полей должны быть атомарными. ¬се сложные сущности таблицы раздел€ютс€ на новые строки или столбцы.

„тобы не потер€ть информацию, дл€ каждого сотрудника дублируютс€ значени€ столбцов managerID, managerName и area.

ѕерва€ нормальна€ форма (1NF)

ƒоработанна€ таблица соответствует первой нормальной форме.

Ўаг 2: ¬тора€ нормальна€ форма (2NF)

¬о второй нормальной форме кажда€ строка таблицы должна зависеть от первичного ключа.

„тобы таблица соответствовала критери€м этой формы, ее необходимо разделить на 2 части:

Manager (managerID, managerName, area)

¬тора€ нормальна€ форма (2NF), таблица 1

Employee (employeeID, employeeName, managerID, sectorID, sectorName)

¬тора€ нормальна€ форма (2NF), таблица 2

»тогова€ таблица во второй нормальной форме представл€ет собой 2 таблицы без частичных зависимостей.

Ўаг 3: треть€ нормальна€ форма (3NF)

“реть€ нормальна€ форма раздел€ет любые транзитивные функциональные зависимости. ¬ нашем примере транзитивна€ зависимость есть у таблицы Employee; она разбиваетс€ на 2 новых таблицы:

Employee (employeeID, employeeName, managerID, sectorID)

“реть€ нормальна€ форма (3NF), таблица 1

Sector (sectorID, sectorName)

“реть€ нормальна€ форма (3NF), таблица 1

“еперь таблица соответствует третьей нормальной форме с трем€ взаимосв€з€ми.  онечна€ структура выгл€дит так:

Ќомализированна€ Ѕƒ

“еперь база данных считаетс€ нормализованной. ƒальнейша€ нормализаци€ зависит от ваших конкретных целей.


«аключение

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

≈сли же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией Ѕƒ.

ј если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип Ѕƒ.


—кидки 50% в Merion Academy

¬ыбрать курс