Шта је нормализација?
Нормализација је техника дизајнирања базе података која смањује сувишност података и уклања нежељене карактеристике попут Аномалија уметања, ажурирања и брисања. Правила нормализације деле веће табеле на мање табеле и повезују их помоћу односа. Сврха нормализације у СКЛ-у је уклањање сувишних (понављајућих) података и осигуравање логичког складиштења података.
Изумитељ релационог модела Едгар Цодд предложио је теорију нормализације података увођењем Прве нормалне форме, а наставио је да проширује теорију Другом и Трећом нормалном формом. Касније се придружио Раимонду Ф. Боицеу да би развио теорију Боице-Цоддове нормалне форме.
Уобичајени обрасци базе података
Ево листе нормалних образаца
- 1НФ (први уобичајени образац)
- 2НФ (друга нормална форма)
- 3НФ (трећа нормална форма)
- БЦНФ (Боице-Цодд-ова нормална форма)
- 4НФ (четврта нормална форма)
- 5НФ (пети уобичајени образац)
- 6НФ (шести нормални образац)
Теорија нормализације података у СКЛ серверу се и даље даље развија. На пример, постоје разговори чак и на 6 тх нормална форма. Међутим, у већини практичних примена нормализација постиже најбоље у 3. нормалном облику . Еволуција теорија нормализације СКЛ приказана је испод -

Нормализација базе података са примерима
Пример нормализације базе података може се лако разумети уз помоћ студије случаја. Претпоставимо да видеотека одржава базу података о филмовима који се изнајмљују. Без икакве нормализације у бази података, све информације се чувају у једној табели као што је приказано доле. Да разумемо Нормализацију у бази података на примеру табела:
Овде видите колона „Филмови изнајмљени“ има више вредности. Сада кренимо у 1. нормалне форме:
1НФ (Фирст Нормал Форм) правила
- Свака ћелија табеле треба да садржи једну вредност.
- Сваки запис мора бити јединствен.
Горња табела у 1НФ-
Пример 1НФ
Пре него што наставимо, схватимо неколико ствари -
Шта је КЉУЧ?
КЉУЧ је вредност која се користи за јединствену идентификацију записа у табели. КЉУЧ може бити појединачна колона или комбинација више колона
Напомена: Колоне у табели које се НЕ користе за јединствену идентификацију записа називају се некључним колонама.
Шта је примарни кључ?

Примарни је вредност једне колоне која се користи за јединствену идентификацију записа базе података.
Има следеће атрибуте
- Примарни кључ не може бити НУЛЛ
- Вредност примарног кључа мора бити јединствена
- Вредности примарног кључа ретко треба мењати
- Примарни кључ мора добити вредност када се убаци нови запис.
Шта је композитни кључ?
Састављени кључ је примарни кључ састављен од више колона који се користи за јединствену идентификацију записа
У нашој бази података имамо две особе са истим именом Роберт Пхил, али оне живе на различитим местима.
Дакле, захтевамо и пуно име и адресу да бисмо јединствено идентификовали запис. То је сложени кључ.
Идемо у други нормални облик 2НФ
2НФ (друга нормална форма) правила
- Правило 1- Будите у 1НФ
- Правило 2- Примарни кључ једне колоне
Јасно је да не можемо да кренемо напред да бисмо направили нашу једноставну базу података у другом облику нормализације ако не раздвојимо горњу таблицу.
Подијелили смо нашу 1НФ табелу на двије табеле. Табела 1 и Табела 2. Табела 1 садржи податке о члановима. Табела 2 садржи информације о изнајмљеним филмовима.
Увели смо нову колону под називом Мемберсхип_ид која је примарни кључ за табелу 1. Записи се могу јединствено идентификовати у табели 1 помоћу ИД-а чланства
База података - страни кључ
У табели 2, Чланство_ИД је страни кључ
Страни кључ упућује на примарни кључ друге табеле! Помаже у повезивању табела
- Страни кључ може да се разликује од примарног кључа
- Осигурава да редови у једној табели имају одговарајуће редове у другој
- За разлику од примарног кључа, они не морају бити јединствени. Најчешће нису
- Страни кључеви могу бити ништавни иако примарни кључеви не могу
Зашто вам треба страни кључ?
Претпоставимо да почетник убаци запис у табелу Б као што је
У спољни кључ моћи ћете да уметнете само вредности које постоје у јединственом кључу у надређеној табели. Ово помаже у референцијалном интегритету.
Горе наведени проблем може се превазићи декларацијом ИД-а чланства из Табеле2 као страног кључа ИД-а чланства из Табеле1
Сада, ако неко покуша да у поље вредности ид-а чланства убаци вредност која не постоји у надређеној табели, приказаће се грешка!
Шта су прелазне функционалне зависности?
Прелазна функционална зависност може променити било који други ступац који није кључ када мења не-кључни ступац
Размотрите табелу 1. Промена не-кључног ступца Пуно име може променити Поздрав.
Идемо у 3НФ
3НФ (трећа нормална форма) правила
- Правило 1- Будите у 2НФ
- Правило 2- Нема прелазне функционалне зависности
Да бисмо нашу 2НФ табелу преместили у 3НФ, поново морамо да поделимо нашу табелу.
Пример 3НФ
Испод је пример 3НФ у СКЛ бази података:
Поново смо поделили наше столове и створили нови сто који чува Поздраве.
Не постоје прелазне функционалне зависности, па је стога наша табела у 3НФ
У табели 3 ИД поздрава је примарни кључ, а у табели 1 ИД поздрава је примарни кључ у табели 3
Сада је наш мали пример на нивоу који се не може даље разлагати да би се постигли виши нормални облици нормализације. У ствари, то је већ у вишим облицима нормализације. Одвојени напори за прелазак на наредне нивое нормализације података обично су потребни у сложеним базама података. Међутим, о следећим нивоима нормализација ћемо укратко разговарати у наставку.
БЦНФ (Боице-Цодд-ова нормална форма)
Чак и када је база података у 3. нормалном облику, и даље би долазило до аномалија ако има више од једног кључа кандидата .
Понекад се БЦНФ назива и 3,5 нормалним обликом.
Правила 4НФ (четврта нормална форма)
Ако постоји табела база случај садржи два или више, независна и више-податке који описују релевантне ентитет, онда је у 4 -ом нормалној форми.
5НФ (пети уобичајени образац) правила
Табела је у 5. нормалном облику само ако је у 4НФ и не може се разложити у било који број мањих табела без губитка података.
Предложен 6НФ (шести нормални образац)
6 -ог нормална форма није стандардизована, али ипак, она се расправља стручњаци база података за неко време. Надам се да ће имати јасну и стандардизовани дефиницију за 6 -ог нормална форма у блиској будућности ...
То је све за СКЛ нормализацију !!!
Резиме
- Дизајн базе података је пресудан за успешну примену система за управљање базама података који испуњава захтеве података у систему предузећа.
- Процес нормализације у ДБМС-у помаже у стварању система база података који су исплативи и имају боље сигурносне моделе.
- Функционалне зависности су врло важна компонента процеса нормализације података
- Већина система база података су нормализоване базе података до трећег нормалног облика.
- Примарни кључ јединствено идентификује запис у табели и не може бити нулл
- Страни кључ помаже у повезивању табеле и референци на примарни кључ