Ang isang palipat na dependency sa isang database ay isang di-tuwirang kaugnayan sa pagitan ng mga halaga sa parehong mesa na nagiging sanhi ng isang functional dependency. Upang makamit ang pamantayan ng normalization ng Third Normal Form (3NF), dapat mong alisin ang anumang palipat na dependency.
Sa pamamagitan ng kalikasan nito, ang isang palipat na dependency ay nangangailangan ng tatlo o higit pang mga katangian (o mga haligi ng database) na may isang functional dependency sa pagitan ng mga ito, ibig sabihin na ang Haligi A sa isang table ay umaasa sa Haligi B sa pamamagitan ng isang intermediate na Column C.
Tingnan natin kung paano ito gumagana.
Halimbawa ng Transitive Dependency
MGA AUTHORS
| Author_ID | May-akda | Book | Author_Nationality |
|---|---|---|---|
| Auth_001 | Orson Scott Card | Ender's Game | Estados Unidos |
| Auth_001 | Orson Scott Card | Ender's Game | Estados Unidos |
| Auth_002 | Margaret Atwood | Ang Kuwento ng Suliranin | Canada |
Sa mga halimbawa ng AUTHORS sa itaas:
- Book → May-akda : Dito, ang Book tinutukoy ng katangian ang May-akda katangian. Kung alam mo ang pangalan ng libro, maaari mong malaman ang pangalan ng may-akda. Gayunpaman, May-akda ay hindi tumutukoy Book , dahil ang isang may-akda ay maaaring magsulat ng maramihang mga libro. Halimbawa, dahil alam namin ang pangalan ng may-akda na Orson Scott Card, hindi namin alam ang pangalan ng libro.
- May-akda → Author_Nationality : Gayundin, ang May-akda tinutukoy ng katangian ang Author_Nationality , ngunit hindi ang iba pang paraan sa paligid; dahil alam natin na ang nasyonalidad ay hindi nangangahulugang matukoy natin ang may-akda.
Ngunit ang mesa na ito ay nagpapakilala ng isang palipat na dependency:
- Book → Author_Nationality: Kung alam namin ang pangalan ng libro, maaari naming matukoy ang nasyonalidad sa pamamagitan ng hanay ng May-akda.
Pag-iwas sa mga Transitive Dependencies
Upang matiyak ang Third Normal Form, tanggalin natin ang palipat na dependency.
Maaari naming magsimula sa pamamagitan ng pag-alis ng hanay ng Aklat mula sa talahanayan ng Mga May-akda at paglikha ng hiwalay na talahanayan ng Mga Libro:
MGA LIBRO
| Book_ID | Book | Author_ID |
|---|---|---|
| Book_001 | Ender's Game | Auth_001 |
| Book_001 | Mga Bata ng Pag-iisip | Auth_001 |
| Book_002 | Ang Kuwento ng Suliranin | Auth_002 |
MGA AUTHORS
| Author_ID | May-akda | Author_Nationality |
|---|---|---|
| Auth_001 | Orson Scott Card | Estados Unidos |
| Auth_002 | Margaret Atwood | Canada |
Naaayos na ba ito? Suriin natin ang ating mga dependency ngayon:
Mga talahanayan ng BOOKS:
- Book_ID → Aklat: Ang Book depende sa Book_ID .
- Walang iba pang mga dependency sa table na ito ang umiiral, kaya't okay lang kami. Tandaan na ang banyagang susi Author_ID nagli-link ng table na ito sa talahanayan ng AUTHORS sa pamamagitan ng pangunahing key nito Author_ID . Gumawa kami ng isang relasyon upang maiwasan ang isang palipat na dependency, isang pangunahing disenyo ng mga pamanggit na database.
Mga talahanayan ng mga may-akda:
- Author_ID → May-akda: Ang May-akda depende sa Author_ID .
- May-akda → Author_Nationality: Ang nasyonalidad ay maaaring matukoy ng may-akda.
- Author_ID → Author_Nationality: Ang nasyonalidad ay maaaring matukoy mula sa Author_ID sa pamamagitan ng May-akda katangian. Mayroon pa kaming isang palipat na dependency.
Kailangan naming magdagdag ng isang ikatlong talahanayan upang gawing normal ang data na ito:
MGA BANSA
| Country_ID | Bansa |
|---|---|
| Coun_001 | Estados Unidos |
| Coun_002 | Canada |
MGA AUTHORS
| Author_ID | May-akda | Country_ID |
|---|---|---|
| Auth_001 | Orson Scott Card | Coun_001 |
| Auth_002 | Margaret Atwood | Coun_002 |
Ngayon mayroon kaming tatlong mga talahanayan, na ginagamit ang mga banyagang key upang iugnay sa pagitan ng mga talahanayan:
- Ang banyagang key ng BOOK table Author_ID nagli-link ng isang libro sa isang may-akda sa talahanayan ng AUTHORS.
- Ang banyagang key ng talahanayan ng AUTHORS Country_ID nagli-link ng isang may-akda sa isang bansa sa talahanayan ng COUNTRIES.
- Ang talahanayan ng COUNTRIES ay walang mga banyagang key dahil hindi na kailangang mag-link sa isa pang table sa disenyo na ito.
Bakit ang mga Dependencies ng Transitive ay Masamang Disenyo sa Database
Ano ang halaga ng pag-iwas sa mga palipat-lipat na dependency upang matulungan tiyakin ang 3NF? Isaalang-alang natin ang aming unang talahanayan at tingnan ang mga isyu na lumilikha nito:
MGA AUTHORS
| Author_ID | May-akda | Book | Author_Nationality |
|---|---|---|---|
| Auth_001 | Orson Scott Card | Ender's Game | Estados Unidos |
| Auth_001 | Orson Scott Card | Mga Bata ng Pag-iisip | Estados Unidos |
| Auth_002 | Margaret Atwood | Ang Kuwento ng Suliranin | Canada |
Ang ganitong uri ng disenyo ay maaaring magbigay ng kontribusyon sa mga anomalya at hindi pagkakapare-pareho ng data, halimbawa:
- Kung tinanggal mo ang dalawang aklat na "Children of the Mind" at "Ender's Game," tatanggalin mo ang may-akda na "Orson Scott Card" at ang kanyang nasyonalidad ganap na mula sa database.
- Hindi ka maaaring magdagdag ng isang bagong may-akda sa database maliban kung nagdagdag ka rin ng isang libro; paano kung ang may-akda ay hindi pa nai-publish o hindi mo alam ang pangalan ng isang libro na kanyang nilikha?
- Kung ang "Orson Scott Card" ay nagbago ng kanyang pagkamamamayan, kailangan mong baguhin ito sa lahat ng mga rekord kung saan siya lilitaw. Ang pagkakaroon ng maramihang mga rekord na may parehong may-akda ay maaaring magresulta sa di-tumpak na data: paano kung ang data entry tao ay hindi mapagtanto mayroong maraming mga talaan para sa kanya at nagbabago ang data sa isang talaan lamang?
- Hindi mo maaaring tanggalin ang isang libro tulad ng "The Handmaid's Tale" nang hindi rin tinatanggal ang may-akda ng ganap.
Ang mga ito ay ilang mga kadahilanan kung bakit ang normalisasyon, at pag-iwas sa mga palipat-lipat na dependency, protektahan ang data at matiyak ang pagkakapare-pareho.
