Buong Functional Dependency sa Database Normalization

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 hindi sumunod sa 1NF, dahil ang empleyado na si Tina ay naka-link sa dalawang lokasyon, pareho sa mga ito sa isang solong cell:

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:

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 attribute A ay tumutukoy sa halaga ng B, isinulat namin ito A -> 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 sumusunod na talahanayan ng Mga Kaganapan ng Empleyado, ang EmployeeID at DeptID ay parehong mga kandidato na key: Ang EmployeeID ang 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.

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:

Inalis namin ang attribute ng DeptName mula sa talahanayan ng Mga Empleyado at lumikha ng isang bagong Departamento ng talahanayan:

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:

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).