Eng vollstänneg Ofhängegkeet ass e Status vun der Datebanknormaliséierung, déi parallel zum Normaliséierungstand vun der zweeter Normalform ass (2NF) . Kuerz gesot heescht dat, datt et den Ufuerderunge vun der éischter normal Form (1NF) entsprécht, an all net-Schlëssel Attribute sinn voll funktionsend vun der Primärschrei.
Dëst ass net esou komplizéiert wéi et kléngt. Loosst eis dat a méi Detail detailléieren.
Zesummefaassung vun éischter normal Form
Virun enger Datebank kann ganz funktionell abegraff sinn, muss et éischt Zert. Normal Form benotzen .
All dat heescht datt all Attribut een eenzegen atomesche Wäert huet.
Zum Beispill gëtt déi folgend Tabelle net mat 1NF erfaasst, well de Mataarbechter Tina op zwou Locatiouns verbonne gëtt, souwuel si an enger eenzeger Zelle:
| Employé | Standuert |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Allgemeng kann dësen Dateschutz negativ op Aktualiséierungen oder Eegeschafte beaflossen. Fir 1NF Konformitéit ze garantéieren, ordinéiert den Dësch un, fir datt all Attribute (oder Spalte Zellen) een eenzegen Wäert behalen:
| Employé | Standuert |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Mee 1NF ass ëmmer net genuch fir Problemer mat den Daten ze vermeiden.
Wéi 2NF schafft fir déi ganz Ofhängegkeet ze garantéieren
Fir ganz ugewiesen ze sinn, mussen all net beruffleche Schlësselelementer ofgeschloss sinn. (Bedenkt datt e Kandidatschloss Attribut ass e Schlëssel (zum Beispill e primäre oder auslännescht Taste) benotzt fir e Datebank ze identifizéieren.
Datebank Designers benotzen eng Notioun fir d'reliant Bezéiungen tëschent Attributer ze beschreiwen:
Wann d'Attribut bestëmmt de Betrag vun B, schreift Dir dësen A -> B - datt B am Funktionalement vun A. funktionnéiert. An dëser Bezéiung A bestëmmt de Wäert vun B, während B vun A abhängt.
Zum Beispill, an der folgender Tabelle vum Employee Departments , EmployeeID an DeptID sinn e Kandidatschlüssel: EmployeeID ass de Primärschlüssel vum Dësch, während DeptID en auslännesche Schlëssel ass.
All aner Attribut - an dësem Fall, EmployeeName and DeptName - muss ofgeschalt ginn op de Primärschlüssel fir säi Wäert ze kréien.
| EmployeeID | EmployeeName | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | Finanzen |
| Emp2 | Tina | Dept003 | Verkaf |
| Emp3 | Carlos | Dept001 | Finanzen |
An dësem Fall ass d'Tabelle net voll ofhängeg well d'EmployeeName hängt vum Primärschoul EmployeeID of, hänkt am DeptID of. Dëst gëtt heiansdo Departioun genannt .
Fir dës Tabell mat 2NF konform ze maachen, brauche mer d'Daten an zwou Dëscher ze trennen:
| EmployeeID | EmployeeName | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Mir entfernen den DeptName Attribut vun der Tabelle " Mataarbechter" an eng nei Tabelle spezialiséiert Departementer :
| DeptID | DeptName |
|---|---|
| Dept001 | Finanzen |
| Dept002 | Mënschlech Ressourcen |
| Dept003 | Verkaf |
Elo sinn d'Relatiounen tëschent den Dëscher voll ofhängeg oder an 2NF.
Firwat ganz Ofhängegkeet ass wichteg
Déi komplett Ofhängegkeet vun den Datenbankattribute hëlleft fir d'Integritéit vun Daten z'erreechen an Datenanomalien ze vermeiden.
Zum Beispill zielt d'Tabelle am Abschnitt iwwer déi et nëmmen 1NF hänkt. Hei ass et erëm:
| Employé | Standuert |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina huet zwee Opzeechnungen. Wann mir aktualiséieren ouni ze realiséieren datt et zwee gëtt, wäerten d'Resultater onbestänneg Daten sinn.
Oder, wéi wann mir e Mataarbechter op dës Dësch setzen wëllen, awer mir wëssen nach net d'Positioun? Mir kënnen eventuell net zougelooss ginn, souguer e neie Mataarbechter ze addéieren, wann de Location Attribut net NULL Wäerter zielt.
Déi ganz Ofhängegkeet ass net dat ganzt Bild, obwuel et normaresch ass. Dir musst sécher datt Är Datenbank an Dritt Normalform ass (3NF).