A teljes funkcionális függőség az adatbázis normalizációjának állapota, amely megfelel a második normál forma (2NF) normalizációs szabványának. Röviden, ez azt jelenti, hogy megfelel az első normál űrlap (1NF) követelményeinek, és az összes nem kulcs attribútum teljes mértékben funkcionálisan függ az elsődleges kulcstól.
Ez nem olyan bonyolult, mint amilyennek hangzik. Nézzük ezt részletesebben.
Az első normál forma összefoglalása
Mielőtt az adatbázis teljesen funkcionálisan függhet, először meg kell felelnie az első normál űrlapnak.
Mindez azt jelenti, hogy minden attribútumnak egyetlen atomi értéket kell tartalmaznia.
Például a következő táblázat tartalmazza nem megfeleljen az 1NF-nek, mert a Tina alkalmazott két helyre kapcsolódik, mindkettő egy cellában:
Munkavállaló | Elhelyezkedés |
---|---|
János | Los Angeles |
Tina | Los Angeles, Chicago |
Ha engedélyezi ezt a tervet, az negatív hatással lehet az adatfrissítésekre vagy bejegyzésekre. Az 1NF megfelelés biztosítása érdekében rendezze át a táblázatot úgy, hogy minden attribútum (vagy oszlopcellás) egyetlen értéket tartalmazzon:
Az első normál forma megfelelősége
De az 1NF még mindig nem elég ahhoz, hogy elkerülje az adatokkal kapcsolatos problémákat.
Hogyan működik a 2NF a teljes függőség biztosítása érdekében?
Ahhoz, hogy teljesen függő legyen, az összes nem jelölt kulcsfontosságú attribútumnak az elsődleges kulcstól kell függenie. (Ne feledje, hogy a jelölt kulcs-attribútum bármelyik kulcs (például egy elsődleges vagy idegen kulcs), amelyet az adatbázis-rekord egyedileg azonosítására használnak.
Az adatbázis-tervezők jelölést használnak az attribútumok közötti függő kapcsolatok leírására:
Ha az A attribútum meghatározza a B értékét, ezt írjukA -> B- ami azt jelenti, hogy B funkcionálisan függ az A-tól. Ebben a kapcsolatban A határozza meg a B értékét, míg B függ az A-tól.
Például a következőkben Munkavállalói osztályok táblázat, a EmployeeID és a DeptID mind jelölt kulcsok: az EmployeeID az asztal elsődleges kulcs, míg a DeptID idegen kulcs.
Bármelyik másik attribútum - ebben az esetben a EmployeeName és DeptName - az elsődleges kulcstól függ, hogy elérje az értékét.
Munkavállalói azonosító | Alkalmazott Neve | DeptID | DeptName |
---|---|---|---|
Emp1 | János | Dept001 | Pénzügy |
Emp2 | Tina | Dept003 | Sales |
Emp3 | Carlos | Dept001 | Pénzügy |
Ebben az esetben a táblázat nem teljesen függő, mert míg a EmployeeName az elsődleges Alkalmazásazonosító-kulcstól függ, a DeptName inkább a DeptID-től függ. Ezt nevezik részleges függőség .
Ahhoz, hogy ez a táblázat megfeleljen a 2NF-nek, el kell különíteni az adatokat két táblázatra:
Munkavállalói azonosító | Alkalmazott Neve | DeptID |
---|---|---|
Emp1 | János | Dept001 |
Emp2 | Tina | Dept003 |
Emp3 | Carlos | Dept001 |
A DeptName attribútumot eltávolítjuk a Az alkalmazottak és hozzon létre egy új táblát Osztályok :
DeptID | DeptName |
---|---|
Dept001 | Pénzügy |
Dept002 | Emberi Erőforrások |
Dept003 | Sales |
Most a táblák közötti kapcsolatok teljesen függenek, vagy 2NF-ben.
Miért fontos a teljes függőség?
Az adatbázis-attribútumok közötti teljes függőség biztosítja az adatok sértetlenségét és az adat-anomáliák elkerülését.
Például vegye figyelembe a fenti szakasz táblázatát, amely csak 1NF-et tart. Itt van még:
Munkavállaló | Elhelyezkedés |
---|---|
János | Los Angeles |
Tina | Los Angeles |
Tina | Chicago |
Tina két rekordot tartalmaz. Ha frissítjük, anélkül, hogy felismernénk, hogy kettő van, az eredmény nem konzisztens.
Vagy, mi van, ha hozzá akarunk adni egy alkalmazást ehhez a táblázathoz, de még nem ismerjük a Helyet? Lehet, hogy nem engedélyezzük új alkalmazottak hozzáadását sem, ha a Hely attribútum nem engedélyezi a NULL értékeket.
A teljes függőség azonban nem a teljes kép, ha a normalizációról van szó. Biztosítania kell, hogy az adatbázis harmadik normál űrlapon (3NF) legyen.