Википедија

Нормализација на бази на податоци

Во дизајнот на релационите бази со податоци (RDBMS), нормализација на бази со податоци е процесот на организирање на податоците за да се намали оптоварувањето. Целта на нормализацијата на базите со податоци е да се прекинат врските со аномалии со цел да се направат помали,добро структуирани релации. Нормализацијата обично вклучува делење на големите табели во помали табели и дефинирање на врските помеѓу нив .Задачата е да се изолираат податоците со цел собирањата ,бришењата и измените на полето да можат да бидат направени само во една табела и како такви да функционираат низ целата база со податоци , дефинирана со релации.

Едгар Ф. Код (Edgar F. Codd), пронаоѓачот на релациониот модел ,го прикажал концептот на нормализација што нам ни е познат како Прва Нормална Форма (1NF) во 1970год . Код работел на тоа да ја дефинира Втората Нормална Форма(2NF) и Третата Нормална Форма (3NF) во 1971год. Код и Рејмонд Ф.Бојс ја дефинираат Бојс-Кодoвата Нормална Форма (BCNF) во 1974 година. Повисоките нормални форми биле дефинирани од други теоретичари во следните години. Најчеста била Шестата Нормална Форма (6NF), претставена од Крис Дејт, Хју Дарвен и Никос Лоренцос во 2002 година.

Неформално, табелата на релационата база со податоци (компјутерско остварување на релациите) често е опишано како “нормализирано” ако тоа е во Третата Нормална Форма. Повеќето 3NF табели немаат потреба од внесување, надградување и бришење на аномалии. На пример, во поголемиот дел од случаите 3NF табелите додаваат BCNF, 4NF и 5NF, но не и 6NF.

Стандардната база на податоци е направена така што творецот би можел да направи целосно нормализиран дизајн; селективна денормализација која подоцна може да се искористи за да се прават измени на табелата. Како и да е, некој видови на моделирање како што е на пример димензионалното моделирање, пристапуваат до складиштето на податоци кое е препорачано за ненормализирани дизајни. Тие во голема мерка не се залепени со 3NF.

Цел на нормализација

Примарната цел на Првата Нормална Форма дефинирана од Код во 1970г. е да овозможи податоците да бидат складирани и манипулирани користејќи “универзален под-јазик за податоци” втемелен во првобитната логика. (SQL е пример за таков под-јазик за податоци). Објекти на нормализација над 1NF според Код, се класифицирани на следниот начин:

1. Да го ослободи збирот на релации од несакани внесување, ажурирања, како и бришење на зависности;

2. За да се намали потребата за реструктуирање на релации како што се нови видови на податоци , а со тоа зголемување на работниот век при примената на програмите;

3. Да се ​​направи релационен модел повеќе информативен за корисниците;

4. Да се ​​направи колекција на релациите неутрални за пребарувањето и статистиката, каде што овие статистики се должни да се променат како што времето одминува.

-E.F. Codd "Понатамoшна нормализација на База На Податоци (Релационен модел)"

Деловите подолу прикажуваат детали за секоја од овие цели.

Ослободување на базата на податоци од аномалии

Кога се прави обид да се измени (ажурирање, внесување во , или да се избрише од) табела, можна е појава на непожелни ефекти. Не сите табели може да страдаат од овие несакани ефекти, туку на несакани ефекти само може да се појават во табели кои не се доволно нормализирани. Недоволно Нормална табела може да има една или повеќе од следните одлики:

• Истите информации може да се изразат во повеќе редови, па затоа ажурирање на табелата може да резултира со логички недоследности. На пример, секој запис во "Employees Skills " табелата може да содржи Employee ID, Employee Address и Skill, така што промената на адресата за одреден вработен потенцијално ќе треба да се примени на повеќе записи (по еден запис за секоја од неговите вештини). Ако ажурирањето не се изврши успешно,вредностите ќе се изменат само на некои записи. Поточно, табелата дава спротивставени одговори. Овој феномен е познат како ажурирање на аномалија.

• Постојат околности во кои одредени факти не можат да бидат запишани на сите полиња. На пример, секој запис во "Faculty and Their Courses" табелата може да содржи FacultyID, Faculty Name, Faculty Hire Date , и Course code. На тој начин можеме да ги снимиме деталите за кој било член на факултетот кој предава на најмалку еден курс, но не може да снимаме деталите на ново-вработените членови на факултетот кои сè уште не се назначени да ги предаваат сите предмети. Овој феномен е познат како вметнување на аномалија.

• Постојат околности во кои бришење на податоци претставува поставување на сосема различни факти. На "Faculty and Their Courses" табелата како што е опишано во претходниот пример страда од овој вид на аномалија, бидејќи ако факултетскиот член привремено престане да предава на сите курсеви, ние мораме да ја избришете последната на евиденција за која факултетскиот член се појавува. Овој феномен е познат како бришење на аномалија.

