Нормализация на СУБД: Пример за база данни 1NF, 2NF, 3NF

Какво е нормализиране на база данни?

нормализиране е техника за проектиране на база данни, която намалява излишъка на данни и елиминира нежелани характеристики като аномалии при вмъкване, актуализиране и изтриване. Правилата за нормализиране разделят по-големите таблици на по-малки и ги свързват чрез релации. Целта на нормализирането в SQL е да елиминира излишните (повтарящи се) данни и да гарантира, че данните се съхраняват логично.

Изобретателят на релационен модел Едгар Код предложи теорията за нормализирането на данни с въвеждането на първата нормална форма и той продължи да разширява теорията с втората и третата нормална форма. Later той се присъединява към Реймънд Ф. Бойс, за да развие теорията за нормалната форма на Бойс-Код.

Видове нормални форми в СУБД

Ето списък на нормалните форми в SQL:

  • 1NF (първа нормална форма): Гарантира, че таблицата на базата данни е организирана така, че всяка колона съдържа атомарни (неделими) стойности и всеки запис е уникален. Това елиминира повтарящите се групи, като по този начин структурира данните в таблици и колони.
  • 2NF (втора нормална форма): Надгражда 1NF от Трябва да премахнем излишните данни от таблица, която се прилага към множество редове. и поставянето им в отделни таблици. Изисква всички неключови атрибути да бъдат напълно функционални на първичния ключ.
  • 3NF (трета нормална форма): Разширява 2NF, като гарантира, че всички неключови атрибути са не само напълно функционални на първичния ключ, но и независими един от друг. Това елиминира преходната зависимост.
  • BCNF (нормална форма на Бойс-Код): Усъвършенстване на 3NF, което адресира аномалии, които не се обработват от 3NF. Изисква всеки детерминант да бъде ключ за кандидат, което гарантира още по-стриктно спазване на правилата за нормализиране.
  • 4NF (Четвърта нормална форма): Адресира многозначни зависимости. Той гарантира, че няма множество независими многозначни факти за даден обект в запис.
  • 5NF (Пета нормална форма): Известен също като „нормална форма за свързване на проекция“ (PJNF), той се отнася до реконструкцията на информация от по-малки, различно подредени части от данни.
  • 6NF (Шеста нормална форма): Теоретичен и неразпространен. Той се занимава с временни данни (обработва промени във времето) чрез допълнително разлагане на таблици, за да елиминира всички невремеви излишъци.

Теорията за нормализиране на данните в MySQL сървърът все още се разработва допълнително. Например има дискусии дори на 6th Нормална форма. В повечето практически приложения обаче нормализирането постига най-доброто си в 3rd Нормална форма. Еволюцията на нормализирането в SQL теориите е илюстрирана по-долу-

Нормални форми на база данни
Нормални форми на база данни

Нормализация на база данни с примери

База данни Пример за нормализиране може лесно да се разбере с помощта на казус. Да предположим, че една видеотека поддържа база данни с филми, дадени под наем. Без нормализиране в базата данни цялата информация се съхранява в една таблица, както е показано по-долу. Нека разберем базата данни за нормализиране с пример за нормализиране с решение:

Нормализация на база данни с пример

Ето вижте Колоната „Наети филми“ има множество стойности. Сега нека преминем към 1-ви нормални форми:

Първа нормална форма (1NF)

  • Всяка клетка от таблицата трябва да съдържа една стойност.
  • Всеки запис трябва да бъде уникален.

Горната таблица в 1NF-

1NF Пример

Правила на 1NF

Пример за 1NF в СУБД

Преди да продължим, нека разберем няколко неща -

Какво е КЛЮЧ в SQL

A КЛЮЧ в SQL е стойност, използвана за уникално идентифициране на записи в таблица. SQL KEY е единична колона или комбинация от множество колони, използвани за уникално идентифициране на редове или кортежи в таблицата. SQL Key се използва за идентифициране на дублирана информация и също така помага за установяване на връзка между множество таблици в базата данни.

