Целосна функционална зависност е состојба на база на нормализација која е еднаква на нормализацијата на стандардот на Втората нормална форма (2NF) . Накратко, тоа значи дека ги исполнува барањата на првата нормална форма (1NF), а сите не-клучни атрибути целосно функционираат зависно од примарниот клуч.
Ова не е толку комплицирано што може да звучи. Да го разгледаме ова подетално.
Резиме на првата нормална форма
Пред да може базата на податоци да биде целосно функционално зависна, таа најпрво мора да се придржува кон првата нормална форма .
Сето ова значи дека секој атрибут мора да има една, атомска вредност.
На пример, следнава табела не е во согласност со 1NF, бидејќи вработениот Тина е поврзан со две локации, и двете во една единствена ќелија:
Вработен | Локација |
---|---|
Џон | Лос Анџелес |
Тина | Лос Анџелес, Чикаго |
Овозможувањето на овој дизајн може негативно да влијае на ажурирањата или записите на податоците. За да се обезбеди усогласеност со 1NF, преуредете ја табелата така што сите атрибути (или клетки на колоните) имаат една вредност:
Вработен | Локација |
---|---|
Џон | Лос Анџелес |
Тина | Лос Анџелес |
Тина | Чикаго |
Но 1NF сè уште не е доволно за да се избегнат проблеми со податоците.
Како 2NF работи за да се обезбеди целосна зависност
За да бидат целосно зависни, сите атрибути на клучни зборови кои не се кандидираат мора да зависат од примарниот клуч. (Запомнете, клучниот атрибут на кандидатот е кој било клуч (на пример, примарен или странски клуч) што се користи за уникатно идентификување на запис од базата на податоци.
Дизајнерите на бази на податоци користат ознака за опишување на зависните врски помеѓу атрибутите:
Ако атрибутот А ја одредува вредноста на В, го запишуваме ова А -> В - што значи дека Б функционално зависи од А. Во оваа врска, А ја одредува вредноста на В, додека В зависи од А.
На пример, во следната табела на вработените, EmployeeID и DeptID се клучни кандидати: EmployeeID е примарен клуч на табелата, додека DeptID е странски клуч.
Секој друг атрибут - во овој случај, EmployeeName и DeptName - мора да зависи од примарниот клуч за да ја добие неговата вредност.
EmployeeID | Име на Вработен | DeptID | DeptName |
---|---|---|---|
Emp1 | Џон | Dept001 | Финансии |
Emp2 | Тина | Dept003 | Продажба |
Emp3 | Карлос | Dept001 | Финансии |
Во таков случај, табелата не е целосно зависна, бидејќи, додека EmployeeName зависи од примарниот клуч EmployeeID, DeptName зависи, наместо, на DeptID. Ова се нарекува делумна зависност .
За да се направи оваа табела во согласност со 2NF, треба да ги разделиме податоците во две табели:
EmployeeID | Име на Вработен | DeptID |
---|---|---|
Emp1 | Џон | Dept001 |
Emp2 | Тина | Dept003 |
Emp3 | Карлос | Dept001 |
Отстрануваме атрибут DeptName од табелата " Вработени" и креираме нова табела Оддели :
DeptID | DeptName |
---|---|
Dept001 | Финансии |
Dept002 | Човечки ресурси |
Dept003 | Продажба |
Сега односите меѓу табелите се целосно зависни, или во 2NF.
Зошто е важно целосната зависност
Целосната зависност помеѓу атрибутите на базата помага да се обезбеди интегритет на податоците и да се избегнат аномалии на податоците.
На пример, разгледајте ја табелата во горниот дел што се придржува само до 1NF. Тука е, повторно:
Вработен | Локација |
---|---|
Џон | Лос Анџелес |
Тина | Лос Анџелес |
Тина | Чикаго |
Тина има две записи. Ако го ажурираме еден без да сфатиме дека има два, резултатот ќе биде неконзистентни податоци.
Или, што ако сакаме да додадеме вработен на оваа табела, но сеуште не ја знаеме локацијата? Ние може да биде забрането дури и да додадете нов вработен ако атрибутот Локација не дозволува NULL вредности.
Сепак, целосната зависност не е целата слика, кога станува збор за нормализација. Мора да бидете сигурни дека вашата база на податоци е во трета нормална форма (3NF).