Намалување на редизајнот кога се проширува базата на податоци

Кога целосно Нормална основа на податоци се проширува, потребно е присбосување на новите типови на податоци. Постоечките аспекти на базата на податоци можат во голема мера или целосно да останат непроменети. Како резултат на тоа, апликациите и нивните интеракциии со базата на податоци се со минимални.

Правење на модел со податоци со повеќе информации кон корисниците

Нормализирани табели, како и односот помеѓу Нормална табела и друга е огледало на реалниот концепт и нивните меѓусебни врски.

'Избегнување пристрасност кон некоја посебна шема

Нормализираните табели се погодни за општа намена. Ова значи дека какви било замерки против овие табели, вклучувајќи идни променливи чии детали не можат да се предвидат, се поддржани. Спротивно на тоа, табели кои не се нормализирани се приспособуваат на некои видови, на некои и не.

На пример, да земеме онлајн книжара, чии клиенти се содржани во списоци со саканите книги кои би сакале да ги имаат. Очигледно, се очекува побарување на книги. Што го прави овој клиент заинтересиран?-тоа е доволно за складирање на список на купувачи во табела како, да речеме, хомогена низа на авторите и насловите.

Со овој дизајн, сепак, базата на податоци може да одговори само на едно единствено пребарување. Таа не може сама по себе да се интересира.

Како Лорд Бајрон застанал против неговите современи поети? Одговорите на овие прашања мораат да дојдат од посебени адаптивни алатки сосема различни од базата на податоци. Една од алатките може да биде софтвер напишан за да се справи со таквите пребарувања. Овој специјален адаптивен софтвер има само една единствена цел: ефектно нормализирање на не-нормализирано поле. Непредвидливи прашања може да се одговорат тривијално, во базата на податоци, со Нормална табела.

Пребарување и манипулирање со податоци во рамките на ненормална податочна структура, како што се следниве ненормализирани форми за застапености на клиентите, трансакции со кредитни картички, вклучува повеќе комплексност отколку што е навистина потребно: Секој клиент одговара на група на повторување на трансакции. За автоматско оценување во врска со трансакциите на клиентите настапуваат 2 фази:

1. Отпакување на една или повеќе групи на клиенти на трансакции со што се овозможува поединечни трансакции во една група да бидат испитани.

2. Изведување на пребарувачки резултат врз основа на резултатите од првата фаза.

На пример, со цел да се дознае монетарниот збир на сите трансакции што се случиле во октомври 2003 година за сите клиенти, системот би требало да знае дека мора прво да ја отпакува групата со трансакции на секој клиент, па да направи збир на износите на сите трансакции што се добиени и кои од нив имаат датум на трансакција во октомври 2003 година.

Еден од важните увиди на Код беше дека оваа структурна комплексност секогаш може да се отстрани целосно, што доведува до многу поголема моќ и флексибилност во начинот на табелирање и како би можеле да бидат формулирани (од страна на корисниците и апликациите) и вреднувани (од страна на DBMS).

Заднина на нормализација: Дефиниции

Функционална зависност

Функционалната зависност е дефинирана како:

Атрибутот Х на релацијата е функционално зависен од атрибутот Y (клуч) на таа релација, ако атрибутот X има само една вредност поврзана со одредена вредност на атрибутот Y.Со други зборови, ако вредноста на атрибутот Y е познатa, поврзаната вредност на атрибутот Х може да се утврди. На пример, во една табела за вработени, EMPLOYEE START DATE е функционално зависно од EMPLOYEE NUMBER. За секој EMPLOYEE NUMBER е само еден EMPLOYEE START DATE. За да пристапиме до EMPLOYEE START DATE, треба да го знаеме EMPLOYEE NUMBER, што всушност претставува клуч. Атрибутот може да биде функционално зависен од група на атрибути, а не само од еден атрибут.

Тривијалнa функционална зависност

Тривијалнаta функционална зависност е функционална зависност на атрибут која повторно покажува сама на себе. {Employee ID,Employee Adress} → {Employee Adress} е тривијална, како што е {Employee Adress} → {Employee Adress}.

Целосна функционална зависност

Атрибутот е целосно функционално зависен од множество на атрибути X ако тоа е:

• функционално зависно од X, и

• не е функционално зависно од било кое соодветно подмножество на X. {Employee Adress} има функционална зависност од {Employee ID, Skill}, но не и целосно функционална зависност, поради тоа што е, исто така, зависи од {Employee ID}.

Преодна зависност

Преодната зависност е индиректна функционална зависност, во која x → Z само врз основа на X → Y и Y → З.

Зависност со повеќе вредности

Зависноста со повеќе вредности е пречка според која присуството на одредени редови во табелата подразбираат присуство на некои други редови.

Приклучна зависност

Табелата Т е предмет на приклучна зависност ако Т секогаш може да се создава повторно од спојување на повеќе табели, а секоја од нив има подмножество со особини на Т.

