Je, ni Matumaini ya Kubadilika katika Database

Epuka Utegemeaji wa Msaada wa Msaidizi wa Kuhakikisha Kuwezesha Usimamizi

Utegemezi wa mabadiliko katika database ni uhusiano usio wa moja kwa moja kati ya maadili katika meza sawa ambayo husababisha utegemezi wa kazi . Ili kufikia kiwango cha kawaida cha Fomu ya Tatu ya kawaida (3NF), lazima uondoe utegemezi wowote wa mabadiliko.

Kwa asili yake, utegemezi wa transiti inahitaji sifa tatu au zaidi (au safu za databana) ambazo hutegemea kazi kati yao, maana ya kwamba safu A katika meza inategemea Hifadhi B kupitia Column ya Kati.

Hebu angalia jinsi hii inaweza kufanya kazi.

Mfano wa Utegemeaji

AUTHORS

Katika mfano wa AUTHORS hapo juu:

• Kitabu → Mwandishi : Hapa, sifa ya Kitabu huamua sifa ya Mwandishi . Ikiwa unajua jina la kitabu, unaweza kujifunza jina la mwandishi. Hata hivyo, Mwandishi hakuamua Kitabu , kwa sababu mwandishi anaweza kuandika vitabu vingi. Kwa mfano, tu kwa sababu tunajua jina la mwandishi Orson Scott Kadi, hatujui jina la kitabu.
• Mwandishi → Mwandishi wa Umoja wa Mataifa : Vivyo hivyo, sifa ya Mwandishi huamua Mwandishi_Nationality , lakini sio njia nyingine kote; kwa sababu tu tunajua utaifa hauna maana tunaweza kuamua mwandishi.

Lakini meza hii inaleta utegemezi wa mabadiliko:

• Kitabu → Mwandishi wa Uraia: Ikiwa tunajua jina la kitabu, tunaweza kuamua utaifa kupitia safu ya Mwandishi.

Kuepuka Utegemeaji wa Msaada

Kuhakikisha Fomu ya Tatu ya kawaida, hebu tuondoe utegemezi wa mabadiliko.

Tunaweza kuanza kwa kuondokana na safu ya Kitabu kutoka kwenye meza ya Waandishi na kujenga meza tofauti ya Vitabu:

BOOKS

AUTHORS

Je! Hii iliiharibu? Hebu tuchunguze utegemezi wetu sasa:

Kitabu cha kitabu :

• Kitabu_ID → Kitabu: Kitabu kinategemea Kitabu_ID .
• Hakuna tegemezi nyingine katika meza hii zipo, kwa hiyo tunastahili. Kumbuka kuwa ufunguo wa kigeni Mwandishi_ID huunganisha meza hii kwa meza ya AUTHORS kwa njia ya ufunguo wake wa msingi Author_ID . Tumeunda uhusiano ili kuepuka utegemezi wa mabadiliko, muundo muhimu wa databases za kihusiano.

Jedwali la AUTHORS :

• Mwandishi_ID → Mwandishi: Mwandishi hutegemea Author_ID .
• Mwandishi → MwandishiNational : Urithi unaweza kuamua na mwandishi.
• Mwandishi_ID → Mwandishi wa Umoja wa Mataifa: Urithi unaweza kuamua kutoka kwa Author_ID kupitia sifa ya Mwandishi . Bado tunayo tegemezi ya mabadiliko.

Tunahitaji kuongeza meza ya tatu ili kuimarisha data hii:

Nchi

AUTHORS

Sasa tuna meza tatu, tunatumia funguo za kigeni kuunganisha kati ya meza:

• Kitufe cha kigeni cha meza ya BOOK Author_ID huunganisha kitabu kwa mwandishi katika meza ya AUTHORS.
• Kitufe cha kigeni cha meza ya AUTHORS Nchi_ID inaunganisha mwandishi kwa nchi katika meza ya COUNTRIES.

• Jedwali la Nchi haina ufunguo wa nje kwa sababu hauna haja ya kuunganisha kwenye meza nyingine katika kubuni hii.

Kwa nini Utegemeaji wa Uhamisho ni Mfumo wa Hifadhi ya Bad

Je! Ni thamani gani ya kuepuka utegemezi wa mpito ili kusaidia kuhakikisha 3NF? Hebu fikiria meza yetu ya kwanza tena na uone masuala yanayojenga:

AUTHORS

Aina hii ya kubuni inaweza kuchangia uharibifu wa data na kutofautiana, kwa mfano:

• Ikiwa umefuta vitabu viwili vya "Watoto wa Akili" na "Mchezo wa Ender," ungefuta mwandishi "Orson Scott Kadi" na utaifa wake kabisa kutoka kwenye databana.

• Huwezi kuongeza mwandishi mpya kwenye database isipokuwa wewe pia kuongeza kitabu; je! ikiwa mwandishi bado haja kuchapishwa au hujui jina la kitabu alichoandika?
• Ikiwa "Orson Scott Kadi" ilibadilika uraia wake, ungebidi uibadilishe katika rekodi zote ambazo anaonekana. Kuwa na rekodi nyingi na mwandishi sawa kunaweza kusababisha data sahihi: ni nini ikiwa mtu anayeingia data hajui kuna rekodi nyingi kwa ajili yake na kubadilisha data katika rekodi moja tu?
• Huwezi kufuta kitabu kama "Tale ya Handmaid" bila pia kufuta mwandishi kabisa.

Hizi ni baadhi ya sababu zingine ambazo zinawezesha kuimarisha , na kuepuka utegemezi wa mabadiliko, kulinda data na kuhakikisha uwiano.