Забележка: Колони в таблица, които НЕ се използват за еднозначно идентифициране на запис, се наричат ​​неключови колони.

Какво е първичен ключ?

Първичен ключ

Първичен ключ в СУБД

Основната е стойност на една колона, използвана за уникално идентифициране на запис в базата данни.

Има следните атрибути

  • A първичен ключ не може да бъде NULL
  • Стойността на първичния ключ трябва да бъде уникална
  • Стойностите на първичния ключ рядко трябва да се променят
  • Първичният ключ трябва да получи стойност, когато се вмъква нов запис.

Какво е композитен ключ?

Композитният ключ е първичен ключ, съставен от множество колони, използвани за уникално идентифициране на запис

В нашата база данни имаме двама души с едно и също име Робърт Фил, но те живеят на различни места.

Съставен ключ в базата данни

Съставен ключ в базата данни

Следователно ние изискваме както пълно име, така и адрес, за да идентифицираме уникално записа. Това е съставен ключ.

Нека преминем към втората нормална форма 2NF

Втора нормална форма (2NF)

  • Правило 1- Бъдете в 1NF
  • Правило 2 - Първичен ключ в една колона, който не е функционално зависим от никое подмножество на връзката на кандидат ключ

Ясно е, че не можем да продължим напред, за да направим нашата проста база данни в 2nd Форма за нормализиране, освен ако не разделим таблицата по-горе.

Правила на 2NF

Правила на 2NF

Разделихме нашата 1NF таблица на две таблици, т.е. Таблица 1 и Таблица 2. Таблица 1 съдържа информация за членовете. Таблица 2 съдържа информация за наетите филми.

Въведохме нова колона, наречена Membership_id, която е първичен ключ за таблица 1. Записите могат да бъдат уникално идентифицирани в таблица 1 с помощта на членски идентификатор

База данни – външен ключ

В таблица 2 Membership_ID е външният ключ

База данни – външен ключ

База данни – външен ключ

Външен ключ в СУБД

Външният ключ препраща към първичния ключ на друга таблица! Помага за свързването на вашите маси

  • Външният ключ може да има различно име от първичния ключ
  • Той гарантира, че редовете в една таблица имат съответни редове в друга
  • За разлика от първичния ключ, те не трябва да бъдат уникални. Най-често не са
  • Външните ключове могат да бъдат нулеви, въпреки че първичните ключове не могат

База данни – външен ключ

Защо се нуждаете от външен ключ?

Да предположим, че новак вмъква запис в таблица B като напр

Защо ви е необходим външен ключ

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

Горният проблем може да бъде преодолян чрез деклариране на id на членство от Table2 като външен ключ на id на членство от Table1

Сега, ако някой се опита да вмъкне стойност в полето за идентификатор на членство, която не съществува в родителската таблица, ще се покаже грешка!

Какво представляват преходните функционални зависимости?

Преходен функционална зависимост е при промяна на неключова колона, може да доведе до промяна на някоя от другите неключови колони

Разгледайте таблица 1. Промяната на неключовата колона Пълно име може да промени Поздрава.

Преходни функционални зависимости

Да преминем към 3NF

Трета нормална форма (3NF)

  • Правило 1- Бъдете в 2NF
  • Правило 2- Няма преходни функционални зависимости

За да преместим нашата 2NF таблица в 3NF, отново трябва отново да разделим нашата таблица.

3NF Пример

По-долу е пример за 3NF в SQL база данни:

3NF Пример

3NF Пример

3NF Пример

Отново разделихме нашите маси и създадохме нова таблица, която съхранява Поздрави.

Няма преходни функционални зависимости и следователно нашата таблица е в 3NF

В таблица 3 ID на поздрава е първичен ключ, а в таблица 1 ID на поздрав е чужд на първичния ключ в таблица 3

Сега нашият малък пример е на ниво, което не може да бъде допълнително разложено, за да се постигнат по-високи типове нормална форма на нормализация в СУБД. Всъщност той вече е в по-високи нормални форми. Обикновено са необходими отделни усилия за преминаване към следващи нива на нормализиране на данни в сложни бази данни. Но по-долу ще обсъдим накратко следващите нива на нормализиране в СУБД.