''''Суперклуч

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

Кандидат клуч

Кандидат клучот е посебна подгрупа на суперклучот кој нема никакви информации во него: тоа е минимален суперклуч.

Примери: Замислете табела со полиња <Name>, <Age>, <SSN> и <Phone Extension>. Оваа табела има многу можни суперклучеви. Три од нив се <SSN>, <Phone Extension, name> и <SSN, name>. Од оние кои се наведени, само <SSN> е кандидат клуч, додека другите содржати не толку потребни информации за идентификација. ("SSN овде се однесува на бројот на социјалното осигурување, кој е единствен за секој човек).

Не примарен атрибут

Не-премарен атрибут е атрибут кој го нема во кој било кандидат клуч. Employee Address би бил не-примарен атрибут во "Employee Skills "табела.

Примарен атрибут

Примарниот атрибут е атрибут кој го има во некои кандидат клучеви.

Примарен клуч

Повеќето DBMS бараат табела за да се дефинира еден единствен клуч, а не број на можни уникатен клучеви. Примарен клуч е клуч кој дизајнерот на базата на податоци го створил со оваа цел.

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

Нормални форми (abbrev. NF) на релациона основа на податоци е теорија која треба да обезбеди критериуми за утврдување на степенот на ранливоста на табелата како и логички недоследности и аномалии. Колку повисоко се наоѓа Нормална форма на табелата, толку помалку е ранлива и поседува помалку недоследности и аномалии. Секоја табела има "највисок нормален облик" (HNF)

Нормалните форми се применуваат за поединечни табели; За да се каже дека целата база на податоци е во Нормална форма n треба сите нејзини табели да се во Нормална форма Н.

Главните нормални форми се сумирани подолу:

Денормализација

Бази на податоци наменети за онлајн трансакција (OLTP) се обично повеќе се нормализирани од базите на податоци наменети за онлајн аналитичка обработка (OLAP). OLTP апликации се одликуваат со голем обем на мали трансакции, како што се ажурирање на продажбата во супермаркет . Во очекување е дека секоја трансакција ќе ја напушти базата на податоци во константна состојба. Спротивно на тоа, базите на податоци наменети за OLAP операции се "претежно за читање" бази на податоци. OLAP апликациите имаат тенденција да извлечат историски податоци што го имаат акумулирано во текот на долг временски период .

Димензионални табели во ѕвезда шема често содржат ненормализрани податоци. Во многу случаи, потребата за денормализација е исчезната како компјутери и RDBMS софтверот се помоќни, но бидејќи податоците растат, генерално, е зголемена потребата на хардверски и софтверски перформанси. OLAP база на податоци сè уште користи ненормализрани шеми.

Денормализација се користи за да се подобри ефикасноста на помали компјутери, како во електронска кеш регистри и мобилни уреди, бидејќи тие можат да ги користат податоците само за гледање. Денормализација, исто така, може да биде се користи кога нема RDBMS платформа (како Palm PC).

Облик кој не е во прва нпрмална форма (NF2 или N1NF)

Денормализација може да биде наменска и корисна, облик кој не е во прва нормална форма е дефиниција за база на податоци со дизајни кој не се во согласност со првата Нормална форма, со тоа што дозволува да има атрибути со домени" (Schek 1982). Јазиците се користат за пребарување и манипулирање со податоци, модел мора да се прошири во согласност со таквите вредности. Еден од начинити на гледање на овој принцип е да се разгледа како структурирана вредност, како и специјализирани типови на вредности (домени), со свој домен-специфичен јазик. Сепак, она што обично се подразбира под не-1NF модел е пристапот во кој релациониот модел и јазиците кои се користат за барањето да се прошири со општ механизам за таква структура; На пример, вгнезден релационен модел поддржува употреба на односи како што се домен вредности, со додавање на два дополнителни оператори (nest и unnest) на релационата алгебра што може да создаде и израмнити вгнездени односи, соодветно.

Размислете за следната табела:

Да претпоставиме дека некое лице има неколку омилени бои. Очигледно, омилените бои се состојат од сет на бои моделирани од дадената табела. Да се ​​трансформира 1NF во NF ² табела е потребнen "nest" операторот кој се протега на релационата алгебра на високо нормални форми. Примена на "nest" оператор на 1NF табела дава следниве NF ² табела:

Да се ​​трансформира оваа NF ² табела назад во 1NF е потребен "unnest" операторот кој се протега на релационата алгебра на повисока Нормална форма. Unnest, во овој случај, ќе биде "colours" во табелата.

Иако "unnest" е математички инверзна операција на "nest", операторот "nest" не е секогаш математички инверзна операција на "unnest". Друга пречка потребна на операторите е да се двострани, што е опфатено со Парцијалната Нормална форма (PNF).

Користена литература

уреди
Преземено од „https://mk.wikipedia.org/w/index.php?title=Нормализација_на_бази_на_податоци&oldid=5140951“