КАКВА Е ТРЕТАТА НОРМАЛНА ФОРМА? (БАЗИ ДАННИ) - ТЕХНОЛОГИЯ - 2025

На трета нормална форма (бази данни) е релационна база данни дизайн техника, където различните таблици, които я съставляват, не само в съответствие с втора нормална форма, но всичките му атрибути или полета в пряка зависимост от първичния ключ.

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

Източник: pixabay.com

За постигането на тази цел могат да се използват някои техники за проектиране на база данни, сред които е нормализирането.

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

Тя започва с изследване на функционалната връзка или зависимост между атрибутите. Те описват някакво свойство на данните или връзката между тях.

Нормални форми

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

Тоест, техниката на нормализиране е изградена около концепцията за нормална форма, която определя система от ограничения. Ако една връзка отговаря на ограниченията на определена нормална форма, се казва, че връзката е в тази нормална форма.

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

Казва се, че таблицата е в 1FN, ако всички атрибути или полета в нея съдържат само уникални стойности. Тоест, всяка стойност за всеки атрибут трябва да е неделима.

По дефиниция релационна база данни винаги ще се нормализира до първата нормална форма, защото стойностите на атрибутите винаги са атомни. Всички взаимоотношения в база данни са в 1FN.

Обаче просто напускането на базата данни по този начин стимулира редица проблеми, като излишък и възможни грешки при надстройката. По-високи нормални форми са разработени за коригиране на тези проблеми.

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

Той се занимава с премахването на кръгови зависимости от таблица. Казват, че връзката е в 2FN, ако е в 1FN и освен това всяко не-ключово поле или атрибут зависи изцяло от първичния ключ, или по-точно, то гарантира, че таблицата има една единствена цел.

Не ключов атрибут е всеки атрибут, който не е част от първичния ключ за връзка.

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

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

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

Трябва да потърсите повтарящи се стойности в атрибути, които не са ключови, за да сте сигурни, че тези не-ключови атрибути не зависят от нищо друго, освен от първичния ключ.

Казват, че атрибутите са взаимно независими, ако никой от тях не зависи функционално от комбинация от други. Тази взаимна независимост гарантира, че атрибутите могат да се актуализират индивидуално, без опасност да засегнат друг атрибут.

Следователно, за да има връзка в база данни в трета нормална форма, тя трябва да отговаря на:

- Всички изисквания на 2FN.

- Ако има атрибути, които не са свързани с първичния ключ, те трябва да бъдат премахнати и поставени в отделна таблица, свързана с двете таблици с помощта на чужд ключ. Тоест, не трябва да има преходни зависимости.

Примери за трета нормална форма

Пример 1

Таблицата нека бъде STUDENT, чийто основен ключ е идентификацията на ученика (STUDENT_ID) и се състои от следните атрибути: STUDENT_NAME, STREET, CITY и POST_CODE, отговарящи на условията да бъдат 2FN.

В този случай STREET и CITY нямат пряка връзка с първичния ключ STUDENT_ID, тъй като те не са пряко свързани с ученика, но са изцяло зависими от пощенския код.

Тъй като студентът е разположен от сайта, определен от CODE_POSTAL, STREET и CITY са свързани е с този атрибут. Поради тази втора степен на зависимост не е необходимо тези атрибути да се съхраняват в таблицата СТУДЕНТ.

Създайте нова таблица

Да предположим, че има няколко ученици, разположени в един и същ пощенски код, като таблицата СТУДЕНТ има огромно количество записи и е необходимо да промените името на улицата или града, тогава тази улица или град трябва да бъде намерена и актуализирана в цялата таблица СТУДЕНТ.

Например, ако трябва да смените улицата „El Limón“ на „El Limón II“, ще трябва да потърсите „El Limón“ в цялата таблица на СТУДЕНТИТЕ и след това да я актуализирате на „El Limón II“.

Търсенето в огромна таблица и актуализирането на единични или множество записи ще отнеме много време и следователно ще се отрази на работата на базата данни.

Вместо това тези подробности могат да се съхраняват в отделна таблица (POSTCARD), която е свързана с таблицата STUDENT, използвайки атрибута POST_CODE.

Таблицата POST ще има сравнително по-малко записи и тази таблица POST ще трябва да бъде актуализирана само веднъж. Това ще бъде отразено автоматично в таблицата СТУДЕНТ, опростявайки базата данни и заявки. Така че таблиците ще бъдат в 3FN:

Пример 2

Нека следната таблица се използва с полето Project_Num като първичен ключ и с повтарящи се стойности в атрибути, които не са ключове.

Стойността на телефона се повтаря всеки път, когато името на мениджъра се повтаря. Това е така, защото телефонният номер има зависимост само от втора степен от номера на проекта. Наистина първо зависи от мениджъра, а това от своя страна зависи от номера на проекта, което прави преходна зависимост.

Атрибут Project_Manager не може да бъде възможен ключ в таблицата Проекти, тъй като един и същ мениджър управлява повече от един проект. Решението за това е да премахнете атрибута с повтарящите се данни (Phone), създавайки отделна таблица.

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

За да се съобрази с третата нормална форма, се създава нова таблица (Мениджъри), която да реши проблема. И двете таблици са свързани чрез полето Project_Manager:

Препратки

1. Терадата (2019). Първа, втора и трета нормални форми. Взета от: docs.teradata.com.
2. Учебна купа (2019). Трета нормална форма (3NF). Взета от: tutorialcup.com.
3. База данни Dev (2015). Трета нормална форма (3NF) - нормализиране на вашата база данни. Взето от: databasedev.co.uk.
4. Релационен DB Design (2019). Въведение в третата нормална форма. Взета от: relationaldbdesign.com.
5. Манекени (2019). Първа, втора и трета нормални форми SQL. Взета от: dummies.com.