Нормална форма на Бойс-Код (BCNF)

Дори когато базата данни е в 3rd Нормална форма, все пак ще има аномалии, ако има повече от една Кандидат Ключ.

Понякога BCNF се нарича също така 3.5 Нормална форма.

Четвърта нормална форма (4NF)

Ако нито един екземпляр на таблица на база данни не съдържа две или повече независими и многозначни данни, описващи съответния обект, тогава той е в 4th Нормална форма.

Пета нормална форма (5NF)

Една маса е в 5th Нормална форма само ако е в 4NF и не може да бъде разложена на произволен брой по-малки таблици без загуба на данни.

Предложена шеста нормална форма (6NF).

6th Нормалната форма не е стандартизирана, но въпреки това се обсъжда от експерти по бази данни от известно време. Надяваме се, че ще имаме ясна и стандартизирана дефиниция за 6th Нормална форма в близко бъдеще...

Предимства на нормалната форма

  • Подобряване на съгласуваността на данните: Нормализирането гарантира, че всяка част от данните се съхранява само на едно място, намалявайки шансовете за непоследователни данни. Когато данните се актуализират, те трябва да се актуализират само на едно място, като се гарантира последователност.
  • Намаляване на излишъка от данни: Нормализирането помага за елиминирането на дублирани данни, като ги разделя на множество свързани таблици. Това може да спести място за съхранение и също така да направи базата данни по-ефективна.
  • Подобрете ефективността на заявките: Нормализираните бази данни често са по-лесни за заявки. Тъй като данните са организирани логически, заявките могат да бъдат оптимизирани за по-бързо изпълнение.
  • Направете данните по-смислени: Нормализацията включва групиране на данни по начин, който има смисъл и е интуитивен. Това може да направи базата данни по-лесна за разбиране и използване, особено за хора, които не са проектирали базата данни.
  • Намалете шансовете за аномалии: Аномалиите са проблеми, които могат да възникнат при добавяне, актуализиране или изтриване на данни. Нормализирането може да намали шансовете за тези аномалии, като гарантира, че данните са логично организирани.

Недостатъци на нормализирането

  • Повишена сложност: Нормализирането може да доведе до сложни отношения. Голям брой таблици с външни ключове могат да бъдат трудни за управление, което води до объркване.
  • Намалена гъвкавост: Поради строгите правила за нормализиране може да има по-малко гъвкавост при съхраняване на данни, които не се придържат към тези правила.
  • Повишени изисквания за съхранение: Въпреки че нормализирането намалява излишъка, може да се наложи да се разпредели повече място за съхранение, за да се поберат допълнителните таблици и индекси.
  • Разход за производителност: Обединяването на множество таблици може да бъде скъпо по отношение на производителността. Колкото по-нормализирани са данните, толкова повече присъединявания са необходими, което може да забави времето за извличане на данни.
  • Контекст на загуба на данни: Нормализирането разбива данните в отделни таблици, което може да доведе до загуба на бизнес контекст. Изследването на свързани таблици е необходимо, за да се разбере контекстът на дадена част от данните.
  • Необходимост от експертни познания: Внедряването на нормализирана база данни изисква задълбочено разбиране на данните, връзките между данните и правилата за нормализиране. Това изисква експертни познания и може да отнеме много време.

Това е всичко за нормализирането на SQL!!!

Заключение

  • Проектиране на база данни е от решаващо значение за успешното внедряване на система за управление на база данни, която отговаря на изискванията за данни на корпоративна система.
  • Нормализирането в СУБД е процес, който помага за създаването на системи от бази данни, които са икономически ефективни и имат по-добри модели за сигурност.
  • Функционалните зависимости са много важен компонент от процеса на нормализиране на данните
  • Повечето системи за бази данни са нормализирани бази данни до третата нормална форма в СУБД.
  • Първичният ключ уникално идентифицира записа в таблица и не може да бъде нула
  • Външен ключ помага за свързване на таблица и препратки към първичен ключ