Ang ikatlong normal na form (3NF) ay isang prinsipyo ng database na sumusuporta sa integridad ng data sa pamamagitan ng pagtatayo sa mga prinsipyo ng normalisasyon ng database na ibinigay ng First Normal Form (1NF) at Second Normal Form (2NF).
Mga Pangangailangan sa Third Normal Form
Mayroong dalawang pangunahing mga kinakailangan para sa isang database upang maging sa ikatlong normal na form:
- Dapat na matugunan ng database ang mga kinakailangan ng parehong 1NF at 2NF .
- Ang lahat ng mga haligi ng database ay dapat na depende sa pangunahing susi , ibig sabihin na ang halaga ng haligi ay maaaring makuha mula sa pangunahing susi lamang.
Tungkol sa Pangunahing Depende sa Pangunahing
Talakayin natin ang karagdagang kahulugan ng katotohanan na ang lahat ng haligi ay dapat nakasalalay sa pangunahing susi.
Kung ang halaga ng haligi ay maaaring makuha mula sa parehong pangunahing susi at isa pang hanay sa talahanayan, lumalabag ito sa 3NF. Isaalang-alang ang talahanayan ng Mga empleyado na may mga hanay na ito:
- EmployeeID
- Pangalan
- Huling pangalan
Ang parehong LastName at FirstName ay nakasalalay lamang sa halaga ng EmployeeID? Well, maaaring LastName ay nakasalalay sa FirstName? Hindi, dahil walang likas sa LastName ang magmumungkahi ng halaga ng FirstName. Maari ba ang FirstName depende sa LastName? Hindi na, dahil pareho ang totoo: anuman ang isang LastName, hindi ito maaaring magbigay ng pahiwatig sa halaga ng FirstName. Samakatuwid, ang talahanayang ito ay sumusunod sa 3NF.
Ngunit isaalang-alang ang talahanayan ng Sasakyan:
- SasakyanID
- Manufacturer
- Modelo
Ang Manufacturer at ang Modelo ay maaaring makuha mula sa VehicleID - ngunit ang Modelo ay maaari ring makuha mula sa Manufacturer dahil ang isang modelo ng sasakyan ay ginawa lamang ng isang partikular na tagagawa. Ang disenyo ng talahanayan ay hindi sumusunod sa 3NF, at maaari, kaya, magreresulta sa mga anomalya ng data. Halimbawa, maaari mong i-update ang tagagawa nang hindi ina-update ang modelo, nagpapakilala ng mga kamalian.
Upang masunod ito, kailangan naming ilipat ang karagdagang haligi ng umaasa sa isa pang talahanayan at irepaso ito gamit ang isang banyagang susi. Ito ay magreresulta sa dalawang talahanayan:
Table ng Sasakyan
Sa talahanayan sa ibaba, ang ModelID ay isang banyagang susi sa mesa ng Mga Modelo :
- SasakyanID
- Manufacturer
- ModelID
Mga Table ng Mga Modelo
Ang bagong talahanayan ay nagpaplano ng mga modelo sa mga tagagawa. Kung nais mong i-update ang anumang impormasyon ng sasakyan na tukoy sa isang modelo, gagawin mo ito sa table na ito, sa halip na sa talahanayan ng Mga Sasakyan.
- ModelID
- Manufacturer
- Modelo
Mga Natatanging Field sa 3NF Model
Ang isang talahanayan ay maaaring maglaman ng isang nakuha na patlang - isa na nakalkula batay sa iba pang mga haligi sa talahanayan. Halimbawa, isaalang-alang ang talahanayan ng mga order ng widget na ito:
- Numero ng order
- Numero ng Customer
- Presyo ng isang piraso
- Dami
- Kabuuang
Ang kabuuang break 3NF pagsunod dahil ito ay maaaring makuha sa pamamagitan ng pag-multiply ang presyo ng yunit sa pamamagitan ng dami, sa halip na ganap na umaasa sa pangunahing susi. Dapat namin itong alisin mula sa talahanayan upang sumunod sa ikatlong normal na form.
Sa katunayan, dahil ito ay nagmula, mas mahusay na hindi ito iimbak sa database sa lahat.
Maaari lamang nating i-compute ito "sa mabilisang" kapag gumaganap ng mga query sa database. Halimbawa, maaaring ginamit namin dati ang query na ito upang mabawi ang mga numero at kabuuan ng order:
Pumili ng OrderNumber, Kabuuang MULA WidgetOrdersMaaari na namin ngayong gamitin ang sumusunod na tanong:
Piliin ang OrderNumber, UnitPrice * Dami AS Kabuuang MULA WidgetOrdersupang makamit ang parehong mga resulta nang hindi lumalabag sa mga panuntunan sa normalisasyon.