Ang isang buong functional dependency ay isang estado ng database normalisasyon na katumbas sa pamantayan ng normalization ng Pangalawang Normal Form (2NF). Sa madaling salita, nangangahulugan ito na natutugunan nito ang mga kinakailangan ng Unang Normal na Form (1NF), at lahat ng mga di-key na mga katangian ay ganap na nakasalalay sa pangunahing key.
Hindi ito kumplikado dahil maaaring ito ay tunog. Tingnan natin ito nang mas detalyado.
Buod ng Unang Normal na Form
Bago ang isang database ay maaaring ganap na nakasalalay depende, ito ay dapat munang sumunod sa Unang Normal Form.
Ang lahat ng ito ay nangangahulugan na ang bawat katangian ay dapat na magkaroon ng isang solong, atomic na halaga.
Halimbawa, ang sumusunod na talahanayan ay ginagawa hindi Sumunod sa 1NF, dahil ang empleyado ni Tina ay naka-link sa dalawang lokasyon, pareho sa mga ito sa isang solong cell:
| Empleado | Lokasyon |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Ang pagpapahintulot sa disenyo na ito ay maaaring negatibong epekto sa mga update sa data o mga entry. Upang matiyak ang pagsunod sa 1NF, muling ayusin ang talahanayan upang ang lahat ng mga katangian (o mga cell ng haligi) ay may isang solong halaga:
Pagsunod sa Unang Normal na Form
Ngunit hindi pa sapat ang 1NF upang maiwasan ang mga problema sa data.
Paano Gumagana ang 2NF upang matiyak ang Buong Dependency
Upang maging lubos na umaasa, dapat na depende sa pangunahing susi ang lahat ng mga katangian ng pangunahing di-kandidato. (Tandaan, ang isang key na katangian ng kandidato ay anumang susi (halimbawa, isang pangunahing o dayuhang susi) na ginamit upang kilalanin ang isang talaan ng database.
Ang mga taga-disenyo ng database ay gumagamit ng notasyon upang ilarawan ang mga nakasalalay na relasyon sa pagitan ng mga katangian:
Kung ang katangian A ay tumutukoy sa halaga ng B, isinulat namin itoA -> B- nangangahulugan na ang B ay nakasalalay sa pagtakbo sa A. Sa ganitong relasyon, tinutukoy ng A ang halaga ng B, habang ang B ay depende sa A.
Halimbawa, sa mga sumusunod Mga Kagawaran ng Kawani table, EmployeeID at DeptID ay parehong mga kandidato na key: Ang EmployeeID ay pangunahing susi ng talahanayan habang ang DeptID ay isang banyagang susi.
Ang anumang iba pang katangian - sa kasong ito, ang EmployeeName at DeptName - ay dapat na depende sa pangunahing susi upang makuha ang halaga nito.
| EmployeeID | EmployeeName | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | Pananalapi |
| Emp2 | Tina | Dept003 | Pagbebenta |
| Emp3 | Carlos | Dept001 | Pananalapi |
Sa kasong ito, ang talahanayan ay hindi ganap na nakasalalay dahil, habang ang EmployeeName ay nakasalalay sa pangunahing susi EmployeeID, ang DeptName ay nakasalalay sa halip sa DeptID. Ito ay tinatawag na bahagyang dependency .
Upang magawa ang talahanayan na ito sa 2NF, kailangan naming paghiwalayin ang data sa dalawang talahanayan:
| EmployeeID | EmployeeName | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Inalis namin ang attribute ng DeptName mula sa Mga empleyado talahanayan at lumikha ng isang bagong talahanayan Mga Kagawaran :
| DeptID | DeptName |
|---|---|
| Dept001 | Pananalapi |
| Dept002 | Mga Mapagkukunan ng Tao |
| Dept003 | Pagbebenta |
Ngayon ang relasyon sa pagitan ng mga talahanayan ay ganap na umaasa, o sa 2NF.
Kung Bakit Mahalaga ang Buong Dependency
Ang buong dependency sa pagitan ng mga attribute ng database ay tumutulong na matiyak ang integridad ng data at maiwasan ang mga anomalya ng data.
Halimbawa, isaalang-alang ang talahanayan sa seksyon sa itaas na sumusunod lamang sa 1NF. Narito ito ay, muli:
| Empleado | Lokasyon |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
May dalawang talaan si Tina. Kung i-update namin ang isa nang hindi napagtatanto na may dalawa, ang resulta ay magiging hindi pantay-pantay na data.
O, paano kung gusto naming magdagdag ng empleyado sa table na ito, ngunit hindi pa namin alam ang Lokasyon? Maaari naming i-disallow upang magdagdag pa ng bagong empleyado kung hindi pinapayagan ng katangian ng Lokasyon ang mga halaga ng NULL.
Gayunpaman, ang buong dependency ay hindi ang buong larawan, pagdating sa normalisasyon. Dapat mong tiyakin na ang iyong database ay nasa Third Normal Form (3NF).
