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 az alábbi táblázat nem felel meg az 1NF-nek, mivel a Tina alkalmazottja két helyre kapcsolódik, mindkettő egy cella:
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:
Munkavállaló | Elhelyezkedés |
---|---|
János | Los Angeles |
Tina | Los Angeles |
Tina | Chicago |
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, akkor ezt A -> B - mondjuk, 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 az A-tól függ.
Például a következő Munkavállalói Osztályok táblázatban, a Munkavállalói azonosító és a DeptID mind jelölt kulcsok: az EmployeeID az asztal elsődleges kulcsa, 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 részleges függőségnek nevezik.
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 az Alkalmazottak táblázatból, és új táblát hozunk létre. 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.