Hifadhidata za Uhusiano hukuruhusu kuhifadhi habari katika majedwali kadhaa ya "gorofa" (ya pande mbili), yaliyounganishwa kupitia sehemu za data zilizoshirikiwa zinazoitwa funguo. Hifadhidata za uhusiano hutoa ufikiaji rahisi wa ripoti za hewani (kawaida kupitia SQL) na hutoa uaminifu na uadilifu zaidi wa data kwa kuondoa taarifa zisizohitajika.

Kila mtu anajua hifadhidata rahisi ni nini: saraka za simu, katalogi za bidhaa na kamusi zote ni hifadhidata. Zinaweza kupangwa au kupangwa vinginevyo: kama faili bapa, kama miundo ya daraja au mtandao, au kama majedwali ya uhusiano. Mara nyingi, mashirika hutumia hifadhidata za uhusiano kuhifadhi habari.

Hifadhidata ni mkusanyiko wa majedwali yanayojumuisha safu wima na safu mlalo, sawa na lahajedwali. Kila mstari una kiingilio kimoja; kila safu ina matukio yote ya kipande fulani cha data kutoka kwa safu mlalo zote. Kwa mfano, saraka ya simu ya kawaida huwa na safu wima zilizo na nambari za simu, majina ya mpigaji simu, na anwani za mpigaji simu. Kila mstari una nambari, jina na anwani. Fomu hii rahisi inaitwa faili gorofa kutokana na asili yake ya pande mbili na ukweli kwamba data zote zimehifadhiwa katika faili moja.

Kwa kweli, kila hifadhidata ina angalau safu wima moja iliyo na kitambulisho cha kipekee, au ufunguo. Fikiria kitabu cha simu. Kunaweza kuwa na maingizo kadhaa kwa mpigaji simu John Smith, lakini hakuna nambari ya simu inayorudiwa. Nambari ya simu hutumika kama ufunguo.

Kwa kweli, kila kitu sio rahisi sana. Watu wawili au zaidi wanaotumia nambari moja ya simu wanaweza kuorodheshwa tofauti katika saraka ya simu, na kusababisha nambari ya simu kuonekana katika sehemu mbili au zaidi, ili kuwe na nyuzi nyingi muhimu ambazo si za kipekee.

Data inaleta matatizo

Katika hifadhidata rahisi zaidi, kila rekodi inachukua safu moja, kwa maneno mengine, kampuni ya simu inahitaji kuunda safu tofauti kwa kila kipande cha habari ya uhasibu. Hiyo ni, moja kwa mteja wa pili wa simu "iliyounganishwa", nyingine kwa ya tatu, nk, kulingana na jinsi wanachama wengi wa ziada wanahitajika.

Hii ina maana kwamba kila rekodi katika hifadhidata lazima iwe na safu wima hizi zote za ziada, hata kama hazitumiki popote pengine. Hii pia inamaanisha kuwa hifadhidata lazima ipangwe upya wakati wowote kampuni inatoa huduma mpya. Huduma ya upigaji simu ya toni imeanzishwa - na muundo wa hifadhidata hubadilika, safu wima mpya inapoongezwa. Usaidizi wa kitambulisho cha mpigaji simu, kusubiri simu, nk huletwa - na hifadhidata inajengwa tena na tena.

Katika miaka ya 1960, makampuni makubwa pekee ndiyo yaliweza kumudu kununua kompyuta ili kudhibiti data zao. Zaidi ya hayo, hifadhidata zilizoundwa kwa miundo ya data tuli na lugha za programu za kitaratibu kama vile Cobol zinaweza kuwa ghali kudumisha na sio kuaminika kila wakati. Lugha za kitaratibu hufafanua mlolongo wa matukio ambayo kompyuta lazima ipitie ili kukamilisha kazi. Kupanga mlolongo kama huo ilikuwa ngumu, haswa ikiwa unahitaji kubadilisha muundo wa hifadhidata au kuunda aina mpya ya ripoti.

Viunganisho vya nguvu

Edgar Codd, mtafiti katika Maabara ya Utafiti ya IBM ya San Jose, kimsingi aliunda na kueleza dhana ya hifadhidata za uhusiano katika kazi yake ya mwisho, Mfano wa Uhusiano wa Data kwa Benki Kubwa za Data Zilizoshirikiwa. Mawasiliano ya ACM, Juni 1970).

Codd alipendekeza muundo unaoruhusu wasanidi programu kugawa hifadhidata zao katika majedwali tofauti lakini yanayohusiana, ambayo huboresha utendakazi huku ikidumisha mwonekano sawa na hifadhidata asili. Tangu wakati huo, Codd amezingatiwa baba mwanzilishi wa tasnia ya hifadhidata ya uhusiano.

Mfano huu hufanya kazi kama ifuatavyo. Kampuni ya simu inaweza kuunda jedwali kuu kwa kutumia nambari ya simu kama ufunguo msingi na kuihifadhi pamoja na maelezo mengine ya msingi ya mteja. Kampuni inaweza kufafanua jedwali tofauti lenye safu wima za ufunguo huu msingi na kwa huduma za ziada kama vile usaidizi wa kitambulisho cha anayepiga na kusubiri simu. Anaweza pia kuunda jedwali lingine ili kudhibiti bili za simu, ambapo kila ingizo lina nambari ya simu na data ya malipo ya simu.

Watumiaji wa hatima wanaweza kupata maelezo wanayotaka kwa urahisi, jinsi wanavyotaka, ingawa data imehifadhiwa katika majedwali tofauti. Kwa hiyo, mwakilishi wa huduma ya wateja wa kampuni ya simu anaweza kuonyesha taarifa kuhusu malipo ya mteja, pamoja na hali ya huduma maalum au wakati malipo ya mwisho yalipokewa, kwenye skrini sawa.

Codd ilitunga sheria 12 za hifadhidata za uhusiano, nyingi zikiwa zinahusu uadilifu wa data, kusasisha na ufikiaji. Mbili za kwanza ziko wazi hata kwa watumiaji wasio wa kiufundi.

Kanuni ya 1, sheria ya habari, inabainisha kuwa taarifa zote katika hifadhidata ya uhusiano zinawakilishwa kama seti ya maadili yaliyohifadhiwa kwenye jedwali.

Kanuni ya 2, Kanuni ya Dhamana ya Ufikiaji, inabainisha kuwa kila kipengele cha data katika hifadhidata ya uhusiano kinaweza kufikiwa kwa kutumia jina la jedwali, ufunguo msingi na jina la safu wima. Kwa maneno mengine, data zote zimehifadhiwa kwenye meza, na ikiwa unajua jina la meza, ufunguo wa msingi na safu ambapo kipengee cha data kinachohitajika kinapatikana, inaweza kupatikana kila wakati.

Kiini cha kazi ya Codd ilikuwa kwamba ilipendekezwa kutumia lugha za kutangaza badala ya utaratibu na hifadhidata za uhusiano. Lugha bainifu kama vile SQL (Lugha ya Maswali Iliyoundwa) huwapa watumiaji uwezo wa kuiambia kompyuta kimsingi, "Ninataka kupata data ifuatayo kutoka kwa rekodi zote zinazotimiza seti fulani ya vigezo." Kompyuta yenyewe "itaelewa" ni hatua gani zinahitajika kuchukuliwa ili kupata habari hii kutoka kwa hifadhidata.

Kufanya kazi na idadi kubwa ya hifadhidata zinazotumiwa kikamilifu, mifumo ya programu ya usimamizi wa hifadhidata hutumiwa, iliyoundwa na watengenezaji mashuhuri kama Oracle, Sybase, IBM, Informix na Microsoft.

Ingawa utekelezaji mwingi wa SQL unaweza tu kuitwa kuwa unaweza kushirikiana ndani ya makadirio fulani, utaratibu huu, ulioidhinishwa kama kiwango cha kimataifa, unaruhusu uundaji wa mifumo changamano ya msingi wa hifadhidata. Kiolesura rahisi cha programu kati ya Tovuti na hifadhidata za uhusiano huwapa watumiaji wa mwisho uwezo wa kuongeza rekodi mpya, kusasisha zilizopo, na kutoa ripoti za huduma mbalimbali, kama vile biashara ya mtandaoni na ufikiaji wa katalogi za maktaba mtandaoni.

Mfano wa uhusiano

Hifadhidata ya uhusiano hutumia seti ya jedwali zinazohusiana na kila moja kupitia kitufe maalum (katika kesi hii, sehemu ya Nambari ya Simu)

Hifadhidata (DB) - Hii ni seti iliyopewa jina la data iliyopangwa inayohusiana na eneo mahususi la somo na inayokusudiwa kuhifadhi, kukusanywa na kuchakatwa kwa kutumia kompyuta.

Hifadhidata ya Uhusiano (RDB) ni seti ya mahusiano ambayo majina yao yanawiana na majina ya mahusiano ya schema kwenye schema ya hifadhidata.

Dhana za Msingi hifadhidata za uhusiano:

· Aina ya data- aina ya maadili ya safu maalum.

· Kikoa(kikoa) - seti ya maadili yote halali ya sifa.

· Sifa(sifa) - kichwa cha safu ya jedwali kinachoashiria mali iliyopewa jina la kitu, kwa mfano, jina la mwisho la mwanafunzi, tarehe ya kuagiza, jinsia ya mfanyakazi, nk.

· Cortege- safu ya jedwali inayowakilisha seti ya maadili ya sifa zinazohusiana kimantiki.

· Mtazamo(uhusiano) - meza inayoonyesha habari kuhusu vitu vya ulimwengu halisi, kwa mfano, kuhusu wanafunzi, maagizo, wafanyakazi, wakazi, nk.

· Ufunguo wa msingi(ufunguo wa msingi) - sehemu (au seti ya sehemu) ya jedwali ambayo inabainisha kipekee kila rekodi zake.

· Kitufe mbadala ni sehemu (au seti ya sehemu) ambayo hailingani na ufunguo msingi na inabainisha kwa namna ya kipekee mfano wa rekodi.

· Kitufe cha nje ni sehemu (au seti ya sehemu) ambazo thamani zake zinalingana na thamani zilizopo za ufunguo msingi wa jedwali lingine. Unapounganisha meza mbili, ufunguo wa msingi wa jedwali la kwanza umeunganishwa na ufunguo wa kigeni wa jedwali la pili.

· Muundo wa Data ya Uhusiano (RDM)- kuandaa data kwa namna ya meza mbili-dimensional.

Kila jedwali la uhusiano lazima liwe na sifa zifuatazo:

1. Kila rekodi ya meza ni ya pekee, i.e. seti ya maadili kwenye sehemu hairudiwi.

2. Kila thamani iliyoandikwa kwenye makutano ya safu mlalo na safu ni ya atomiki (haitenganishwi).

3. Thamani za kila sehemu lazima ziwe za aina moja.

4. Kila uwanja una jina la kipekee.

5. Utaratibu wa maingizo sio muhimu.

Vipengele kuu vya hifadhidata:

Shamba- kitengo cha msingi cha shirika la kimantiki la data. Sifa zifuatazo hutumiwa kuelezea fani:

· jina, kwa mfano, Jina la Mwisho, Jina la Kwanza, Patronymic, Tarehe ya Kuzaliwa;

· aina, kwa mfano, kamba, tabia, nambari, tarehe;

· urefu, kwa mfano, katika ka;

· usahihi wa data ya nambari, kama vile sehemu mbili za desimali ili kuonyesha sehemu ya sehemu ya nambari.

Rekodi- seti ya maadili ya nyanja zinazohusiana kimantiki.

Kielezo- njia ya kuharakisha operesheni ya utafutaji wa rekodi, inayotumiwa kuanzisha uhusiano kati ya meza. Jedwali ambalo index hutumiwa inaitwa indexed. Wakati wa kufanya kazi na faharisi, unahitaji kulipa kipaumbele kwa shirika la faharisi, ambayo ni msingi wa uainishaji. Faharasa rahisi inawakilishwa na sehemu moja au usemi wa Boolean ambao huchakata sehemu moja. Faharasa ya mchanganyiko inawakilishwa na nyanja kadhaa zenye uwezo wa kutumia kazi mbalimbali. Faharasa za jedwali huhifadhiwa kwenye faili ya faharasa.

Uadilifu wa data- hii ni njia ya kulinda data kwenye uwanja wa mawasiliano, ambayo hukuruhusu kudumisha meza katika hali thabiti (ya thabiti) (yaani, hairuhusu uwepo wa rekodi kwenye jedwali ndogo ambazo hazina rekodi zinazolingana katika mzazi. meza).

Ombi- swali lililoundwa kwa jedwali moja au zaidi zilizounganishwa zenye vigezo vya sampuli za data. Hoja inatekelezwa kwa kutumia lugha ya uulizaji iliyoundwa SQL (Lugha ya Maswali Iliyoundwa). Kurejesha data kutoka kwa jedwali moja au zaidi kunaweza kusababisha seti ya rekodi inayoitwa mtazamo.

Uwasilishaji wa data- swali lililopewa jina lililohifadhiwa kwenye hifadhidata ili kupata data (kutoka kwa jedwali moja au zaidi).

Mtazamo kimsingi ni jedwali la muda iliyoundwa kama matokeo ya swali. Ombi yenyewe inaweza kutumwa kwa faili tofauti, ripoti, meza ya muda, meza kwenye diski, nk.

Ripoti- sehemu ya mfumo ambayo kusudi lake kuu ni kuelezea na kuchapisha hati kulingana na habari kutoka kwa hifadhidata.

Tabia za jumla za kufanya kazi na RDB:

Ufafanuzi wa kawaida wa mfano wa data wa uhusiano unaonekana kuwa wa Data, ambaye huizalisha (na uboreshaji mbalimbali) katika karibu vitabu vyake vyote. Kulingana na Tarehe, modeli ya uhusiano ina sehemu tatu ambazo zinaelezea vipengele tofauti vya mbinu ya uhusiano: sehemu ya kimuundo, sehemu ya uendeshaji, na sehemu ya jumla.

Sehemu ya kimuundo ya modeli inasema kwamba muundo pekee wa data unaotumiwa katika hifadhidata za uhusiano ni uhusiano wa kawaida wa n-ary.

Sehemu ya ghiliba ya modeli inathibitisha mbinu mbili za kimsingi za kudhibiti hifadhidata za uhusiano - aljebra ya uhusiano na kalkulasi ya uhusiano. Utaratibu wa kwanza unategemea hasa nadharia ya kitamaduni (pamoja na uboreshaji fulani), na ya pili inategemea vifaa vya kimantiki vya kalkulasi ya mpangilio wa kwanza. Kumbuka kuwa kazi kuu ya sehemu ya ghiliba ya muundo wa uhusiano ni kutoa kipimo cha uhusiano wa lugha yoyote maalum ya hifadhidata ya uhusiano: lugha inaitwa uhusiano ikiwa haina usemi na nguvu kidogo kuliko aljebra ya uhusiano au kalkulasi ya uhusiano.

28. LUGHA ZA ALGORITHIM. WAFASIRI (WAKALIMANI NA WASANGAMIZI). MSINGI WA LUGHA YA ALGORITHM. MUUNDO WA PROGRAMU. VITAMBULISHO. VIGEZO. WAENDESHAJI. USINDIKAJI WA SAFU ZENYE DARAJA MOJA NA ZENYE PICHA MBILI. KAZI ZA MTUMIAJI. SUBROUTINES. KUFANYA KAZI NA FAILI ZA DATA.

Lugha ya hali ya juu- lugha ya programu ambayo dhana na muundo ni rahisi kwa mtazamo wa kibinadamu.

Lugha ya algoriti(Lugha ya algorithmic) - lugha ya programu - lugha ya bandia (rasmi) iliyoundwa kwa ajili ya kuandika algoriti. Lugha ya programu inafafanuliwa na maelezo yake na kutekelezwa kwa namna ya programu maalum: mkusanyaji au mkalimani. Mfano wa lugha za algorithmic ni Borland Pascal, C++, Msingi, nk.

Dhana za kimsingi za lugha ya algorithmic:

Muundo wa lugha:

Lugha ya kawaida inayozungumzwa ina vipengele vinne vya msingi: ishara, maneno, vishazi na sentensi. Lugha ya algorithmic ina vitu sawa, maneno pekee huitwa ujenzi wa msingi, misemo huitwa misemo, na sentensi huitwa waendeshaji.

Alama, miundo ya kimsingi, misemo na waendeshaji huunda muundo wa hali ya juu, kwani ujenzi wa msingi huundwa kutoka kwa mlolongo wa alama.

Maneno ni mlolongo wa miundo na alama za msingi,

Opereta- mlolongo wa maneno, miundo ya msingi na alama.

Maelezo ya lugha:

Maelezo ya wahusika yanajumuisha kuorodhesha vibambo halali vya lugha. Maelezo ya miundo ya msingi inamaanisha sheria za malezi yao. Maelezo ya misemo ni kanuni za uundaji wa misemo yoyote ambayo ina maana katika lugha fulani. Maelezo ya waendeshaji hujumuisha kuzingatia aina zote za waendeshaji zinazoruhusiwa katika lugha. Maelezo ya kila kipengele cha lugha yametolewa na SINTAKSIA na SEMANTIKI yake.

Sintaksia fasili huweka kanuni za kujenga vipengele vya lugha.

Semantiki hufafanua maana na kanuni za matumizi ya vipengele hivyo vya lugha ambavyo fasili za kisintaksia zimetolewa.

Alama za lugha- hizi ni ishara za kimsingi zisizoweza kugawanywa kulingana na ambayo maandishi yote katika lugha yameandikwa.

Miundo ya msingi- hivi ndivyo vipashio vya chini zaidi vya lugha ambavyo vina maana huru. Wao huundwa kutoka kwa alama za msingi za lugha.

Kujieleza katika lugha ya algorithmic, ina miundo ya msingi na alama; inabainisha sheria ya kuhesabu thamani fulani.

Opereta hubainisha maelezo kamili ya kitendo fulani kinachohitaji kufanywa. Kikundi cha kauli kinaweza kuhitajika kuelezea kitendo changamano.

Katika kesi hii, waendeshaji wameunganishwa kuwa Opereta kiwanja au Zuia. Vitendo, iliyoainishwa na waendeshaji, inatekelezwa kwenye data. Taarifa za lugha ya algoriti ambayo hutoa maelezo kuhusu aina za data huitwa matamko au taarifa zisizotekelezeka. Seti ya maelezo na waendeshaji waliounganishwa na algoriti moja huunda programu katika lugha ya algoriti. Katika mchakato wa kusoma lugha ya algorithmic, inahitajika kutofautisha lugha ya algorithmic kutoka kwa lugha ambayo maelezo ya lugha ya algorithmic inayosomwa hufanywa. Kawaida lugha inayosomwa huitwa lugha tu, na lugha ambayo maelezo ya lugha inayosomwa hutolewa - Lugha ya Kimetala.

Wafasiri - (Mfasiri wa Kiingereza - mtafsiri) ni programu ya mfasiri. Inabadilisha programu iliyoandikwa katika moja ya lugha za kiwango cha juu kuwa programu inayojumuisha maagizo ya mashine.

Programu iliyoandikwa kwa lugha yoyote ya kiwango cha juu ya algoriti haiwezi kutekelezwa moja kwa moja kwenye kompyuta. Kompyuta inaelewa tu lugha ya amri za mashine. Kwa hivyo, programu katika lugha ya algorithmic lazima itafsiriwe (itafsiriwe) kwa lugha ya amri ya kompyuta maalum. Tafsiri kama hiyo inafanywa kiatomati na programu maalum za watafsiri iliyoundwa kwa kila lugha ya algorithmic na kwa kila aina ya kompyuta.

Kuna njia kuu mbili za utangazaji - mkusanyiko na tafsiri.

1.Mkusanyiko: Mkusanyaji(Mkusanyaji wa Kiingereza - mkusanyaji, mkusanyaji) anasoma programu nzima, anaitafsiri na kuunda toleo kamili la programu katika lugha ya mashine, ambayo inatekelezwa.

Katika mkusanyiko programu nzima ya asili inabadilishwa mara moja kuwa mlolongo wa maagizo ya mashine. Baada ya hayo, programu inayosababisha inatekelezwa na kompyuta yenye data ya chanzo inapatikana. Faida ya njia hii ni kwamba tafsiri inafanywa mara moja, na utekelezaji (nyingi) wa programu inayosababisha inaweza kufanywa kwa kasi ya juu. Wakati huo huo, programu inayosababisha inaweza kuchukua nafasi nyingi katika kumbukumbu ya kompyuta, kwani operator wa lugha moja hubadilishwa na mamia au hata maelfu ya amri wakati wa tafsiri. Kwa kuongeza, utatuzi na marekebisho ya programu ya utangazaji ni vigumu sana.

2. Tafsiri: Mkalimani(Mkalimani wa Kiingereza - mkalimani, mkalimani) hutafsiri na kutekeleza mpango kwa mstari.

Katika tafsiri mpango wa awali ni kuhifadhiwa katika kumbukumbu ya kompyuta karibu bila kubadilika. Mpango wa mkalimani huamua taarifa za programu chanzo moja baada ya nyingine na mara moja huhakikisha utekelezaji wao kwa data inayopatikana. Programu iliyotafsiriwa inachukua nafasi kidogo katika kumbukumbu ya kompyuta na ni rahisi kurekebisha na kurekebisha. Lakini utekelezaji wa programu ni polepole sana, kwani kwa kila utekelezaji tafsiri ya waendeshaji wote hufanywa upya.

Programu zilizokusanywa huendesha haraka, lakini zilizofasiriwa ni rahisi kurekebisha na kubadilisha.

Kila lugha mahususi huelekezwa ama katika mkusanyo au tafsiri - kutegemeana na madhumuni ambayo iliundwa kwa ajili yake. Kwa mfano, Pascal kawaida hutumiwa kutatua shida ngumu ambazo kasi ya programu ni muhimu. Kwa hivyo, lugha hii kawaida hutekelezwa kwa kutumia mkusanyaji.

Kwa upande mwingine, BASIC iliundwa kama lugha ya waandaaji wa programu wanaoanza, ambao utekelezaji wa mpango kwa mstari una faida zisizoweza kuepukika.

Wakati mwingine kuna mkusanyaji na mkalimani wa lugha moja. Katika kesi hii, unaweza kutumia mkalimani kuendeleza na kupima programu, na kisha kukusanya programu iliyotatuliwa ili kuboresha kasi ya utekelezaji wake.

• Tafsiri

Ujumbe wa mtafsiri: ingawa nakala ni ya zamani kabisa (iliyochapishwa miaka 2 iliyopita) na ina kichwa kikubwa, bado inatoa wazo nzuri la tofauti kati ya hifadhidata za uhusiano na hifadhidata za NoSQL, faida na hasara zao, na pia hutoa muhtasari mfupi. ya hifadhi zisizo za uhusiano.

Hivi karibuni, hifadhidata nyingi zisizo za uhusiano zimeonekana. Hii inapendekeza kwamba ikiwa unahitaji uwezekano usio na kikomo wa mahitaji, unahitaji hifadhidata isiyo ya uhusiano.

Ikiwa hii ni kweli, je, hii inamaanisha kuwa hifadhidata kubwa ya uhusiano imekuwa hatarini? Je, hii inamaanisha kwamba siku za hifadhidata za uhusiano zinapita na hivi karibuni zitatoweka kabisa? Katika makala haya, tutaangalia vuguvugu maarufu la hifadhidata isiyo ya uhusiano kama inavyotumika kwa hali tofauti na kuona ikiwa itaathiri mustakabali wa hifadhidata za uhusiano.

Hifadhidata za uhusiano zimekuwepo kwa takriban miaka 30. Wakati huu, mapinduzi kadhaa yalizuka ambayo yangekomesha uhifadhi wa uhusiano. Bila shaka, hakuna mapinduzi haya yaliyofanyika, na hakuna hata mmoja wao aliyetikisa msimamo wa hifadhidata za uhusiano hata ota moja.

Hebu tuanze na mambo ya msingi

Hifadhidata ya uhusiano ni seti ya majedwali (vyombo). Jedwali linajumuisha safu wima na safu (tuples). Vikwazo vinaweza kufafanuliwa ndani ya majedwali, na mahusiano yapo kati ya majedwali. Kwa kutumia SQL, unaweza kuendesha hoja zinazorudisha seti za data kutoka kwa jedwali moja au zaidi. Ndani ya swali moja, data hupatikana kutoka kwa jedwali kadhaa kwa kuziunganisha (JIUNGE), mara nyingi safu wima zinazofafanua uhusiano kati ya jedwali hutumiwa kwa unganisho. Kurekebisha ni mchakato wa kuunda muundo wa data ili kuhakikisha uwiano na ukosefu wa upungufu katika data.

Hifadhidata za uhusiano zinapatikana kupitia mifumo ya usimamizi wa hifadhidata ya uhusiano (RDBMS). Takriban mifumo yote ya hifadhidata tunayotumia ni ya uhusiano, kama vile Oracle, SQL Server, MySQL, Sybase, DB2, TeraData na kadhalika.

Sababu za utawala huu haziko wazi. Katika historia ya hifadhidata za uhusiano, zimetoa mara kwa mara mchanganyiko bora wa urahisi, uthabiti, unyumbufu, utendakazi, uimara na utangamano katika usimamizi wa data.

Walakini, ili kutoa huduma hizi zote, duka za uhusiano ni ngumu sana chini ya kofia. Kwa mfano, hoja rahisi CHAGUA inaweza kuwa na mamia ya njia zinazowezekana za utekelezaji ambazo kiboreshaji kitatathmini moja kwa moja wakati wa utekelezaji wa hoja. Yote haya yamefichwa yasionekane na watumiaji, lakini ndani RDBMS huunda mpango wa utekelezaji kulingana na mambo kama vile kanuni za makadirio ya gharama ili kukidhi hoja vizuri zaidi.

Matatizo ya hifadhidata ya uhusiano

Ingawa maduka ya uhusiano yanatoa mchanganyiko bora zaidi wa urahisi, uthabiti, kunyumbulika, utendakazi, ukubwa na uoanifu, si lazima yafanye vyema kwenye kila mojawapo ya pointi hizi kuliko mifumo linganifu inayolenga kipengele kimoja. Hili halikuwa tatizo kubwa, kwani utawala wa jumla wa DBMS za uhusiano ulizidi mapungufu yoyote. Hata hivyo, ikiwa RDB za kawaida hazikukidhi mahitaji, daima kulikuwa na njia mbadala.

Leo hali ni tofauti kidogo. Aina mbalimbali za maombi zinaongezeka, na kwa hiyo umuhimu wa vipengele hivi unakua. Na kadiri idadi ya hifadhidata inavyoongezeka, kipengele kimoja huanza kuangazia vingine vyote. Hii ni scalability. Kadiri programu nyingi zinavyoendeshwa chini ya upakiaji wa juu, kama vile huduma za wavuti, mahitaji yao ya scalability yanaweza kubadilika na kukua haraka sana. Tatizo la kwanza linaweza kuwa gumu sana kusuluhisha ikiwa una hifadhidata ya uhusiano iliyo kwenye seva yako mwenyewe. Wacha tuseme upakiaji wa seva mara tatu mara moja. Je, unaweza kuboresha maunzi yako kwa haraka vipi? Kutatua tatizo la pili pia husababisha matatizo wakati wa kutumia hifadhidata za uhusiano.

Hifadhidata za uhusiano huwa nzuri tu ikiwa ziko kwenye seva moja. Wakati rasilimali za seva hii zinaisha, utahitaji kuongeza mashine zaidi na kusambaza mzigo kati yao. Na hapa ndipo ugumu wa hifadhidata za uhusiano huanza kucheza dhidi ya scalability. Ukijaribu kuongeza idadi ya seva sio chache tu, lakini kwa mamia au maelfu, ugumu utaongezeka kwa amri ya ukubwa, na sifa zinazofanya hifadhidata za uhusiano kuvutia sana hupunguza nafasi za kuzitumia kama jukwaa. kwa mifumo mikubwa iliyosambazwa hadi sifuri.

Ili kubaki na ushindani, wachuuzi wa huduma ya wingu wanapaswa kwa namna fulani kukabiliana na kizuizi hiki, kwa sababu ni aina gani ya jukwaa la wingu bila hifadhi ya data inayoweza kuenea. Hii huwaacha wachuuzi na chaguo moja tu ikiwa wanataka kuwapa watumiaji nafasi kubwa ya kuhifadhi. Inahitajika kutumia aina zingine za hifadhidata ambazo zina uboreshaji wa hali ya juu, ingawa kwa gharama ya vipengele vingine vinavyopatikana katika hifadhidata za uhusiano.

Manufaa haya, pamoja na mahitaji yaliyopo kwao, yamesababisha wimbi la mifumo mipya ya usimamizi wa hifadhidata.

Wimbi jipya

Aina hii ya hifadhidata kwa kawaida huitwa duka la ufunguo-thamani. Kwa kweli, hakuna jina rasmi, kwa hivyo unaweza kuliona katika muktadha wa hifadhidata zenye mwelekeo wa hati, zenye mwelekeo wa sifa, zilizosambazwa (ingawa zinaweza pia kuwa za uhusiano), safu zilizopangwa zilizogawanywa, jedwali la heshi zilizosambazwa, na thamani ya ufunguo wa kuhifadhi. aina. Ingawa kila moja ya majina haya yanarejelea vipengele mahususi vya mfumo, zote ni tofauti kwenye mandhari ambayo tutayaita uhifadhi wa thamani-msingi.

Walakini, chochote unachokiita, aina hii ya "mpya" ya hifadhidata sio mpya na imekuwa ikitumika kila wakati haswa kwa programu ambazo utumiaji wa hifadhidata za uhusiano haungefaa. Hata hivyo, bila ya haja ya mtandao na wingu kwa scalability, mifumo hii ilibakia katika mahitaji kidogo. Sasa changamoto ni kuamua ni aina gani ya hifadhi inafaa zaidi kwa mfumo fulani.
Hifadhidata za uhusiano na duka za thamani kuu ni tofauti kimsingi na zimeundwa kutatua shida tofauti. Kulinganisha sifa itakuruhusu kuelewa tofauti kati yao, lakini wacha tuanze na hii:

Tabia za uhifadhi

Database ya uhusiano	Hifadhi ya thamani kuu
Hifadhidata ina majedwali, majedwali yana safu wima na safu mlalo, na safu mlalo inajumuisha thamani za safu wima. Safu zote za meza moja zina muundo sawa.	Kwa vikoa, mlinganisho unaweza kuchorwa na majedwali, lakini tofauti na jedwali, muundo wa data wa vikoa haujafafanuliwa. Kikoa ni sanduku ambalo unaweza kuweka chochote unachotaka. Rekodi ndani ya kikoa kimoja zinaweza kuwa na miundo tofauti.
Muundo wa data 1 umefafanuliwa mapema. Imechapwa kwa nguvu na ina vikwazo na uhusiano ili kuhakikisha uadilifu wa data.	Rekodi hutambulishwa kwa ufunguo, na kila rekodi kuwa na seti inayobadilika ya sifa zinazohusiana nayo.
Muundo wa data unatokana na uwakilishi asilia wa data iliyomo badala ya utendakazi wa programu.	Katika baadhi ya utekelezaji, sifa zinaweza tu kuwa kamba. Katika utekelezaji mwingine, sifa zina aina rahisi za data zinazoonyesha aina zinazotumiwa katika upangaji: nambari kamili, safu za safu, na orodha.
Muundo wa data umesasishwa ili kuepuka kurudia data. Kusawazisha kunaunda uhusiano kati ya jedwali. Uhusiano huunganisha data kutoka kwa meza tofauti.	Kati ya vikoa, na vile vile ndani ya kikoa kimoja, uhusiano haujafafanuliwa wazi.

Hakuna viungo

Maduka ya thamani kuu yana mwelekeo wa rekodi. Hii ina maana kwamba taarifa zote zinazohusiana na rekodi fulani huhifadhiwa nayo. Kikoa (ambacho unaweza kufikiria kama jedwali) kinaweza kuwa na maingizo mengi tofauti. Kwa mfano, kikoa kinaweza kuwa na taarifa kuhusu wateja na maagizo. Hii inamaanisha kuwa data huwa inarudiwa kati ya vikoa tofauti. Hii ni njia inayokubalika kwa sababu nafasi ya diski ni nafuu. Jambo kuu ni kwamba inakuwezesha kuhifadhi data zote zinazohusiana katika sehemu moja, ambayo inaboresha scalability kwani hakuna haja ya kujiunga na data kutoka kwa meza tofauti. Wakati wa kutumia hifadhidata ya uhusiano, itakuwa muhimu kutumia viungio kuweka taarifa muhimu katika sehemu moja.

Ingawa hitaji la mahusiano ya kuhifadhi jozi za thamani-msingi linashuka sana, mahusiano bado yanahitajika. Mahusiano kama haya kawaida huwa kati ya vyombo vya msingi. Kwa mfano, mfumo wa kuagiza utakuwa na rekodi ambazo zina data kuhusu wateja, bidhaa na maagizo. Haijalishi ikiwa data hii iko katika kikoa kimoja au katika kadhaa. Jambo la msingi ni kwamba mteja anapoagiza, labda hutaki kuhifadhi mteja na maelezo ya agizo katika rekodi sawa.
Badala yake, rekodi ya agizo lazima iwe na funguo zinazoelekeza kwa rekodi za mteja na bidhaa zinazolingana. Kwa kuwa rekodi zinaweza kuhifadhi taarifa yoyote, na mahusiano hayajafafanuliwa katika muundo wa data yenyewe, mfumo wa usimamizi wa hifadhidata hautaweza kuthibitisha uadilifu wa mahusiano. Hii inamaanisha kuwa unaweza kufuta wateja na bidhaa walizoagiza. Kuhakikisha uadilifu wa data unaangukia kwenye programu tumizi.

Ufikiaji wa data

Database ya uhusiano	Hifadhi ya thamani kuu
Data huundwa, kusasishwa, kufutwa na kuulizwa kwa kutumia Lugha ya Maswali Iliyoundwa (SQL).	Data huundwa, kusasishwa, kufutwa na kuulizwa kwa kutumia simu za mbinu za API.
Hoja za SQL zinaweza kupata data kutoka kwa jedwali moja au jedwali nyingi kwa kutumia viungio.	Utekelezaji fulani hutoa syntax inayofanana na SQL kwa kubainisha hali za kichujio.
Hoja za SQL zinaweza kujumuisha mijumuisho na vichujio changamano.	Mara nyingi unaweza tu kutumia viendeshaji vya ulinganisho vya kimsingi (=, !=,<, >, <= и =>).
Hifadhidata ya uhusiano kwa kawaida huwa na mantiki iliyojengewa ndani kama vile vichochezi, taratibu zilizohifadhiwa na vitendakazi.	Mantiki yote ya uadilifu wa biashara na data yamo katika msimbo wa maombi.

Mwingiliano na maombi

Maduka ya thamani kuu: faida

Kuna faida mbili za wazi za mifumo hiyo juu ya maduka ya uhusiano.

Inafaa kwa huduma za wingu

Faida ya kwanza ya duka za thamani kuu ni kwamba ni rahisi na kwa hivyo zinaweza kuongezeka zaidi kuliko hifadhidata za uhusiano. Ikiwa unakaribisha mfumo wako mwenyewe, na unapanga kuweka seva kadhaa au mia moja ambazo zitahitaji kushughulikia mizigo inayoongezeka nyuma ya hifadhi yako ya data, basi maduka ya thamani kuu ni chaguo lako.

Kwa sababu hifadhi kama hiyo inaweza kupanuliwa kwa urahisi na kwa nguvu, ni muhimu pia kwa wachuuzi ambao hutoa jukwaa la uhifadhi la wapangaji wengi kwenye wavuti. Hifadhidata kama hiyo inawakilisha njia ya bei nafuu ya kuhifadhi data na uwezo mkubwa wa kubadilika. Watumiaji kwa kawaida hulipa tu kile wanachotumia, lakini mahitaji yao yanaweza kukua. Muuzaji atakuwa na uwezo wa dynamically na kivitendo bila vikwazo kuongeza ukubwa wa jukwaa kulingana na mzigo.

Ushirikiano zaidi wa asili na msimbo

Muundo wa data wa uhusiano na modeli ya kitu cha msimbo kawaida huundwa kwa njia tofauti, na kusababisha kutopatana. Watengenezaji hutatua tatizo hili kwa kuandika msimbo unaoweka muundo wa uhusiano na muundo wa kitu. Mchakato huu hauna thamani iliyo wazi na inayoweza kufikiwa kwa haraka na inaweza kuchukua muda mwingi ambao ungeweza kutumika kutengeneza programu yenyewe. Wakati huo huo, maduka mengi ya thamani-msingi huhifadhi data katika muundo unaoweka vitu kwa njia asilia zaidi. Hii inaweza kupunguza kwa kiasi kikubwa wakati wa maendeleo.

Hoja zingine za kutumia duka za thamani kuu, kama "Hifadhidata ya uhusiano inaweza kuwa ngumu" (sijui inamaanisha nini, kwa njia), sio ya kulazimisha sana. Lakini kabla ya kuwa mtetezi wa hifadhi hiyo, soma sehemu inayofuata.

Duka za thamani kuu: hasara

Vikwazo katika hifadhidata za uhusiano huhakikisha uadilifu wa data katika kiwango cha chini kabisa. Data ambayo haikidhi vikwazo haiwezi kuingia kwenye hifadhidata. Katika maduka ya thamani kuu hakuna vikwazo hivyo, kwa hivyo ufuatiliaji wa uadilifu wa data hutegemea kabisa programu. Walakini, nambari yoyote ina makosa. Ingawa hitilafu katika hifadhidata ya uhusiano iliyoundwa vizuri kwa kawaida haileti matatizo ya uadilifu wa data, hitilafu katika maduka ya thamani kuu kwa kawaida husababisha.

Faida nyingine ya hifadhidata za uhusiano ni kwamba zinakulazimisha kupitia mchakato wa kuunda muundo wa data. Ikiwa umeunda mfano vizuri, hifadhidata itakuwa na muundo wa kimantiki ambao unaonyesha kikamilifu muundo wa data iliyohifadhiwa, lakini inapingana na muundo wa programu. Hii hufanya data kuwa huru kutoka kwa programu. Hii inamaanisha kuwa programu nyingine inaweza kutumia data sawa na mantiki ya programu inaweza kubadilishwa bila mabadiliko yoyote kwenye muundo wa hifadhidata. Ili kufanya vivyo hivyo na duka la thamani kuu, jaribu kubadilisha mchakato wa muundo wa muundo wa uhusiano na muundo wa darasa, ambao huunda madarasa ya jumla kulingana na muundo asilia wa data.

Na usisahau kuhusu utangamano. Tofauti na hifadhidata za uhusiano, hifadhi inayotegemea wingu ina viwango vichache vya kawaida. Ingawa si tofauti kimawazo, zote zina API tofauti, miingiliano ya ombi na maelezo yao wenyewe. Kwa hivyo, ni bora kumwamini muuzaji wako kwa sababu ikiwa kitu kitatokea, hutaweza kubadili kwa urahisi kwa mtoa huduma mwingine. Na kwa kuzingatia ukweli kwamba karibu maduka yote ya kisasa ya thamani-msingi yapo kwenye beta 2, uaminifu unakuwa hatari zaidi kuliko katika kesi ya kutumia hifadhidata za uhusiano.

Uchanganuzi mdogo wa data

Kwa kawaida, hifadhi zote za wingu hujengwa kwa misingi ya upangaji mbalimbali, ambayo ina maana kwamba idadi kubwa ya watumiaji na programu hutumia mfumo huo. Ili kuzuia mfumo mzima usitekwe nyara, wachuuzi kwa kawaida huzuia utekelezaji wa maombi kwa njia fulani. Kwa mfano, katika SimpleDB, hoja haiwezi kuchukua zaidi ya sekunde 5 kukamilika. Katika Google AppEngine Datastore, huwezi kupata zaidi ya rekodi 1000 katika ombi moja 3.

Vikwazo hivi sio vya kutisha kwa mantiki rahisi (kuunda, kusasisha, kufuta na kurejesha idadi ndogo ya rekodi). Lakini vipi ikiwa programu yako itakuwa maarufu? Una watumiaji wengi wapya na data nyingi mpya, na sasa ungependa kufanya matumizi mapya yapatikane kwa watumiaji au kwa namna fulani ufaidike na data. Hapa unaweza kuwa na wakati mgumu kutekeleza hata maswali rahisi kwa uchanganuzi wa data. Vipengele kama vile kufuatilia mifumo ya matumizi ya programu au mfumo wa mapendekezo kulingana na historia ya mtumiaji vinaweza kuwa vigumu kutekeleza vyema. Na mbaya zaidi, haziwezekani.

Katika kesi hii, kwa uchambuzi ni bora kufanya hifadhidata tofauti, ambayo itajazwa na data kutoka kwa duka lako la ufunguo wa thamani. Fikiria mapema jinsi hii inaweza kufanywa. Je, utakaribisha seva katika wingu au ndani ya nyumba? Je, kutakuwa na matatizo kutokana na ucheleweshaji wa ishara kati yako na mtoa huduma wako? Je, hifadhi yako inaweza kutumia uhamishaji huu wa data? Ikiwa una rekodi milioni 100, na unaweza kuchukua rekodi 1000 kwa wakati mmoja, itachukua kiasi gani kuhamisha data zote?

Walakini, usiweke kipaumbele cha uboreshaji zaidi ya yote. Haitakuwa na maana ikiwa watumiaji wako wataamua kutumia huduma za huduma nyingine kwa sababu hutoa vipengele na mipangilio zaidi.

Hifadhi ya wingu

Watoa huduma wengi wa wavuti hutoa maduka mengi ya thamani kuu ya wapangaji. Wengi wao hukutana na vigezo vilivyoorodheshwa hapo juu, lakini kila mmoja ana sifa zake tofauti na hutofautiana na viwango vilivyoelezwa hapo juu. Hebu tuangalie mifano mahususi ya hifadhi kama vile SimpleDB, Google AppEngine Datastore, na SQL Data Services.

Amazon: SimpleDB

SimpleDB ni duka la thamani la ufunguo lenye mwelekeo wa sifa lililojumuishwa na Amazon WebServices. SimpleDB iko kwenye beta; watumiaji wanaweza kuitumia bila malipo - mradi tu mahitaji yao hayazidi kikomo fulani.

SimpleDB ina mapungufu kadhaa. Kwanza, muda wa utekelezaji wa hoja ni mdogo kwa sekunde 5. Pili, hakuna aina za data isipokuwa kamba. Kila kitu kinahifadhiwa, kurejeshwa na kulinganishwa kama kamba, kwa hivyo ili kulinganisha tarehe utahitaji kuzibadilisha kuwa umbizo la ISO8601. Tatu, ukubwa wa juu wa mfuatano wowote ni baiti 1024, ambayo hupunguza ukubwa wa maandishi (kwa mfano, maelezo ya bidhaa) ambayo unaweza kuhifadhi kama sifa. Hata hivyo, kwa kuwa muundo wa data unaweza kunyumbulika, unaweza kushughulikia kikomo hiki kwa kuongeza sifa "Maelezo ya Bidhaa1", "Maelezo ya Bidhaa2", nk. Lakini idadi ya sifa pia ni mdogo - upeo wa sifa 256. Wakati SimpleDB iko katika beta, ukubwa wa kikoa ni gigabaiti 10 tu, na hifadhidata nzima haiwezi kuchukua zaidi ya terabyte 1.

Mojawapo ya sifa kuu za SimpleDB ni matumizi ya modeli ya uthabiti. Muundo huu unafaa kwa kazi zenye nyuzi nyingi, lakini fahamu kwamba mara tu unapobadilisha thamani ya sifa katika rekodi, usomaji unaofuata unaweza usione mabadiliko hayo. Uwezekano wa maendeleo hayo ya matukio ni ya chini kabisa, hata hivyo, ni lazima ikumbukwe. Hutaki kuuza tikiti ya mwisho kwa wanunuzi watano kwa sababu tu data yako haikuwa thabiti wakati wa mauzo.

Google AppEngine Data Store

Google AppEngine Datastore imeundwa juu ya BigTable, mfumo wa ndani wa Google wa kuhifadhi data. AppEngine Datastore haitoi ufikiaji wa moja kwa moja kwa BigTable, lakini inaweza kutambuliwa kama kiolesura kilichorahisishwa cha kuingiliana na BigTable.

AppEngine Datastore inasaidia aina zaidi za data ndani ya rekodi moja kuliko SimpleDB. Kwa mfano, orodha zinazoweza kuwa na mikusanyiko ndani ya rekodi.

Hili ndilo duka la data ambalo una uwezekano mkubwa wa kutumia unapotengeneza na Google AppEngine. Hata hivyo, tofauti na SimpleDB, hutaweza kutumia Hifadhidata ya AppEngine (au BigTable) nje ya Huduma za Wavuti za Google.

Microsoft: Huduma za Data za SQL

Huduma za Data za SQL ni sehemu ya jukwaa la Microsoft Azure. Huduma za Data ya SQL ni bure, katika beta, na ina vikomo vya ukubwa wa hifadhidata. Huduma za Data za SQL ni programu tofauti - nyongeza juu ya seva nyingi za SQL zinazohifadhi data. Maduka haya yanaweza kuwa ya uhusiano, lakini kwako SDS ni duka la thamani kuu, kama tu bidhaa zilizoelezwa hapo juu.

Hifadhi isiyo ya wingu

Pia kuna chaguo kadhaa za kuhifadhi ambazo unaweza kutumia nje ya wingu kwa kuzisakinisha mwenyewe. Takriban miradi hii yote ni changa, katika alpha au beta, na chanzo huria. Ukiwa na chanzo huria, unaweza kuwa na ufahamu zaidi wa matatizo na vikwazo vinavyowezekana kuliko bidhaa za wamiliki.

CouchDB

CouchDB ni hifadhidata inayopatikana bila malipo, chanzo wazi, inayoelekeza hati. JSON inatumika kama umbizo la kuhifadhi data. CouchDB inalenga kuziba pengo kati ya hifadhidata zenye mwelekeo wa hati na uhusiano kwa kutumia "maoni." Maoni kama hayo yana data kutoka kwa hati katika fomu inayofanana na jedwali na hukuruhusu kuunda faharasa na kuendesha maswali.

Kwa sasa, CouchDB si hifadhidata iliyosambazwa kikweli. Ina utendakazi wa urudufishaji unaokuruhusu kusawazisha data kati ya seva, lakini huu sio usambazaji unaohitajika ili kujenga mazingira hatarishi. Walakini, watengenezaji wa CouchDB wanafanyia kazi hili.

Mradi wa Voldemort

Mradi wa Voldemort ni hifadhidata iliyosambazwa ya thamani-msingi iliyoundwa ili kuongeza mlalo katika idadi kubwa ya seva. Ilizaliwa nje ya mchakato wa ukuzaji wa LinkedIn na imetumika kwa mifumo kadhaa iliyo na mahitaji ya hali ya juu. Mradi wa Voldemort pia hutumia mfano wa uthabiti wa mwisho.

Mongo

Mongo ni hifadhidata iliyotengenezwa katika 10gen na Geir Magnusson na Dwight Merriman (ambao unaweza kuwajua kutoka DoubleClick). Kama vile CouchDB, Mongo ni hifadhidata inayoelekeza hati ambayo huhifadhi data katika umbizo la JSON. Walakini, Mongo ni msingi wa kitu kuliko duka safi la thamani ya ufunguo.

Kunyesha

Drizzle inawakilisha mbinu tofauti sana ya kutatua matatizo ambayo maduka ya thamani kuu yameundwa kukabiliana nayo. Drizzle ilianza kama uma wa MySQL 6.0. Baadaye, wasanidi programu waliondoa idadi ya vitendakazi (ikiwa ni pamoja na mionekano, vichochezi, misemo iliyokusanywa, taratibu zilizohifadhiwa, akiba ya hoja, ACL na baadhi ya aina za data) ili kuunda DBMS rahisi na ya haraka zaidi. Hata hivyo, Drizzle bado inaweza kutumika kuhifadhi data ya uhusiano. Lengo la wasanidi programu ni kujenga jukwaa la nusu-mahusiano lililoundwa kwa ajili ya programu za wavuti na za wingu zinazoendeshwa kwenye mifumo yenye viini 16 au zaidi.

Suluhisho

Hatimaye, kuna sababu nne kwa nini unaweza kuchagua hifadhi ya thamani ya ufunguo isiyo ya uhusiano kwa programu yako:

1. Data yako ina mwelekeo wa hati sana, na inafaa zaidi kwa muundo wa data ya thamani kuu kuliko muundo wa uhusiano.
2. Muundo wa kikoa chako una mwelekeo wa juu wa kitu, kwa hivyo kutumia hifadhi ya thamani-msingi kutapunguza kiwango cha msimbo wa ziada unaohitajika ili kubadilisha data.
3. Ghala la data ni la bei nafuu na linaunganishwa kwa urahisi na huduma za wavuti za mchuuzi wako.
4. Tatizo lako kuu ni kuongezeka kwa uhitaji.

Hata hivyo, unapofanya uamuzi wako, fahamu vikwazo vya hifadhidata mahususi na hatari utakazokabiliana nazo ikiwa utapitia njia ya kutumia hifadhidata zisizo za uhusiano.

Kwa mahitaji mengine yote, ni bora kuchagua DBMS nzuri ya zamani ya uhusiano. Kwa hiyo wamehukumiwa? Bila shaka hapana. Angalau kwa sasa.

1 - kwa maoni yangu, neno "muundo wa data" linafaa zaidi hapa, lakini niliacha mfano wa awali wa data.
2 - uwezekano mkubwa, mwandishi alimaanisha kuwa kwa suala la uwezo wao, hifadhidata zisizo za uhusiano ni duni kwa zile za uhusiano.
3 - data inaweza kuwa tayari imepitwa na wakati; makala ni ya Februari 2009.

Ongeza vitambulisho

Mfano wa uhusiano

Mtindo wa hifadhidata ya uhusiano ulipendekezwa mnamo 1969 na mwanahisabati na mtafiti wa IBM E.F. Codd (E.F. Codd). Kwa habari kadhaa za kimsingi kuhusu hifadhidata za uhusiano, angalia nakala ya muhtasari " DB na DBMS" 2. Kwa kuwa hifadhidata za uhusiano kwa sasa ni kubwa, katika nakala hii (na vile vile katika vifungu " Maelezo ya data”, “Usindikaji wa data"Na" Ubunifu wa hifadhidata” 2) dhana muhimu zaidi za modeli ya uhusiano zinajadiliwa kwa undani.

Hebu tukumbuke mara moja kwamba nadharia ya hifadhidata za uhusiano iliundwa hapo awali kwa lugha kali ya hisabati, na ni dhana kali, iliyofafanuliwa rasmi ambayo inaelezea vyema kiini cha mambo. Wakati huo huo, katika hali nyingi inawezekana, bila uharibifu mkubwa, kutoa dhabihu ya ukali wa istilahi kwa ajili ya uwazi wa uwasilishaji, ambayo ndiyo tutajaribu kufanya.

Wazo kuu la mfano wa uhusiano ni kama ifuatavyo. Hifadhidata ina mfululizo wa zisizo na mpangilio meza(katika kesi rahisi - kutoka meza moja). Majedwali yanaweza kubadilishwa kupitia shughuli zisizo za kitaratibu (za kutangaza) - maombi, matokeo ambayo pia ni meza.

Mara nyingi neno "uhusiano" ( ya uhusiano) katika neno "mfano wa uhusiano" inafasiriwa kulingana na ukweli kwamba miunganisho imeanzishwa katika hifadhidata ya uhusiano ( kuhusiana) kati ya meza. Ufafanuzi huu ni rahisi, lakini sio sahihi. Katika mfumo wa asili wa masharti ya Codd, masharti ya unganisho ( mahusiano), sifa ( sifa) na nakala ( tuples) zilitumika ambapo wengi wetu tunatumia istilahi zinazojulikana zaidi, jedwali, safu wima (sehemu) na safu mlalo (rekodi).

Wakati wa kuunda modeli ya habari ya eneo la somo (tazama " DB na DBMS”, “Ubunifu wa hifadhidata” 2) jitokeze kiini(vitu), vielezee mali a (sifa, sifa) ambazo ni muhimu kwa madhumuni ya uundaji, na miunganisho kati ya taasisi imeanzishwa. Katika hatua ya mpito kutoka kwa infological hadi mfano wa uhusiano wa datalogical, meza zinaonekana. Kwa kawaida, kila chombo kinawakilishwa na jedwali moja. Kila safu ya jedwali (rekodi moja) inalingana na mfano mmoja wa huluki, na kila sehemu inaelezea mali fulani (sifa).

Kwa mfano, ikiwa tunahitaji kuhifadhi habari kuhusu watu, ikiwa ni pamoja na jina la mwisho la kila mtu, jina la kwanza, patronymic, TIN, nchi ya makazi na tarehe ya kuzaliwa, basi huluki ni mtu, na data iliyobainishwa ni sifa. Chombo yenyewe kawaida huwa jina la meza.

Jedwali "Mtu"

Mfano wa uhusiano unahitaji kwamba kila safu kwenye meza iwe ya kipekee, i.e. ili safu mlalo zozote mbili zitofautiane katika thamani ya angalau sifa moja.

Fomu ya jadi ya jedwali ni muhimu wakati unahitaji kuwasilisha data yenyewe. Ikiwa, kama katika mfano hapo juu, unavutiwa tu muundo- majina ya uwanja, basi kutoka kwa mtazamo wa uwazi, urahisi wa kutumia katika michoro na kuhifadhi nafasi, ni rahisi zaidi kuionyesha kama ifuatavyo:

Funguo

Ufunguo mezani sehemu au kikundi cha sehemu zilizo na thamani za kipekee ndani ya jedwali fulani. Ufunguo hutambulisha safu mlalo ya jedwali kwa njia ya kipekee. Ikiwa ufunguo una shamba moja, mara nyingi huitwa rahisi, ikiwa kutoka kwa kadhaa - mchanganyiko. Katika mfano hapo juu, ufunguo ni uga wa TIN (tunadhani inajulikana kuwa TIN ni za kipekee ndani ya nchi).

Hebu tuangalie mfano wa meza yenye ufunguo wa composite. Tovuti za utabiri wa hali ya hewa mara nyingi huwasilisha habari kama ifuatavyo: kwa kila tarehe, zinaonyesha halijoto iliyotabiriwa usiku, asubuhi, alasiri na jioni. Ili kuhifadhi habari hii, unaweza kutumia meza kama hii:

Katika jedwali hili, si sehemu za Tarehe, Saa ya Siku au Halijoto - maadili yanaweza kurudiwa katika kila moja ya sehemu hizi. Lakini mchanganyiko wa Tarehe + Muda wa sehemu za siku ni za kipekee na hubainisha safu mlalo ya jedwali kwa njia ya kipekee. Huu ni ufunguo wa mchanganyiko.

Mara nyingi kuna hali ambazo uchaguzi wa ufunguo sio wazi. Hebu turudi kwenye mfano wa kwanza. Hebu sema kwamba pamoja na jina la mwisho, jina la kwanza, patronymic, TIN, tarehe ya kuzaliwa, inahitajika kuhifadhi mfululizo na idadi ya pasipoti ya jumla na mfululizo na idadi ya pasipoti ya kigeni. Jedwali litaonekana kama hii:

Unaweza kuchagua funguo nyingi kama tatu kwenye jedwali hili. Mmoja wao ni rahisi (TIN), wengine wawili ni composite (Mfululizo + Nambari ya pasipoti ya Jumla na Mfululizo + Nambari ya pasipoti ya Nje). Katika hali hiyo, msanidi huchagua ufunguo ambao ni rahisi zaidi kutoka kwa mtazamo wa kuandaa database (kwa ujumla, ufunguo ambao thamani yake inachukua muda mdogo kupata). Kitufe kilichochaguliwa katika kesi hii mara nyingi huitwa ufunguo kuu, au msingi, ufunguo, na michanganyiko mingine ya safu wima ambayo ufunguo unaweza kufanywa ni inawezekana, au funguo mbadala. Kumbuka kwamba daima kuna angalau ufunguo mmoja unaowezekana katika meza, kwani safu haziwezi kurudiwa na, kwa hiyo, mchanganyiko wa safu zote umehakikishiwa kuwa ufunguo unaowezekana.

Wakati wa kuonyesha meza, ni kawaida kuonyesha funguo kuu za meza. Kwa mfano, nyanja zinazohusika mara nyingi hupigwa mstari. Na Microsoft Access inaangazia sehemu muhimu kwa herufi nzito.

Hata mara nyingi zaidi kuliko kwa utata katika kuchagua ufunguo, watengenezaji wanakabiliwa na kutokuwepo kwa ufunguo kati ya data ambayo inahitaji kuhifadhiwa. Ukweli sawa unaweza kuanzishwa katika mchakato wa kuchambua eneo la somo. Kwa mfano, ikiwa unahitaji kuhifadhi orodha rahisi ya watu - majina ya kwanza, majina ya mwisho, patronymics na tarehe za kuzaliwa, basi hakuna ufunguo katika seti hii ya sifa wakati wote - hali inayowezekana ni wakati watu wawili tofauti wana sawa. data kabisa. Katika kesi hii, lazima uingie kwa bandia uwanja wa ziada, kwa mfano, nambari ya kipekee ya mtu. Ufunguo kama huo wakati mwingine huitwa katika fasihi mbadala. Mara nyingi ufunguo wa mbadala huletwa kwa sababu za ufanisi. Ikiwa, kwa mfano, jedwali lina ufunguo mrefu wa utunzi, basi watengenezaji mara nyingi huanzisha ufunguo mfupi wa ziada wa nambari na kuufanya kuwa ufunguo msingi. Hii inafanywa mara nyingi hata ikiwa kuna ufunguo rahisi ambao una aina ya data "isiyofaa" (isiyofaa kwa kutafuta), kwa mfano, kamba. Shughuli hizo hazihusiani tena na nadharia, lakini mara nyingi hukutana katika mazoezi.

Msomaji makini anaweza kutambua kwamba ufunguo unaweza karibu kila mara kupanuliwa (isipokuwa ikiwa inajumuisha sehemu zote za jedwali) kwa kujumuisha sehemu zisizohitajika. Hapo awali, ufunguo kama huo utabaki kuwa ufunguo, lakini kutoka kwa mtazamo wa vitendo, huu ni mchezo wa dhana tu. Vifunguo vile hazifikiriwi hata iwezekanavyo, kwani daima ni muhimu kujitahidi kupunguza urefu (utata) wa ufunguo.

Fomu za kawaida, kuhalalisha

Sio kila jedwali ambalo tunaweza kuchora kwenye karatasi au kwa Neno linaweza kuwa jedwali la hifadhidata la uhusiano. Na sio kila jedwali ambalo linaweza kutumika katika hifadhidata ya uhusiano ni sahihi kutoka kwa mtazamo wa hitaji la mfano wa uhusiano.

Kwanza, inahitaji data zote ndani ya safuwima sawa ziwe za aina moja(kuhusu aina tazama“Maelezo ya data” 2). Kwa mtazamo huu, mfano hapa chini hauna maana hata kujadili:

Pili, inahitaji jedwali kuwa na ufunguo msingi uliokabidhiwa.

Mahitaji haya ni muhimu, lakini hayatoshi. Nadharia ya hifadhidata za uhusiano huleta dhana za kinachojulikana kama "aina za kawaida" - mahitaji ya kupanga data katika jedwali. Fomu za kawaida hupewa nambari kwa kufuatana kadri mahitaji yanavyozidi kuwa magumu. Katika hifadhidata iliyoundwa vizuri, jedwali ziko katika angalau fomu ya tatu ya kawaida. Ipasavyo, tutazingatia fomu tatu za kwanza za kawaida. Hebu tukumbuke kwamba tunashughulika na majedwali ambayo yanakidhi mahitaji mawili ya msingi yaliyoundwa hapo juu.

Fomu ya kwanza ya kawaida (1NF)

Fomu ya kwanza ya kawaida inaamuru kwamba data zote zilizomo kwenye jedwali lazima ziwe za atomiki(isiyogawanyika) Orodha ya aina zinazolingana za data ya atomiki imedhamiriwa na DBMS. Mahitaji ya 1NF ni ya asili kabisa. Ina maana kwamba kila sehemu ya kila rekodi inapaswa kuwa na thamani moja pekee, na si safu au muundo wowote wa data. Hebu tutoe mfano wa maana wa jedwali ambalo haliko katika 1NF. Hebu tuwe na orodha za alama za wanafunzi katika somo fulani.

Kwa kuwa thamani ya sehemu ya Ukadiriaji si ya atomiki, jedwali halikidhi mahitaji ya 1NF.

Njia inayowezekana ya kuwasilisha orodha ya ukadiriaji imeelezewa katika miongozo ya kifungu. Muundo wa DB 2.

Fomu ya pili ya kawaida (2NF)

Jedwali linasemekana kuwa katika umbo la pili la kawaida ikiwa liko katika 1NF na kila safu wima isiyo ya ufunguo inategemea kabisa ufunguo msingi. Kwa maneno mengine, thamani ya kila sehemu lazima iamuliwe kabisa na thamani ya ufunguo msingi. Ni muhimu kutambua kwamba utegemezi wa ufunguo wa msingi unaeleweka kwa usahihi kama utegemezi wa ufunguo kwa ujumla, na si kwa sehemu yake binafsi (katika kesi ya ufunguo wa composite). Wacha tutoe mfano wa jedwali ambalo haliko katika 2NF. Ili kufanya hivyo, hebu turudi kwa mfano wa utabiri wa hali ya hewa na kuongeza safu nyingine kwenye meza - wakati wa jua (hii ni mfano unaowezekana kabisa; aina hii ya habari mara nyingi hutolewa kwenye maeneo ya utabiri wa hali ya hewa).

Kama tunavyokumbuka, jedwali hili lina ufunguo wa mchanganyiko Tarehe+Muda wa siku. Sehemu ya Joto inategemea kabisa ufunguo wa msingi - hakuna shida nayo. Lakini uga wa Mawio hutegemea tu uga wa Tarehe. Muda wa siku hauathiri kwa kawaida wakati wa kuchomoza kwa jua.

Hapa inafaa kuuliza swali: ni nini maana ya vitendo ya 2NF? Je, ni faida gani ya vikwazo hivi? Inageuka ni kubwa. Hebu tuseme kwamba katika mfano hapo juu msanidi hupuuza mahitaji ya 2NF. Kwanza, kinachojulikana upungufu- uhifadhi wa data zisizo za lazima. Baada ya yote, ikiwa kwa rekodi moja na tarehe iliyotolewa wakati wa jua tayari umehifadhiwa, basi kwa rekodi nyingine zote zilizo na tarehe iliyopewa inapaswa kuwa sawa na, kwa ujumla, hakuna haja ya kuihifadhi.

Wacha tuzingatie maneno "inapaswa kuwa". Je, ikiwa haifanyi hivyo? Baada ya yote, katika kiwango cha hifadhidata hii haijadhibitiwa kwa njia yoyote - ufunguo kwenye jedwali ni mchanganyiko, kunaweza kuwa na tarehe zinazofanana (na kwa maana ya uwezekano mkubwa kutakuwa na). Na hakuna vikwazo rasmi (na ufahamu wetu kwamba "hii haiwezi kutokea" sio mmoja wao) inakataza kuonyesha nyakati tofauti za jua kwa tarehe sawa.

Fomu ya tatu ya kawaida (3NF)

Jedwali linasemekana kuwa katika 3NF ikiwa ni 2NF na safu wima zote zisizo muhimu zinajitegemea.

Utegemezi wa pande zote wa safu wima unaeleweka kwa urahisi kama ifuatavyo: Safu zinategemeana ikiwa haiwezekani kubadilisha moja yao bila kubadilisha nyingine.

Wacha tutoe mfano wa jedwali ambalo haliko katika 3NF. Hebu fikiria mfano wa daftari rahisi ya kuhifadhi nambari za simu za nyumbani za watu wanaoishi, labda, katika mikoa mbalimbali ya nchi.

Jedwali hili lina utegemezi kati ya safu wima zisizo muhimu Msimbo wa Jiji na Jiji, kwa hivyo jedwali haliko katika 3NF.

Kumbuka kuwa msanidi huamua uwepo wa utegemezi hapo juu kwa kuchambua eneo la somo - mgongano kama huo hauwezi kuonekana kwa njia rasmi. Wakati wa kubadilisha mali ya eneo la somo, utegemezi kati ya nguzo unaweza kutoweka. Kwa mfano, ikiwa nambari tofauti zimeingizwa ndani ya jiji moja (kama 495 na 499 huko Moscow), safu wima zinazolingana hazihusiani tena kwa ukiukaji wa mahitaji ya 3NF.

Katika nadharia ya hifadhidata za uhusiano, fomu za mpangilio wa juu pia huzingatiwa - fomu ya kawaida ya Boyce-Codd, 4NF, 5NF na hata ya juu zaidi. Fomu hizi hazina umuhimu mkubwa wa vitendo, na watengenezaji, kama sheria, daima husimama kwenye 3NF.

Urekebishaji wa hifadhidata

Kusawazisha ni mchakato wa kupunguza jedwali la hifadhidata hadi fomu ya kawaida iliyochaguliwa. Kusawazisha hadi 2NF, kama sheria, huja hadi kuharibika - kugawanya jedwali moja katika kadhaa. Kurekebisha kwa 3NF kwa kawaida kunaweza kukamilishwa kwa kuondoa safu tegemezi (zilizokokotolewa). Katika baadhi ya matukio, wakati wa kurekebisha kwa 3NF, unapaswa pia kufanya mtengano.

Hifadhidata za meza nyingi, uhusiano kati ya meza, funguo za kigeni

Kwa mazoezi, hifadhidata za meza moja ni nadra sana, kwani kutoka kwa mtazamo wa kuunda hifadhidata ya kikoa, uwepo wa meza moja inamaanisha uwepo wa chombo kimoja. Kwa upande mwingine, uwepo wa vyombo kadhaa kawaida inamaanisha uwepo wa viunganisho kati yao.

Bila kuweka lengo la muundo kamili wa hifadhidata, hebu tuzingatie mfano unaoturuhusu kuonyesha uhusiano katika hifadhidata za jedwali nyingi.

Tuseme tunashughulika na shule ambayo kuna wanafunzi waliopangwa katika madarasa na walimu wanaofundisha masomo fulani. Mara moja tunatofautisha vyombo vinne: wanafunzi, walimu, madarasa na vitu. Vyombo hivi tayari vinatupa jedwali nne.

Ifuatayo, tunahitaji kutatua suala la sifa za chombo - ni aina gani ya habari tutakayohifadhi. Kwa kuwa mfano wetu ni kwa madhumuni ya onyesho pekee, tutajaribu kupunguza kiasi cha maelezo yaliyohifadhiwa. Tutakubali kuhifadhi jina na jina la kwanza kwa kila mwanafunzi, kwa darasa - nambari inayofanana na barua inayotambulisha darasa ndani ya sambamba, kwa mwalimu - jina la ukoo, jina la kwanza na patronymic, kwa somo - jina lake tu. .

Sasa tunahitaji kutatua suala hilo na funguo za msingi. Jedwali la mwanafunzi na mwalimu kimsingi hazina ufunguo, kwa hivyo tutaanzisha ufunguo wa nambari wa ziada ndani yao - nambari. Jedwali la madarasa na vitu, kwa ujumla, zina funguo. Katika meza ya madarasa, ufunguo ni mchanganyiko, huundwa na sifa Nambari ya Sambamba + Barua, na katika meza ya vitu, ufunguo rahisi una shamba moja - jina la kitu. Kumbuka kwamba tulipozungumza kuhusu funguo, tulitaja kwamba funguo za ziada mara nyingi huongezwa kwa sababu za ufanisi, kujaribu kuondoa funguo za kiwanja au sehemu muhimu za aina zisizofaa, kama vile kamba. Hiyo ndiyo tutafanya. Wacha tuongeze ufunguo wa nambari mbadala kwa kila jedwali.

Kama matokeo, tutapokea seti ifuatayo ya meza zinazolingana na vyombo vilivyoelezewa.

Kuelewa ni mada gani tunashughulikia, tunajua kuwa huluki zetu hazipo zenyewe - zimeunganishwa na uhusiano fulani ambao tumeelezea hapo juu. Lakini jinsi ya kuwaunganisha kitaalam? Hapa huwezi kufanya bila kuanzisha sehemu za ziada na hata meza za ziada. Wacha tuangalie uhusiano kati ya vyombo kwa mpangilio.

Ili kumpa mwanafunzi darasa fulani, tunaongeza sehemu ya ziada ya Nambari ya Darasa kwenye jedwali la "Mwanafunzi". (Ni wazi kwamba aina yake lazima ilingane kabisa na aina ya sehemu ya Nambari ya Darasa kwenye jedwali la “Darasa”.) Sasa tunaweza kuunganisha jedwali la “Mwanafunzi” na “Darasa” kwa kutumia thamani zinazolingana za sehemu za Nambari za Darasa. (sio kwa bahati kwamba tulitaja nyanja hizi sawa, katika mazoezi Hii mara nyingi hufanyika ili kuzunguka kwa urahisi mashamba ya kuunganisha). Kumbuka kuwa rekodi moja kwenye jedwali la "Darasa" inaweza kuendana na rekodi nyingi kwenye jedwali la "Mwanafunzi" (na kwa mazoezi uwezekano mkubwa unalingana - ni ngumu kufikiria darasa la mwanafunzi mmoja). Jedwali kama hizo zinasemekana kuhusishwa na uhusiano " moja kwa wengi" Na sehemu ya Nambari ya Darasa kwenye jedwali la "Mwanafunzi" inaitwa ufunguo wa kigeni. Kama unaweza kuona, madhumuni ya funguo za kigeni ni kuunganisha meza. Kumbuka kuwa ufunguo wa kigeni daima unarejelea ufunguo msingi wa jedwali linalohusiana (yaani, ufunguo wa kigeni uko upande wa "nyingi"). Ufunguo wa msingi unaohusishwa na mgeni unaitwa mzazi, ingawa neno hili linatumika mara chache.

Hebu tuonyeshe hili na mchoro katika mtindo wa Upatikanaji wa Microsoft (maelezo zaidi kuhusu Ufikiaji "Schema ya Data" imeandikwa katika makala. "Maelezo ya data" 2).

Sasa hebu tufikirie kuhusu walimu na masomo. Kuchambua eneo la somo (hii ndio njia pekee - baada ya yote, haiwezekani kutoa hali ya kweli ya mambo kutoka kwa mfano rasmi yenyewe), tunagundua kuwa aina ya unganisho kati ya vyombo "mwalimu" na "somo" ni tofauti. kutokana na hayo yaliyojadiliwa hapo juu. Baada ya yote, sio tu walimu wengi wanaweza kufundisha somo moja, lakini mwalimu mmoja anaweza kufundisha masomo mengi. Kwa hivyo, kuna uhusiano kati ya vyombo hivi " wengi kwa wengi" Hapa huwezi kufanya bila kuanzisha nyuga za ziada (jaribu!). Mahusiano mengi hadi mengi yanatatuliwa kila wakati kwa kuanzisha jedwali la ziada. Yaani, tunapanga jedwali la "Somo la Mwalimu", ambalo lina muundo ufuatao:

Jedwali "Somo la Mwalimu"

Jedwali hili lina kitufe cha mchanganyiko kilichoundwa kutoka kwa sehemu zake mbili. Jedwali la "Mwalimu" na jedwali la "Somo" zinahusiana na jedwali hili katika uhusiano wa mtu mmoja hadi wengi (bila shaka, katika hali zote mbili "wengi" ni upande wa "Mwalimu-Somo"). Ipasavyo, katika jedwali la "Somo la Mwalimu" kuna funguo mbili za kigeni (zote ni sehemu za ufunguo wa msingi wa mchanganyiko, ambao hauruhusiwi), ambao hutumikia kuunganisha na meza zinazofanana.

Kwa mazoezi, pamoja na uhusiano unaozingatiwa "mmoja-kwa-wengi" na "wengi-kwa-wengi", pia kuna uhusiano " moja kwa moja" Kutoka kwa mtazamo wa kinadharia, uhusiano kama huo sio wa kupendeza, kwani meza mbili zilizounganishwa na uhusiano wa moja hadi moja zinaweza kuunganishwa kila wakati kuwa moja. Hata hivyo, katika hifadhidata halisi, uhusiano wa mtu-mmoja hutumiwa kuboresha usindikaji wa data. Hebu tuonyeshe hili kwa mfano.

Hebu tuseme tunahifadhi habari nyingi tofauti kuhusu watu - data kutoka kwa kila aina ya nyaraka, nambari za simu, anwani, nk. Uwezekano mkubwa zaidi, data hii itatumika mara chache sana. Na mara nyingi tunahitaji tu jina la mwisho, jina la kwanza, patronymic na nambari ya simu. Kisha ni mantiki kuandaa meza mbili na kuzihusisha katika uhusiano wa moja hadi moja. Hifadhi habari inayotumiwa mara kwa mara kwenye jedwali moja (ndogo), na iliyobaki kwenye jedwali lingine. Kwa kawaida, majedwali yanayohusiana na uhusiano wa mtu mmoja hadi mmoja yana ufunguo sawa wa msingi.

Kanuni za Uadilifu

Muundo wa uhusiano unafafanua sheria mbili za jumla za uadilifu wa hifadhidata: uadilifu wa kitu na uadilifu wa marejeleo.

Kanuni ya Uadilifu vitu rahisi sana. Ni inahitaji funguo za msingi za jedwali hazina maadili (null)..

Kanuni ya uadilifu wa marejeleo inahitaji funguo za kigeni zisiwe na thamani ambazo haziendani na funguo zao kuu. Tukirudi kwenye mfano uliojadiliwa hapo juu, ni lazima tuhitaji, kwa mfano, kwamba wanafunzi wawe wa darasa pekee ambalo nambari yake imeonyeshwa kwenye jedwali la “Madarasa”.

DBMS nyingi zinaweza kufuatilia uadilifu wa data (bila shaka, hii inahitaji juhudi sambamba kutoka kwa msanidi katika hatua ya kuelezea miundo ya data). Hasa, mbinu hutumiwa kudumisha uadilifu wa marejeleo kuteleza shughuli. Cascading inamaanisha, haswa, kwamba wakati wa kufuta rekodi kutoka kwa jedwali la "mzazi" ambalo limeunganishwa kwenye jedwali lingine na uhusiano wa mtu mmoja hadi wengi, rekodi zote zinazohusiana hufutwa kiatomati kutoka kwa jedwali "nyingi" (na DBMS yenyewe, bila kuingilia kati kwa mtumiaji). Na hii ni ya asili, kwa sababu rekodi kama hizo "huning'inia angani"; hazijaunganishwa tena na chochote.

Kuweka faharasa

Kuorodhesha ni muhimu sana kutoka kwa mtazamo wa matumizi ya vitendo, lakini ni ya hiari kutoka kwa mtazamo wa nadharia safi. Kusudi kuu la kuorodhesha ni kuongeza (kuharakisha) utaftaji (na, ipasavyo, shughuli zingine na hifadhidata). Kuorodhesha kwa hali yoyote kunahitaji rasilimali za ziada (faili maalum za faharisi mara nyingi huundwa kwa kiwango cha mwili). Uwekaji faharasa unaweza hata kupunguza kasi ya utendakazi kuhusiana na urekebishaji wa data; kwa hivyo, majedwali ambayo ni nadra sana kurekebishwa na kutafutwa mara kwa mara kwa kawaida huwa katika faharasa.

Faili ya faharasa inafanana sana na faharasa ya kawaida ya vitabu. Kwa kila thamani ya faharasa, orodha ya safu mlalo za jedwali zilizo na thamani hiyo huhifadhiwa. Ipasavyo, kutafuta, hauitaji kutazama jedwali zima - angalia tu kwenye faharisi. Walakini, wakati wa kurekebisha rekodi, unaweza kuhitaji kuunda upya faharasa. Na hii inachukua muda wa ziada.

Bila shaka, hakuna swali la kuwasilisha nadharia ya hifadhidata za uhusiano kama sehemu ya kozi ya msingi ya sayansi ya kompyuta! Walakini, nakala hii ni muhimu sana kwa ensaiklopidia yetu, kwani katika kesi hii tunashughulika na nyenzo ambazo haziwezi kuwasilishwa kikamilifu katika masomo, lakini mwalimu lazima ajue. Kwa nini?

Kwanza, kwa sababu idadi ya dhana husomwa ndani ya mfumo wa kozi ya msingi. Hii inajumuisha mwonekano wa jedwali wa data na vitufe vya jedwali. Na sote tunajua kuwa ni ngumu sana kuwasilisha kwa usahihi na kwa usahihi dhana kadhaa bila kuwasilisha picha ya jumla.

Pili, kufanya maswali rahisi ya hifadhidata na watoto (nyenzo husika zimewasilishwa katika kifungu "Uchakataji wa data" 2), inahitajika kushughulikia majedwali ambayo ni sahihi kutoka kwa mtazamo wa nadharia ya uhusiano. Hakuna haja ya kuelezea kwa wanafunzi kwamba meza hizi ni sahihi, lakini "ikiwa tu ..., basi meza itakuwa sahihi," lakini haikubaliki kutumia mifano mbaya.

Katika kozi maalum ya sayansi ya kompyuta, hali inaweza kuwa tofauti kabisa. Njia muhimu zaidi na yenye tija sana ya kazi katika madarasa maalum ni kazi ya mradi. Kama sehemu ya miradi ya kielimu, inawezekana na ni muhimu kukuza hifadhidata rahisi, na hapa mtu hawezi kufanya bila misingi ya nadharia iliyowasilishwa. Walakini, yafuatayo lazima izingatiwe:

Maeneo ya somo yanayoigwa yasiwe makubwa sana;

Wanapaswa kujulikana sana kwa wanafunzi (kwa maana hii, mradi wa "Shule", ambao kila mtu alichoshwa nao, sio chaguo mbaya zaidi!);

Ni ujinga kutarajia kwamba baada ya kusikiliza misingi ya nadharia, wanafunzi wataweza kubuni kitu wenyewe. Lazima upitie kila hatua pamoja nao, ukihalalisha matendo yako kwa undani.

Hifadhidata zote za kisasa hutumia CBO (Uboreshaji Kulingana na Gharama), uboreshaji wa gharama. Kiini chake kiko katika ukweli kwamba kwa kila operesheni "gharama" yake imedhamiriwa, na kisha gharama ya jumla ya ombi imepunguzwa kwa kutumia minyororo "ya bei nafuu" ya shughuli.

Ili kuelewa vyema uboreshaji wa gharama, tutaangalia njia tatu za kawaida za kuunganisha majedwali mawili na kuona jinsi hata hoja rahisi ya kujiunga inaweza kugeuka kuwa ndoto mbaya ya kiboreshaji. Katika majadiliano yetu, tutazingatia utata wa wakati, ingawa optimizer huhesabu "gharama" kulingana na rasilimali za processor, kumbukumbu na shughuli za I / O. Ni kwamba utata wa wakati ni dhana ya takriban, na kuamua rasilimali zinazohitajika za processor, unahitaji kuhesabu shughuli zote, ikiwa ni pamoja na kuongeza, ikiwa kauli, kuzidisha, iteration, nk.

Mbali na hilo:

• Ili kufanya kila operesheni ya kiwango cha juu, processor hufanya idadi tofauti ya shughuli za kiwango cha chini.
• Gharama ya shughuli za processor (kwa suala la mizunguko) inatofautiana kati ya aina tofauti za wasindikaji, yaani, inategemea usanifu maalum wa CPU.

Kwa hiyo, itakuwa rahisi kwetu kutathmini kwa namna ya utata. Lakini kumbuka kuwa utendaji wa hifadhidata mara nyingi hupunguzwa na mfumo mdogo wa diski, na sio rasilimali za processor.

Tulizungumza juu yao tulipoangalia miti ya B. Kama unavyokumbuka, faharisi tayari zimepangwa. Kwa njia, kuna aina nyingine za indexes, kwa mfano, index ya bitmap. Lakini hazitoi faida yoyote katika suala la CPU, kumbukumbu, na utumiaji wa diski ikilinganishwa na faharisi za miti ya B. Kwa kuongezea, hifadhidata nyingi za kisasa zinaweza kuunda faharasa za muda kwa maswali yanayoendelea ikiwa hii itasaidia kupunguza gharama ya kutekeleza mpango.

4.4.2. Mbinu za kukata rufaa

Kabla ya kutumia waendeshaji wa umoja, lazima kwanza upate data inayohitajika. Unaweza kufanya hivyo kwa njia zifuatazo.

• Scan kamili. Hifadhidata inasoma tu jedwali zima au faharasa. Kama unavyoelewa, kwa mfumo mdogo wa diski ni rahisi kusoma faharisi kuliko meza.
• Uchanganuzi wa masafa. Hutumika kwa mfano unapotumia viambishi kama WHERE UMRI > 20 NA UMRI< 40. Конечно, для сканирования диапазона индекса вам нужно иметь индекс для поля AGE.

  Katika sehemu ya kwanza ya kifungu, tayari tumegundua kuwa uchangamano wa saa wa hoja ya masafa hufafanuliwa kama M + logi(N), ambapo N ni idadi ya data katika faharasa, na M ni makadirio ya idadi ya safu mlalo ndani ya mbalimbali. Tunajua maadili ya anuwai hizi zote kwa shukrani kwa takwimu. Uchanganuzi wa masafa husoma sehemu tu ya faharasa, kwa hivyo utendakazi unagharimu chini ya tambazo kamili.

• Changanua kwa thamani za kipekee. Inatumika katika hali ambapo unahitaji kupata thamani moja tu kutoka kwa faharisi.
• Ufikiaji kwa Kitambulisho cha safu mlalo. Ikiwa hifadhidata inatumia faharasa, basi mara nyingi itakuwa ikitafuta safu mlalo zinazohusiana nayo. Kwa mfano, tunatoa ombi lifuatalo:

  CHAGUA LASTNAME, FIRSTNAME kutoka kwa PERSON WHERE AGE = 28
  Iwapo tuna faharasa kwenye safu wima ya umri, kiboreshaji kitatumia faharasa kupata watoto wote wenye umri wa miaka 28 na kisha kuuliza vitambulisho vya safu mlalo zinazolingana kwenye jedwali, kwa kuwa faharasa ina maelezo ya umri pekee.

  Wacha tuseme tuna ombi lingine:

  CHAGUA TYPE_PERSON.CATEGORY kutoka kwa PERSON, TYPE_PERSON WAPI PERSON.AGE = TYPE_PERSON.AGE
  Ili kuunganishwa na TYPE_PERSON, faharasa kwenye safu wima ya PERSON itatumika. Lakini kwa kuwa hatukuomba maelezo kutoka kwa jedwali la PERSON, hakuna mtu atakayeyafikia kwa Vitambulisho vya safu mlalo.

  Mbinu hii ni nzuri tu kwa idadi ndogo ya simu kwa sababu ni ghali kulingana na I/O. Ikiwa unahitaji kufikia kitambulisho chako mara kwa mara, ni bora kutumia skanisho kamili.

• mbinu zingine. Unaweza kusoma juu yao katika nyaraka za Oracle. Hifadhidata tofauti zinaweza kutumia majina tofauti, lakini kanuni ni sawa kila mahali.

4.4.3. Operesheni za Muungano

Kwa hivyo, tunajua jinsi ya kupata data, ni wakati wa kuichanganya. Lakini kwanza, hebu tufafanue maneno mapya: utegemezi wa ndani na utegemezi wa nje. Utegemezi unaweza kuwa:

• meza,
• index,
• matokeo ya kati ya operesheni ya awali (kwa mfano, kujiunga hapo awali).

Tunapochanganya vitegemezi viwili, algoriti za kuunganisha huzisimamia kwa njia tofauti. Wacha tuseme A JOIN B ni muungano wa A na B, ambapo A ni tegemeo la nje na B ni tegemezi la ndani.

Mara nyingi, gharama ya A JOIN B si sawa na gharama ya B JIUNGE A.

Hebu tuchukulie kuwa utegemezi wa nje una vipengele vya N na utegemezi wa ndani una M. Kama unavyokumbuka, kiboreshaji kinajua maadili haya kutokana na takwimu. N na M ni nambari za utegemezi wa kardinali.

• Muungano kwa kutumia vitanzi vilivyowekwa kiota. Hii ndiyo njia rahisi zaidi ya kuchanganya.

  

  Inafanya kazi kama hii: kwa kila mfuatano wa utegemezi wa nje, ulinganifu hupatikana katika mifuatano yote ya utegemezi wa ndani.

  Mfano wa pseudocode:

  Nested_loop_join(safu ya nje, safu ya ndani) kwa kila safu mlalo a kwa nje kwa kila safu mlalo b ndani ikiwa (match_join_condition(a,b)) write_result_in_output(a,b) itaisha ikiwa mwisho kwa mwisho kwa
  Kwa kuwa hii ni marudio mara mbili, ugumu wa wakati unafafanuliwa kama O(N*M).

  Kwa kila safu ya N ya utegemezi wa nje, unahitaji kuhesabu M safu tegemezi za nje. Hiyo ni, algorithm hii inahitaji N + N*M inasoma kutoka kwa diski. Ikiwa utegemezi wa ndani ni mdogo wa kutosha, basi unaweza kuiweka kabisa kwenye kumbukumbu, na kisha mfumo mdogo wa disk utakuwa na M + N tu kusoma. Kwa hivyo inashauriwa kufanya utegemezi wa ndani kuwa kompakt iwezekanavyo ili kutoshea kwenye kumbukumbu.

  Kutoka kwa mtazamo wa ugumu wa wakati, hakuna tofauti.

  Unaweza pia kubadilisha utegemezi wa ndani na faharisi, hii itaokoa shughuli za I/O.
  Ikiwa utegemezi wa ndani hauingii kabisa kwenye kumbukumbu, unaweza kutumia algorithm nyingine inayotumia diski zaidi kiuchumi.

  • Badala ya kusoma utegemezi wote mstari kwa mstari, husomwa kwa vikundi vya mistari (rundo), na kundi moja kutoka kwa kila utegemezi likihifadhiwa kwenye kumbukumbu.
  • Kamba kutoka kwa vikundi hivi hulinganishwa na kila mmoja, na mechi zilizopatikana zimehifadhiwa tofauti.
  • Kisha vikundi vipya vinapakiwa kwenye kumbukumbu na pia ikilinganishwa na kila mmoja.
  Na kadhalika mpaka vikundi viishie.

  Mfano wa algorithm:

  // toleo lililoboreshwa ili kupunguza diski I/O. nested_loop_join_v2(faili ya nje, ya ndani ya faili) kwa kila kundi ba kwa nje // ba sasa iko kwenye kumbukumbu kwa kila kundi bb ndani // bb sasa iko kwenye kumbukumbu kwa kila safu a in ba kwa kila safu b katika bb ikiwa (match_join_condition( a,b)) andika_result_in_output(a,b) mwisho ikiwa mwisho kwa mwisho kwa mwisho kwa mwisho kwa
  Katika kesi hii, ugumu wa wakati unabaki sawa, lakini idadi ya ufikiaji wa diski imepunguzwa: (idadi ya vikundi vya nje + idadi ya vikundi vya nje * idadi ya vikundi vya ndani). Kadiri ukubwa wa kikundi unavyoongezeka, idadi ya ufikiaji wa diski hupungua hata zaidi.

  Kumbuka: katika algorithm hii, data zaidi inasomwa na kila ufikiaji, lakini hii haijalishi kwani ufikiaji ni mlolongo.

• Hash kujiunga. Hii ni operesheni ngumu zaidi, lakini katika hali nyingi gharama yake ni ya chini.

  

  Algorithm ni kama ifuatavyo:

  1. Vipengele vyote kutoka kwa utegemezi wa ndani vinasomwa.
  2. Jedwali la hashi limeundwa kwenye kumbukumbu.
  3. Vipengele vyote kutoka kwa utegemezi wa nje vinasomwa moja baada ya nyingine.
  4. Kwa kila kipengele, heshi huhesabiwa (kwa kutumia kazi inayolingana kutoka kwa jedwali la hashi) ili kizuizi kinacholingana katika utegemezi wa ndani kinaweza kupatikana.
  5. Vipengele kutoka kwa block vinalinganishwa na vipengele kutoka kwa utegemezi wa nje.
  Ili kutathmini algorithm hii kwa suala la ugumu wa wakati, mawazo kadhaa yanahitajika kufanywa:
  • Utegemezi wa ndani una vizuizi vya X.
  • Chaguo za kukokotoa za heshi husambaza heshi karibu sawa kwa tegemezi zote mbili. Hiyo ni, vitalu vyote vina ukubwa sawa.
  • Gharama ya kupata mechi kati ya vitu vya utegemezi wa nje na vitu vyote ndani ya block ni sawa na idadi ya vitu ndani ya block.
  Kisha ugumu wa wakati utakuwa sawa na:

  (M / X) * (N / X) + hash_table_creation_cost(M) + hash_function_cost * N

  Na ikiwa kazi ya hashi inaunda vizuizi vidogo vya kutosha, basi ugumu wa wakati utakuwa O (M + N).

  Kuna njia nyingine ya kujiunga na hashi ambayo ni nzuri zaidi ya kumbukumbu na haihitaji shughuli zaidi za I/O:

  1. Jedwali la hashi huhesabiwa kwa tegemezi zote mbili.
  2. Imewekwa kwenye diski.
  3. Na kisha hulinganishwa hatua kwa hatua na kila mmoja (block moja imefungwa kwenye kumbukumbu, na ya pili inasomwa mstari kwa mstari).
  Muungano kwa kuunganishwa. Hii ndiyo njia pekee ya kuunganisha ambayo husababisha data iliyopangwa. Katika nakala hii, tunazingatia kesi iliyorahisishwa wakati utegemezi haujagawanywa kuwa wa nje na wa ndani, kwani wanafanya sawa. Walakini, katika maisha halisi wanaweza kutofautiana, sema, wakati wa kufanya kazi na nakala.

  Operesheni ya kuunganisha inaweza kugawanywa katika hatua mbili:

  1. (Kwa hiari) ujumuishaji wa kupanga hufanywa kwanza, ambapo seti zote mbili za data ya ingizo hupangwa kwa vitufe vya kuunganisha.
  2. Kisha kuunganishwa hufanyika.
  Inapanga

  Algorithm ya aina ya kuunganisha tayari imejadiliwa hapo juu; katika kesi hii, ni sawa ikiwa kuhifadhi kumbukumbu ni muhimu kwako.

  Lakini hutokea kwamba seti za data zinafika tayari zimepangwa, kwa mfano:

  • Ikiwa meza imepangwa asili.
  • Ikiwa utegemezi ni faharisi iliyo na sharti la kujiunga lipo.
  • Ikiwa muungano unatokea na matokeo yaliyopangwa ya kati.
  Kuunganisha kwa kuunganisha

  

  Operesheni hii inafanana sana na operesheni ya kuunganisha katika upangaji wa kuunganisha. Lakini badala ya kuchagua vipengele vyote vya tegemezi zote mbili, tunachagua vipengele sawa tu.

  1. Vipengele viwili vya sasa vya tegemezi zote mbili vinalinganishwa.
  2. Ikiwa ni sawa, basi huingizwa kwenye jedwali linalosababisha, na kisha vipengele viwili vinavyofuata vinalinganishwa, moja kutoka kwa kila utegemezi.
  3. Ikiwa si sawa, basi kulinganisha kunarudiwa, lakini badala ya ndogo ya vipengele viwili, kipengele kinachofuata kutoka kwa utegemezi sawa kinachukuliwa, kwani uwezekano wa bahati mbaya katika kesi hii ni ya juu.
  4. Hatua ya 1-3 inarudiwa hadi vipengele vya mojawapo ya utegemezi viishe.
  Ikiwa tegemezi zote mbili tayari zimepangwa, basi ugumu wa wakati ni O (N + M).

  Ikiwa vitegemezi vyote viwili bado vinahitaji kupangwa, basi utata wa wakati ni O(N * Log(N) + M * Log(M)).

  Kanuni hii inafanya kazi vizuri kwa sababu tegemezi zote mbili tayari zimepangwa na si lazima kurudi na kurudi kati yao. Hata hivyo, kuna baadhi ya kurahisisha hapa: algorithm haina kushughulikia hali ambapo data sawa hutokea mara nyingi, yaani, wakati mechi nyingi hutokea. Kwa kweli, toleo ngumu zaidi la algorithm hutumiwa. Kwa mfano:

  MergeJoin(uhusiano a, uhusiano b) jumla ya matokeo ya uhusiano a_key:=0; ufunguo kamili wa b_:=0; wakati (a!=null na b!=null) ikiwa (a< b) a_key++; else if (a >b) b_ufunguo++; lingine //Jiunge na kihusishi cha kuridhika write_result_in_output(a,b) //Tunahitaji kuwa makini tunapoongeza nambari kamili ya viashiria a_key_temp:=a_key; integer b_key_temp:=b_key; ikiwa (a != b) b_key_temp:= b_key + 1; mwisho ikiwa (b != a) a_key_temp:= a_key + 1; mwisho ikiwa (b == a && b == a) a_key_temp:= a_key + 1; b_key_temp:= b_key + 1; mwisho kama ufunguo:= a_key_temp; b_key:= b_key_temp; mwisho kama mwisho wakati

Ni algorithm gani ya kuchagua?

Ikiwa kulikuwa na njia bora ya kuchanganya, basi aina hizi zote hazitakuwapo. Kwa hivyo jibu la swali hili inategemea rundo la mambo:

• Kiasi cha kumbukumbu inayopatikana. Ikiwa haitoshi, sahau kuhusu kiungo chenye nguvu cha heshi. Angalau, utekelezaji wake uko kwenye kumbukumbu kabisa.
• Ukubwa wa seti mbili za data ya ingizo. Ikiwa una jedwali moja ambalo ni kubwa na lingine ndogo sana, basi unganisho kwa kutumia vitanzi vilivyowekwa kiota utafanya kazi haraka sana, kwa sababu uunganisho wa hashi unahusisha utaratibu wa gharama kubwa wa kuunda heshi. Ikiwa una jedwali mbili kubwa sana, kisha kujiunga kwa kutumia vitanzi vilivyowekwa kiota kutatumia rasilimali zote za CPU.
• Upatikanaji wa fahirisi. Ikiwa una faharisi mbili za miti ya B, ni bora kutumia kiunga cha kuunganisha.
• Je, ninahitaji kupanga matokeo? Unaweza kutaka kutumia uunganisho wa gharama kubwa (na aina) ikiwa unafanya kazi na seti za data ambazo hazijapangwa. Kisha kwenye pato utapokea data iliyopangwa, ambayo ni rahisi zaidi kuchanganya na matokeo ya umoja mwingine. Au kwa sababu swali linatarajia kupokea data iliyopangwa kwa njia ya ORDER BY/GROUP BY/DISTINCT.
• Je, utegemezi wa pato umepangwa?. Katika kesi hii, ni bora kutumia unganisho la kuunganisha.
• Je, unatumia aina gani za utegemezi?. Je, ungependa kujiunga kwa usawa (mezaA.column1 = jedwaliB.column2)? Mategemeo ya ndani, tegemezi za nje, bidhaa ya Cartesian au ujiunge mwenyewe? Katika hali tofauti, njia zingine za kuunganisha hazifanyi kazi.
• Usambazaji wa data. Ikiwa data imekataliwa na sharti la kujiunga (kwa mfano, unajiunga na watu kwa jina la mwisho, lakini mara nyingi kuna majina ya majina), basi uunganisho wa hashi haupaswi kutumiwa kamwe. Vinginevyo kazi ya heshi itaunda ndoo zilizo na usambazaji duni wa ndani.
• Inahitajika kuunganishwa katika michakato / nyuzi nyingi?

Wale walio na njaa ya maarifa wanaweza kuzama katika hati za DB2, ORACLE na Seva ya SQL.

4.4.4. Mifano iliyorahisishwa

Wacha tuseme tunahitaji kuungana na meza tano ili kupata picha kamili ya watu fulani. Kila mtu anaweza kuwa na:

• Nambari kadhaa za simu za rununu.
• Barua pepe nyingi.
• Anwani nyingi za mahali.
• Nambari kadhaa za akaunti ya benki.

Hiyo ni, unahitaji kujibu ombi hili haraka:

CHAGUA * kutoka kwa MTU, SIMU, BARUA, AANWANI, AKAUNTI_ZA_BENK AMBAPO MTU.PERSON_ID = SIMU.KITAMBULISHO CHA_MTU NA MTU.MTU_ID = BARUA.KITAMBULISHO_MTU NA MTU.PERSON_ID = ANWANI.KITAMBULISHO_MTU NA MTU.PERSON_ID = BANK_ACCOUNTS.PERSON_ID
Kiboreshaji kinahitaji kutafuta njia bora ya kuchakata data. Lakini kuna shida mbili:

1. Nitumie njia gani ya kuunganisha? Kuna chaguzi tatu (uunganisho wa heshi, unganisha unganisho, uunganisho wa kitanzi kilichowekwa), na chaguo la kutumia faharasa 0, 1 au 2. Bila kutaja kwamba faharisi pia inaweza kuwa tofauti.
2. Uunganisho unapaswa kufanywa kwa utaratibu gani?

Kwa mfano, hapa chini kuna mipango inayowezekana ya viungio vitatu vya jedwali nne:

Kulingana na kile ambacho kimeelezewa, chaguzi zako ni zipi?

1. Tumia mbinu ya nguvu ya kikatili. Kwa kutumia takwimu, hesabu gharama ya kila moja ya mipango inayowezekana ya utekelezaji wa hoja na uchague ya bei nafuu zaidi. Lakini kuna chaguzi nyingi kabisa. Kwa kila agizo la kujiunga, mbinu tatu tofauti za kujiunga zinaweza kutumika, kwa jumla ya 34=81 mipango inayowezekana ya utekelezaji. Katika kesi ya mti wa binary, tatizo la kuchagua utaratibu wa kujiunga inakuwa tatizo la permutation, na idadi ya chaguzi ni (2 * 4)! / (4 + 1)!.. Matokeo yake, katika mfano huu uliorahisishwa sana, jumla ya mipango inayowezekana ya utekelezaji wa hoja ni 34 * (2 * 4)! / (4 + 1)! = 27,216. Ikiwa tutaongeza kwa hili chaguo ambapo uunganisho wa kuunganisha hutumia faharasa 0, 1, au 2 za miti B, idadi ya mipango inayowezekana itaongezeka hadi 210,000. Je, tulitaja kwamba hili ni swali RAHISI SANA?
2. Lia na uache. Inajaribu sana, lakini haizai, na unahitaji pesa.
3. Jaribu mipango kadhaa na uchague moja ya bei nafuu. Kwa kuwa haiwezekani kuhesabu gharama ya chaguo zote zinazowezekana, unaweza kuchukua data ya mtihani wa kiholela na kuendesha aina zote za mipango juu yake ili kukadiria gharama zao na kuchagua bora zaidi.
4. Tumia sheria mahiri ili kupunguza idadi ya mipango inayowezekana.
   Kuna aina mbili za sheria:
   1. Ndio "mantiki", kwa msaada ambao unaweza kuondoa chaguzi zisizo na maana. Lakini hazitumiki kila wakati. Kwa mfano, "Unapojiunga kwa kutumia vitanzi vilivyowekwa, utegemezi wa ndani lazima uwe seti ndogo zaidi ya data."
   2. Sio lazima kutafuta suluhisho la faida zaidi na kutumia sheria kali zaidi ili kupunguza idadi ya mipango inayowezekana. Sema, "ikiwa utegemezi ni mdogo, tumia viungio vya kitanzi vilivyowekwa kwenye viota, lakini usiwahi kuunganisha jiunge au uunganisho wa haraka."

Hata mfano rahisi kama huo unatuacha na chaguo kubwa. Na katika maswali halisi kunaweza kuwa na waendeshaji wengine wa uhusiano: OUTER JOIN, CROSS JOIN, GROUP BY, ORDER BY, PROJECTION, UNION, INTERSECT, DISTINCT, nk. Hiyo ni, idadi ya mipango inayowezekana ya utekelezaji itakuwa kubwa zaidi.

Kwa hivyo hifadhidata hufanyaje chaguo?

4.4.5. Utayarishaji wa nguvu, algorithm ya uchoyo na heuristics

Hifadhidata ya uhusiano hutumia njia tofauti, ambazo zilitajwa hapo juu. Na kazi ya kiboreshaji ni kupata suluhisho linalofaa ndani ya muda mfupi. Katika hali nyingi, optimizer haitafuti suluhisho bora, lakini suluhisho nzuri tu.

Nguvu isiyo na nguvu inaweza kufaa kwa maombi madogo. Na kwa njia za kuondoa hesabu isiyo ya lazima, hata maswali ya ukubwa wa wastani yanaweza kutumia nguvu ya kikatili. Hii inaitwa programu ya nguvu.

Kiini chake ni kwamba mipango mingi ya utekelezaji inafanana sana.

Katika kielelezo hiki, mipango yote minne hutumia mti mdogo A JOIN B. Badala ya kukokotoa gharama yake kwa kila mpango, tunaweza kuikokotoa mara moja tu kisha tuitumie data hiyo kwa muda unaohitajika. Kwa maneno mengine, kwa kutumia kukariri tunatatua tatizo la kuingiliana, yaani, tunaepuka mahesabu yasiyo ya lazima.

Shukrani kwa mbinu hii, badala ya utata wa wakati (2*N)!/(N+1)! tunapata "tu" 3 N. Katika mfano uliopita na viungo vinne, hii ina maana kupunguza idadi ya kesi kutoka 336 hadi 81. Ikiwa tunachukua swala na viungo 8 (swali ndogo), basi kupunguza utata itakuwa kutoka 57,657,600 hadi 6,561.

Iwapo tayari unajua upangaji programu au algorithmization yenye nguvu, unaweza kucheza karibu na kanuni hii:

Utaratibu findbestplan(S) kama (bestplan[S].cost infinite) rudisha bestplan[S] // else bestplan[S] haijakokotwa mapema, ikokoteni sasa ikiwa (S ina uhusiano 1 pekee) kuweka mpango bora[S]. plan and bestplan[S].cost kulingana na njia bora zaidi ya kufikia S /* Kwa kutumia chaguo kwenye S na fahirisi kwenye S */ else kwa kila kitengo kidogo kisicho na tupu S1 cha S ili S1 != S P1= findbestplan(S1) P2= findbestplan(S - S1) A = algoriti bora ya kujiunga na matokeo ya P1 na P2 gharama = P1.cost + P2.cost + gharama ya A ikiwa ni gharama< bestplan[S].cost bestplan[S].cost = cost bestplan[S].plan = “execute P1.plan; execute P2.plan; join results of P1 and P2 using A” return bestplan[S]
Programu yenye nguvu inaweza kutumika kwa maswali makubwa, lakini sheria za ziada (heuristics) zitalazimika kuletwa ili kupunguza idadi ya mipango inayowezekana:


Algorithms za Uchoyo

Lakini ikiwa ombi ni kubwa sana, au ikiwa tunahitaji kupata jibu haraka sana, darasa lingine la algoriti hutumiwa - algoriti za uchoyo.

Katika kesi hii, mpango wa utekelezaji wa swala hujengwa hatua kwa hatua kwa kutumia sheria fulani (heuristics). Shukrani kwa hilo, algorithm ya uchoyo hutafuta suluhisho bora kwa kila hatua tofauti. Mpango huanza na taarifa ya JIUNGE na kisha katika kila hatua JIUNGE mpya huongezwa kwa mujibu wa kanuni.

Hebu tuangalie mfano rahisi. Wacha tuchukue swali na viungio 4 vya jedwali 5 (A, B, C, D na E). Wacha turahisishe shida kwa kiasi fulani na tufikirie kuwa chaguo pekee ni kuchanganya kwa kutumia algorithms zilizowekwa. Tutatumia sheria "tumia unganisho kwa gharama ndogo zaidi."

• Tunaanza na moja ya meza, kwa mfano, A.
• Tunahesabu gharama ya kila muungano na A (itakuwa tegemezi la nje na la ndani).
• Tunaona kuwa A JOIN B itatugharimu kwa gharama nafuu zaidi.
• Kisha tunahesabu gharama ya kila kujiunga na matokeo A JOIN B (pia tunazingatia katika majukumu mawili).
• Tunaona kuwa chaguo lenye faida zaidi litakuwa (A JOIN B) JIUNGE NA C.
• Tena tunatathmini chaguzi zinazowezekana.
• Mwishoni tunapata mpango wa utekelezaji wa hoja ufuatao: (((A JOIN B) JIUNGE C) JIUNGE D) JIUNGE NA E)/

Algorithm sawa inaweza kutumika kutathmini chaguzi kuanzia na jedwali B, kisha C, nk. Matokeo yake, tunapata mipango mitano, ambayo tunachagua gharama nafuu zaidi.

Algorithm hii inaitwa "algorithm ya jirani ya karibu".

Hatutaingia katika maelezo, lakini kwa uundaji mzuri wa utata wa kupanga N*logi(N), tatizo hili linaweza kutatuliwa. Utata wa saa wa algoriti ni O(N*logi(N)) badala ya O(3 N) kwa toleo kamili lenye upangaji programu unaobadilika. Ikiwa una hoja kubwa yenye viungio 20, basi hiyo itakuwa 26 dhidi ya 3,486,784,401. Tofauti kubwa, sivyo?

Lakini kuna nuance. Tunadhani kwamba ikiwa tunapata njia bora ya kuunganisha meza mbili, tutapata gharama ya chini wakati wa kuunganisha matokeo ya viungo vya awali na meza zifuatazo. Hata hivyo, hata kama A JOIN B ndilo chaguo nafuu zaidi, basi (A JOIN C) JIUNGE B inaweza kuwa na gharama ya chini kuliko (A JOIN B) JIUNGE NA C.

Kwa hivyo ikiwa unahitaji sana kupata mpango wa bei nafuu zaidi wa wakati wote, basi tunaweza kukushauri kurudia kurudia algorithms ya uchoyo kwa kutumia sheria tofauti.

Algorithms zingine

Ikiwa tayari umechoshwa na kanuni hizi zote, unaweza kuruka sura hii. Si lazima bwana wengine wa nyenzo.

Watafiti wengi wanashughulikia shida ya kupata mpango bora wa utekelezaji wa hoja. Mara nyingi hujaribu kutafuta ufumbuzi wa matatizo na mifumo maalum. Kwa mfano, kwa viungo vya nyota, utekelezaji wa hoja sambamba, nk.

Chaguzi zinatafutwa kuchukua nafasi ya upangaji programu kwa ajili ya kutekeleza hoja kubwa. Algorithms zile zile za uchoyo ni sehemu ndogo ya algoriti za kiheuristic. Wanatenda kulingana na sheria, kumbuka matokeo ya hatua moja na kuitumia kupata chaguo bora kwa hatua inayofuata. Na algorithms ambazo hazitumii kila wakati suluhisho lililopatikana kwa hatua ya awali huitwa heuristic.

Mfano ni algorithms ya maumbile:

• Kila suluhu inawakilisha mpango wa utekelezaji kamili wa ombi.
• Badala ya suluhisho moja (mpango), algorithm hutoa suluhisho X katika kila hatua.
• Kwanza, mipango ya X imeundwa, hii inafanywa kwa nasibu.
• Kati ya hizi, ni mipango tu ambayo thamani yake inakidhi kigezo fulani huhifadhiwa.
• Mipango hii basi huchanganywa ili kuunda mipango mipya ya X.
• Baadhi ya mipango mipya hurekebishwa bila mpangilio.
• Hatua tatu zilizopita zinarudiwa mara Y.
• Kutoka kwa mipango ya mzunguko wa mwisho tunapata bora zaidi.

Mzunguko zaidi, mpango wa bei nafuu unaweza kuhesabiwa. Uchaguzi wa asili, uimarishaji wa sifa, ndiyo yote.
Kwa njia, algorithms ya maumbile imeunganishwa kwenye PostgreSQL.

Hifadhidata hiyo pia hutumia algoriti za kiheuristic kama vile Uingizaji wa Kuiga, Uboreshaji wa Mara kwa mara, na Uboreshaji wa Awamu Mbili. Lakini sio ukweli kwamba hutumiwa katika mifumo ya ushirika; labda hatima yao ni bidhaa za utafiti.

4.4.6. Viboreshaji halisi

Pia sura ya hiari, unaweza kuiruka.

Wacha tuachane na nadharia na tuangalie mifano halisi. Kwa mfano, jinsi optimizer ya SQLite inavyofanya kazi. Hii ni hifadhidata "nyepesi" ambayo hutumia uboreshaji rahisi kulingana na algorithm ya uchoyo na sheria za ziada:

• SQLite haibadilishi mpangilio wa jedwali katika operesheni ya CROSS JOIN.
• Muungano kwa kutumia vitanzi vilivyowekwa kiota hutumiwa.
• Viungio vya nje kila wakati hutathminiwa kwa mpangilio ambao ulifanyika.
• Hadi toleo la 3.8.0, algoriti ya uchoyo ya Jirani wa Karibu zaidi inatumiwa kupata mpango bora zaidi wa utekelezaji wa hoja. Na kwa kuwa toleo la 3.8.0, "N majirani wa karibu" (N3, N karibu na Majirani) hutumiwa.

Hapa kuna mfano mwingine. Ikiwa tutasoma hati za IBM DB2, tunajifunza kuwa kiboreshaji chake hutumia viwango 7 tofauti vya uboreshaji:

• Algorithms ya uchoyo:
  • 0 - uboreshaji mdogo. Hutumia uchanganuzi wa faharasa, viunganishi vya kitanzi vilivyoorodheshwa, na huepuka kuandika upya baadhi ya hoja.
  • 1 - uboreshaji mdogo
  • 2 - optimization kamili
• Utayarishaji wa Nguvu:
  • 3 - uboreshaji wa kati na makadirio mabaya
  • 5 - optimization kamili, mbinu zote za heuristic hutumiwa
  • 7 - kitu kimoja, lakini bila heuristics
  • 9 - uboreshaji wa juu kwa gharama yoyote, bila kuzingatia jitihada zilizotumiwa. Njia zote zinazowezekana za kuchanganya zinatathminiwa, ikiwa ni pamoja na bidhaa za Cartesian.

Kiwango chaguo-msingi ni 5. Hii inajumuisha:

• Mkusanyiko wa takwimu zote zinazowezekana, ikiwa ni pamoja na usambazaji wa mara kwa mara na quantiles.
• Kutumia sheria zote za kuandika upya hoja, ikiwa ni pamoja na kuunda njia ya jedwali kwa hoja zilizojiri). Isipokuwa ni sheria zinazohitaji mahesabu ya kina na hutumiwa kwa idadi ndogo sana ya kesi.
• Unaporudia kupitia chaguo za kujiunga kwa kutumia programu inayobadilika:
  • Kuna matumizi machache ya utegemezi wa ndani wa kiwanja.
  • Kwa mizunguko ya nyota na meza za kuangalia, bidhaa za Cartesian hutumiwa kwa kiwango kidogo.
• Mbinu mbalimbali za ufikiaji zimeshughulikiwa, ikiwa ni pamoja na uletaji orodha mapema (zaidi kuhusu hili hapa chini), ANDing maalum ya faharasa, na uelekezaji wa jedwali kwa hoja halisi.

Bila shaka, watengenezaji hawashiriki maelezo kuhusu heuristics kutumika katika bidhaa zao, kwa sababu optimizer labda ni sehemu muhimu zaidi ya hifadhidata. Hata hivyo, inajulikana kuwa kwa default, programu ya nguvu, iliyopunguzwa na heuristics, hutumiwa kuamua utaratibu wa kujiunga.

Masharti mengine (GROUP BY, DISTINCT, nk.) yanachakatwa na sheria rahisi.

4.4.7. Akiba ya mpango wa hoja

Kwa sababu kuunda mpango huchukua muda, hifadhidata nyingi huhifadhi mpango katika kashe ya mpango wa hoja. Hii husaidia kuzuia mahesabu yasiyo ya lazima ya hatua sawa. Hifadhidata inahitaji kujua wakati hasa inahitaji kusasisha mipango iliyopitwa na wakati. Kwa hili, kizingiti fulani kinawekwa, na ikiwa mabadiliko katika takwimu yanazidi, basi mpango unaohusiana na meza hii huondolewa kwenye cache.

Ombi la Mtekelezaji

Katika hatua hii, mpango wetu tayari umeboreshwa. Inajumuishwa tena kuwa nambari inayoweza kutekelezwa na, ikiwa kuna rasilimali za kutosha, inatekelezwa. Waendeshaji walio katika mpango (JIUNGE, PANGA KWA, n.k.) wanaweza kushughulikiwa kwa kufuatana au sambamba; uamuzi hufanywa na msimamizi. Inaingiliana na meneja wa data kupokea na kuandika data.

5. Meneja wa data

Kidhibiti cha hoja hutekeleza hoja na anahitaji data kutoka kwa majedwali na faharasa. Inawaomba kutoka kwa meneja wa data, lakini kuna shida mbili:

• Hifadhidata za uhusiano hutumia muundo wa shughuli. Haiwezekani kupata data yoyote inayotaka kwa wakati maalum kwa wakati, kwa sababu kwa wakati huu inaweza kutumika / kurekebishwa na mtu.
• Urejeshaji data ndio operesheni polepole zaidi katika hifadhidata. Kwa hivyo, meneja wa data anahitaji kuwa na uwezo wa kutabiri kazi yake ili kujaza buffer ya kumbukumbu kwa wakati unaofaa.

5.1. Meneja wa Cache

Kama ilivyosemwa zaidi ya mara moja, kizuizi kwenye hifadhidata ni mfumo mdogo wa diski. Kwa hiyo, meneja wa cache hutumiwa kuboresha utendaji.

Badala ya kupokea data moja kwa moja kutoka kwa mfumo wa faili, mendesha swali huenda kwa meneja wa kache kwa hiyo. Inatumia hifadhi ya akiba iliyo kwenye kumbukumbu, ambayo inaweza kuongeza utendaji wa hifadhidata kwa kiasi kikubwa. Ni ngumu kuweka nambari kwenye hii kwa sababu mengi inategemea kile unachohitaji:

• Ufikiaji mfuatano (skanisho kamili) au nasibu (ufikiaji kwa Kitambulisho cha safu mlalo).
• Soma au andika.

Aina ya anatoa zinazotumiwa katika mfumo wa disk pia ni muhimu sana: "anatoa ngumu" na kasi tofauti za spindle, SSD, kuwepo kwa RAID katika usanidi tofauti. Lakini tunaweza kusema kwamba matumizi ya kumbukumbu ni mara 100-100,000 kwa kasi zaidi kuliko matumizi ya disk.

Walakini, hapa tunakabiliwa na shida nyingine. Kidhibiti cha kache kinahitaji kuweka data kwenye kumbukumbu KABLA ya mtekelezaji wa hoja kuhitaji. Vinginevyo, atalazimika kuwangojea kupokelewa kutoka kwa diski polepole.

5.1.1. Kujikinga

Mtekelezaji wa hoja anajua data itahitaji kwa sababu anajua mpango mzima, ni data gani iliyo kwenye diski, na takwimu.

Wakati mtekelezaji anachakata kipande cha kwanza cha data, huuliza msimamizi wa kache kupakia mapema kipande kinachofuata. Na inapoanza kusindika, inauliza DC kupakia ya tatu na inathibitisha kwamba sehemu ya kwanza inaweza kufutwa kutoka kwa cache.

Kidhibiti cha akiba huhifadhi data hii kwenye hifadhi ya akiba. Pia huongeza maelezo ya huduma (kichochezi, latch) kwao ili kujua ikiwa bado zinahitajika kwenye bafa.

Wakati mwingine mwigizaji hajui ni data gani atahitaji, au hifadhidata zingine hazina utendakazi kama huo. Kisha uletaji mapema wa kubahatisha hutumiwa (kwa mfano, ikiwa mtekelezaji ataomba data 1, 3, 5, basi labda ataomba 7, 9, 11 katika siku zijazo) au uletaji mfuatano (katika kesi hii, DC inapakia tu inayofuata kutoka. diski ili kipande cha data.

Hatupaswi kusahau kwamba buffer imepunguzwa na kiasi cha kumbukumbu inayopatikana. Hiyo ni, ili kupakia baadhi ya data tunapaswa kufuta nyingine mara kwa mara. Kujaza na kufuta cache hutumia sehemu ya mfumo mdogo wa disk na rasilimali za mtandao. Ikiwa una hoja inayoendeshwa mara kwa mara, haitakuwa na manufaa kupakia na kusafisha data inayotumia kila wakati. Ili kutatua tatizo hili, hifadhidata za kisasa hutumia mkakati wa kubadilisha bafa.

5.1.2. Mikakati ya kubadilisha bafa

Hifadhidata nyingi (angalau Seva ya SQL, MySQL, Oracle na DB2) hutumia algoriti ya LRU (Inayotumika Hivi Karibuni zaidi) kwa hili. Imeundwa ili kudumisha data katika kache ambayo imetumika hivi karibuni, ambayo ina maana kuna uwezekano mkubwa kwamba inaweza kuhitajika tena.

Ili iwe rahisi kuelewa jinsi algorithm inavyofanya kazi, tutafikiri kwamba data katika buffer haijazuiwa na vichochezi (latch), na kwa hiyo inaweza kufutwa. Katika mfano wetu, bafa inaweza kuhifadhi vipande vitatu vya data:

1. Kidhibiti cha kache hutumia data 1 na kuiweka kwenye bafa tupu.
2. Kisha hutumia data 4 na kuituma kwa bafa pia.
3. Vile vile hufanywa na data 3.
4. Ifuatayo, data 9 inachukuliwa. Lakini buffer tayari imejaa. Kwa hivyo, data 1 huondolewa kutoka kwake kwa kuwa haijatumika kwa muda mrefu zaidi. Baada ya hayo, data 9 imewekwa kwenye bafa.
5. Kidhibiti cha kache hutumia data 4 tena. Tayari iko kwenye bafa, kwa hivyo imetiwa alama kama ilitumika mwisho.
6. Data 1 inahitajika tena. Ili kuiweka kwenye bafa, data ya 3 inafutwa kutoka humo kwa kuwa haijatumika kwa muda mrefu zaidi.

Hii ni algorithm nzuri, lakini ina mapungufu. Je, ikiwa tunachanganua kabisa meza kubwa? Nini kitatokea ikiwa jedwali/saizi ya faharasa inazidi saizi ya bafa? Katika kesi hii, algorithm itaondoa yaliyomo yake yote kutoka kwa kache, kwa hivyo data kamili ya skanisho itawezekana kutumika mara moja tu.

Maboresho ya algorithm

Ili kuzuia hili kutokea, baadhi ya hifadhidata hutumia sheria maalum. Kulingana na nyaraka za Oracle:

"Kwa majedwali makubwa sana, ufikiaji wa moja kwa moja hutumiwa, ikimaanisha kuwa vizuizi vya data vinasomwa moja kwa moja ili kuzuia kufurika kwa kache. Kwa meza za ukubwa wa kati, ufikiaji wa moja kwa moja na usomaji wa cache unaweza kutumika. Ikiwa mfumo utaamua kutumia kache, hifadhidata huweka vizuizi vya data mwishoni mwa orodha ya LRU ili kuzuia umwagikaji wa bafa."

Toleo lililoboreshwa la LRU, LRU-K, pia linatumika. Seva ya SQL hutumia LRU-K na K = 2. Kiini cha algorithm hii ni kwamba wakati wa kutathmini hali hiyo, inachukua maelezo zaidi kuhusu shughuli za zamani, na sio tu kukumbuka data iliyotumiwa mwisho. Herufi K katika jina inamaanisha kuwa algoriti inazingatia ni data gani ilitumika mara K za mwisho. Wanapewa uzito fulani. Data mpya inapopakiwa kwenye akiba, data ya zamani lakini inayotumiwa mara kwa mara haifutwa kwa sababu uzito wake ni mkubwa zaidi. Bila shaka, ikiwa data haitatumika tena, bado itafutwa. Na kadiri data inavyobaki bila kudaiwa, ndivyo uzito wake unavyopungua kwa muda.

Kuhesabu uzito ni ghali kabisa, kwa hivyo Seva ya SQL hutumia LRU-K na K sawa na 2 tu. Thamani ya K inapoongezeka kidogo, ufanisi wa algorithm inaboresha. Unaweza kumfahamu vyema zaidi kutokana na.

Algorithms zingine

Kwa kweli, LRU-K sio suluhisho pekee. Pia kuna 2Q na CLOCK (zote zinafanana na LRU-K), MRU (Iliyotumika Hivi Karibuni zaidi, ambayo hutumia mantiki ya LRU lakini inatumika sheria tofauti, LRFU (Inayotumika Hivi Karibuni na Inayotumika Mara kwa Mara), nk. Katika hifadhidata zingine unaweza kuchagua, nini algorithm itatumika.

5.1.3. Andika bafa

Tulizungumza tu juu ya bafa ya kusoma, lakini hifadhidata pia hutumia vihifadhi vya uandishi, ambavyo hujilimbikiza data na kuifuta kwa diski kwa sehemu, badala ya uandishi wa mfululizo. Hii huokoa shughuli za I/O.
Kumbuka kwamba hifadhi ya bafa kurasa(vitengo visivyoweza kugawanywa vya data), badala ya safu mlalo kutoka kwa jedwali. Ukurasa katika bwawa la bafa unasemekana kuwa chafu ikiwa utarekebishwa lakini haujaandikwa kwa diski. Kuna algoriti nyingi tofauti ambazo hutumiwa kuchagua wakati wa kuandika wa kurasa chafu. Lakini ina mengi ya kufanya na dhana ya shughuli.

5.2. Meneja wa Shughuli

Wajibu wake ni kuhakikisha kwamba kila ombi linatekelezwa kwa kutumia muamala wake. Lakini kabla ya kuzungumza juu ya dispatcher, hebu tufafanue dhana ya shughuli za ACID.

5.2.1. "Kwenye Asidi" (cheza kwa maneno, ikiwa mtu haelewi)

Muamala wa ACID (Atomicity, Isolation, Durability, Consistency) ni operesheni ya msingi, kitengo cha kazi ambacho kinakidhi masharti 4:

• Atomiki. Hakuna kitu "kidogo" kuliko shughuli, hakuna operesheni ndogo. Hata kama shughuli huchukua masaa 10. Ikiwa shughuli itashindwa, mfumo unarudi kwenye hali ya "kabla", yaani, shughuli hiyo inarudishwa nyuma.
• Kujitenga. Ikiwa shughuli mbili A na B zinatekelezwa kwa wakati mmoja, basi matokeo yao haipaswi kutegemea ikiwa mmoja wao alikamilika kabla, wakati, au baada ya utekelezaji wa mwingine.
• Kudumu. Wakati shughuli inafanywa, ambayo ni, imekamilika kwa mafanikio, data iliyotumiwa inabaki kwenye hifadhidata, bila kujali matukio yanayowezekana (makosa, ajali).
• Uthabiti. Data halali tu (kutoka kwa mtazamo wa uhusiano wa uhusiano na kazi) ni kumbukumbu katika database. Uthabiti hutegemea atomicity na kutengwa.

Wakati wa utekelezaji wa muamala wowote, unaweza kutekeleza hoja mbalimbali za SQL ili kusoma, kuunda, kusasisha na kufuta data. Matatizo huanza wakati shughuli mbili zinatumia data sawa. Mfano mzuri ni kuhamisha pesa kutoka akaunti A hadi akaunti B. Hebu tuseme tuna miamala miwili:

• T1 inachukua $100 kutoka kwa akaunti A na kuituma kwa akaunti B.
• T2 inachukua $50 kutoka akaunti A na pia kuzituma kwa akaunti B.

Sasa hebu tuangalie hali hii kutoka kwa mtazamo wa mali ya ACID:

• Atomiki inakuwezesha kuwa na uhakika kwamba bila kujali tukio gani hutokea wakati wa T1 (kuanguka kwa seva, kushindwa kwa mtandao), haiwezi kutokea kwamba $ 100 itatolewa kutoka kwa A, lakini haitakuja kwa B (vinginevyo wanazungumzia "hali isiyofanana").
• Kujitenga inasema kwamba hata ikiwa T1 na T2 zinafanywa wakati huo huo, kwa sababu hiyo $ 100 itatolewa kutoka kwa A na kiasi sawa kitaenda kwa B. Katika matukio mengine yote, wanazungumza tena juu ya hali ya kutofautiana.
• Kuegemea hukuruhusu usiwe na wasiwasi juu ya kutoweka kwa T1 ikiwa hifadhidata itaanguka mara baada ya kufanya T1.
• Uthabiti huzuia uwezekano wa fedha kuundwa au kuharibiwa katika mfumo.

Sio lazima kusoma hapa chini, sio muhimu tena kuelewa nyenzo zingine.

Hifadhidata nyingi hazitoi kutengwa kamili kwa chaguo-msingi, kwani hii inaweka juu ya utendaji mkubwa. SQL hutumia viwango 4 vya kutengwa:

• Shughuli zinazoweza kutekelezwa. Kiwango cha juu cha kujitenga. Chaguomsingi katika SQLite. Kila shughuli inatekelezwa katika mazingira yake, yaliyotengwa kabisa.
• Usomaji unaorudiwa. Chaguo-msingi katika MySQL. Kila shughuli ina mazingira yake, isipokuwa kwa hali moja: ikiwa ni shughuli inaongeza data mpya na ikikamilika kwa mafanikio, yataonekana kwa miamala mingine ambayo bado inaendelea. Lakini kama shughuli inarekebisha data na ikikamilika kwa mafanikio, mabadiliko haya hayataonekana kwa miamala ambayo bado inaendelea. Hiyo ni, kwa data mpya kanuni ya kutengwa inakiukwa.

  Kwa mfano, shughuli A inatekelezwa

  CHAGUA hesabu(1) kutoka TABLE_X
  Kisha shughuli B inaongeza jedwali X na kutoa data mpya. Na ikiwa baada ya shughuli hii A itafanya hesabu (1) tena, basi matokeo yatakuwa tofauti.

  Hii inaitwa kusoma phantom.

• Soma data iliyojitolea. Inatumika kwa chaguo-msingi katika Oracle, PostgreSQL na Seva ya SQL. Hii ni sawa na kusoma mara kwa mara, lakini kwa ukiukwaji wa ziada wa kujitenga. Wacha tuseme shughuli A inasoma data; basi hurekebishwa au kufutwa na shughuli B, ambayo hufanya vitendo hivi. Ikiwa A atasoma data hii tena, ataona mabadiliko (au ukweli wa kufutwa) yaliyofanywa na B.

  Hii inaitwa kusoma isiyoweza kurudiwa.

• Soma data ambayo hujajitolea. Kiwango cha chini cha kutengwa. Ukiukaji mpya wa kutengwa huongezwa kwa usomaji wa data iliyojitolea. Wacha tuseme shughuli A inasoma data; basi zinarekebishwa na shughuli B (mabadiliko hayajafanywa, B bado inatekelezwa). Ikiwa A atasoma data tena, ataona mabadiliko yaliyofanywa. Ikiwa B inarudishwa nyuma, basi ikisomwa tena, A haitaona mabadiliko yoyote, kana kwamba hakuna kilichotokea.

  Hii inaitwa kusoma chafu.

Hifadhidata nyingi huongeza viwango vyao vya kutengwa (kwa mfano, kulingana na vijipicha, kama katika PostgreSQL, Oracle na Seva ya SQL). Pia, hifadhidata nyingi hazitekelezi viwango vyote vinne vilivyoelezewa hapo juu, haswa kusoma data ambayo haijatekelezwa.

Mtumiaji au msanidi anaweza kubatilisha kiwango chaguomsingi cha kutengwa mara tu baada ya muunganisho kuanzishwa. Unachohitaji kufanya ni kuongeza laini rahisi sana ya nambari.

5.2.2. Udhibiti wa Concurrency

Jambo kuu tunalohitaji kutengwa, uthabiti na atomiki ni uwezo wa kufanya shughuli za kuandika kwenye data sawa (kuongeza, kusasisha na kufuta).

Ikiwa miamala yote itasoma data pekee, inaweza kufanya kazi kwa wakati mmoja bila kuathiri miamala mingine.
Ikiwa angalau muamala mmoja utabadilisha data iliyosomwa na miamala mingine, basi hifadhidata inahitaji kutafuta njia ya kuficha mabadiliko haya kutoka kwao. Pia unahitaji kuhakikisha kuwa mabadiliko yaliyofanywa hayatafutwa na shughuli zingine ambazo hazioni data iliyobadilishwa.

Hii inaitwa concurrency control.

Njia rahisi ni kufanya shughuli moja baada ya nyingine. Lakini njia hii kawaida haifai (msingi mmoja tu wa processor moja hutumiwa), na uwezo wa kuongeza kiwango pia hupotea.

Njia bora ya kutatua tatizo inaonekana kama hii (kila wakati shughuli inapoundwa au kughairiwa):

• Fuatilia utendakazi wote wa kila muamala.
• Ikiwa miamala miwili au zaidi inakinzana kwa sababu ya kusoma/kubadilisha data sawa, basi badilisha mpangilio wa shughuli ndani ya wahusika kwenye mzozo ili kupunguza idadi ya sababu.
• Tekeleza sehemu zinazokinzana za miamala kwa mpangilio maalum. Shughuli zisizo na migogoro zinatekelezwa kwa wakati huu.
• Tafadhali fahamu kuwa miamala inaweza kughairiwa.

Ikiwa tunashughulikia suala hilo rasmi zaidi, basi hili ni tatizo la kupanga migogoro. Kutatua ni ngumu sana, na uboreshaji unahitaji rasilimali kubwa za processor. Hifadhidata za biashara haziwezi kumudu kutumia saa nyingi kutafuta ratiba bora kwa kila shughuli mpya. Kwa hiyo, mbinu za chini za kisasa hutumiwa, ambazo muda mwingi hutumiwa kwenye migogoro.

5.2.3. Kidhibiti cha kufuli

Ili kutatua tatizo lililoelezwa hapo juu, hifadhidata nyingi hutumia kufuli na/au utayarishaji wa data.
Ikiwa muamala unahitaji data fulani, huizuia. Ikiwa shughuli nyingine pia iliwahitaji, basi italazimika kusubiri hadi muamala wa kwanza utoe kufuli.

Hii inaitwa kufuli ya kipekee.

Lakini ni kupoteza sana kutumia kufuli za kipekee katika hali ambapo shughuli zinahitaji tu kusoma data. Kwa nini kuingilia kati na usomaji wa data? Katika hali hiyo, kufuli kwa pamoja hutumiwa. Ikiwa muamala unahitaji kusoma data, itatumia kufuli iliyoshirikiwa kwake na kuisoma. Hii haizuii miamala mingine pia kushiriki kufuli na kusoma data. Ikiwa mmoja wao anahitaji kubadilisha data, basi atalazimika kusubiri hadi kufuli zote za pamoja zitolewe. Ni hapo tu ndipo ataweza kutumia kufuli ya kipekee. Na kisha shughuli zingine zote zitalazimika kungojea iondolewe ili kusoma data hii.

Kidhibiti cha kufuli ni mchakato unaotumika na kutoa kufuli. Zimehifadhiwa kwenye jedwali la hashi (funguo ni data iliyofungwa). Msimamizi anajua kwa data yote ni shughuli gani zimetumia kufuli au zinangoja zitolewe.

Deadlock

Kutumia kufuli kunaweza kusababisha hali ambapo shughuli mbili zinangoja kwa muda usiojulikana kwa kufuli kutolewa:

Hapa, muamala A umefunga data 1 pekee na unasubiri data 2 kutolewa. Wakati huo huo, muamala B umefunga data 2 pekee na unasubiri data 1 kutolewa.

Katika msuguano, mtumaji huchagua ni shughuli gani ya kughairi (rejesha nyuma). Na uamuzi sio rahisi sana kufanya:

• Ingekuwa bora kuua muamala ambao ulirekebisha seti ya mwisho ya data (na kwa hivyo kurudisha nyuma kunaweza kuwa chungu kidogo)?
• Ingekuwa bora kuua muamala mdogo zaidi kwani watumiaji wa miamala mingine wamesubiri kwa muda mrefu zaidi?
• Ingekuwa bora kuua muamala unaochukua muda mfupi kukamilika?
• Ni shughuli ngapi zingine zitaathiriwa na urejeshaji?

Lakini kabla ya kufanya uamuzi, mtumaji lazima athibitishe ikiwa msuguano umetokea.

Wacha tufikirie jedwali la hashi katika mfumo wa mchoro, kama kwenye mfano hapo juu. Ikiwa kuna uhusiano wa mzunguko kwenye mchoro, basi msuguano unathibitishwa. Lakini kwa kuwa kuangalia kwa mizunguko ni ghali kabisa (baada ya yote, mchoro unaoonyesha kufuli zote zitakuwa kubwa kabisa), njia rahisi hutumiwa mara nyingi: kutumia muda. Ikiwa kufuli haijatolewa ndani ya muda fulani, basi shughuli imeingia katika hali ya msuguano.

Kabla ya kutumia kufuli, mtumaji anaweza pia kuangalia ili kuona ikiwa itasababisha kufungwa. Lakini kujibu hili bila utata, itabidi pia kutumia pesa kwenye mahesabu. Kwa hivyo, ukaguzi kama huo wa mapema mara nyingi huwasilishwa kama seti ya sheria za msingi.

Uzuiaji wa awamu mbili

Njia rahisi zaidi ya kufikia kutengwa kamili ni wakati kufuli inatumika mwanzoni na kutolewa mwishoni mwa shughuli. Hii ina maana kwamba shughuli lazima isubiri hadi kufuli zote kuachiliwe kabla ya kuanza, na kufuli zozote ambazo imetumia zitatolewa tu baada ya kukamilika. Njia hii inaweza kutumika, lakini basi muda mwingi unapotea kusubiri kufuli zote kutolewa.

DB2 na SQL Server hutumia itifaki ya kufunga ya awamu mbili, ambayo inagawanya shughuli katika awamu mbili:

• Awamu ya kukua, wakati muamala unaweza kutumia kufuli pekee, lakini sio kuzifungua.
• Awamu ya kupungua, wakati muamala unaweza tu kutoa kufuli (kwenye data ambayo tayari imechakatwa na haitachakatwa tena), lakini haitatumika mpya.

Mzozo wa kawaida unaotokea kwa kukosekana kwa kufuli kwa awamu mbili ni:

Kabla ya muamala A, X = 1 na Y = 1. Huchakata data Y = 1, ambayo ilibadilishwa na muamala B baada ya muamala A kuanza. Kutokana na kanuni ya kutengwa, muamala A lazima uchakate Y = 2.

Malengo yaliyofikiwa kwa kutumia sheria hizi mbili rahisi:

• Kufungua kufuli ambazo hazihitajiki tena ili kupunguza muda wa kusubiri kwa miamala mingine.
• Zuia hali ambapo muamala unapokea data iliyorekebishwa na muamala unaoendeshwa hapo awali. Data kama hiyo hailingani na data iliyoombwa.

Itifaki hii inafanya kazi vizuri, isipokuwa kwa hali ambapo shughuli ilibadilisha data na kuondoa kufuli kutoka kwayo, na kisha ikaghairiwa. Katika kesi hii, muamala mwingine unaweza kusoma na kubadilisha data, ambayo itarejeshwa. Ili kuepuka hali hii, kufuli zote za kipekee lazima zitolewe baada ya kukamilika kwa shughuli hiyo.

Kwa kweli, hifadhidata halisi hutumia mifumo ngumu zaidi, aina zaidi za kufuli na kwa granularity kubwa (kufuli kwenye safu, kurasa, kizigeu, meza, nafasi za meza), lakini kiini ni sawa.

Utayarishaji wa data

Njia nyingine ya kutatua tatizo la mgogoro wa muamala ni kutumia toleo la data.

• Shughuli zote zinaweza kurekebisha data sawa kwa wakati mmoja.
• Kila muamala hufanya kazi na nakala yake (toleo) la data.
• Ikiwa miamala miwili itarekebisha data sawa, basi moja tu ya marekebisho yatakubaliwa, nyingine itakataliwa, na shughuli iliyoifanya itarejeshwa (na ikiwezekana kuanzishwa tena).

Hii inaruhusu kuongeza tija kwa sababu:

• Shughuli za kusoma hazizuii miamala ya uandishi, na kinyume chake.
• Kidhibiti cha kufuli kigumu hakina athari.

Kwa ujumla, chochote kitakuwa bora kuliko kufuli, isipokuwa shughuli mbili zinaandika data sawa. Kwa kuongeza, hii inaweza kusababisha upotezaji mkubwa wa nafasi ya diski.

Njia zote mbili - kufunga na toleo - zina faida na hasara, inategemea sana hali ambayo hutumiwa (kusoma zaidi au kuandika zaidi). Unaweza kusoma uwasilishaji mzuri sana juu ya utekelezaji wa udhibiti wa ubadilishaji wa ubadilishanaji katika PostgreSQL.

Baadhi ya hifadhidata (DB2 kabla ya toleo la 9.7, Seva ya SQL) hutumia kufuli pekee. Wengine, kama PostgreSQL, MySQL na Oracle, hutumia mbinu zilizojumuishwa.

Kumbuka: uchapishaji una athari ya kuvutia kwenye faharisi. Wakati mwingine kuna nakala katika faharisi ya kipekee, faharisi inaweza kuwa na rekodi zaidi kuliko safu kwenye jedwali, nk.

Ikiwa sehemu ya data inasomwa kwa kiwango kimoja cha kutengwa, na kisha huongezeka, basi idadi ya kufuli huongezeka, ambayo inamaanisha muda zaidi unapotea kusubiri shughuli. Kwa hiyo, hifadhidata nyingi hazitumii kiwango cha juu cha kutengwa kwa chaguo-msingi.

Kama kawaida, rejelea hati kwa maelezo zaidi: MySQL, PostgreSQL, Oracle.

5.2.4. Meneja wa logi

Kama tunavyojua tayari, ili kuongeza utendaji, hifadhidata huhifadhi sehemu ya data kwenye kumbukumbu ya bafa. Lakini ikiwa seva itaacha kufanya kazi wakati wa ahadi ya muamala, data iliyo kwenye kumbukumbu itapotea. Na hii inakiuka kanuni ya uaminifu wa shughuli.

Bila shaka, unaweza kuandika kila kitu kwenye diski, lakini ikiwa itaanguka utaachwa na data isiyoandikwa, na hii ni ukiukwaji wa kanuni ya atomiki.

Mabadiliko yoyote yaliyoandikwa na muamala lazima yarudishwe au yakamilishwe.

Hii inafanywa kwa njia mbili:

• Nakala za kivuli / kurasa. Kila muamala huunda nakala yake ya hifadhidata (au sehemu yake) na inafanya kazi na nakala hii. Ikiwa kosa linatokea, nakala hiyo inafutwa. Ikiwa kila kitu kilikwenda vizuri, hifadhidata hubadilika mara moja kwa data kutoka kwa nakala kwa kutumia hila moja kwenye kiwango cha mfumo wa faili, na kisha kufuta data "ya zamani".
• Kumbukumbu ya shughuli. Hii ni hifadhi maalum. Kabla ya kila kuandika kwa diski, hifadhidata huandika habari kwenye logi ya shughuli. Kwa hivyo ikishindikana, hifadhidata itajua jinsi ya kufuta au kukamilisha shughuli inayosubiri.

WAL

Katika hifadhidata kubwa zilizo na shughuli nyingi, nakala za kivuli / kurasa huchukua nafasi kubwa sana ya diski. Kwa hiyo, hifadhidata za kisasa hutumia logi ya manunuzi. Lazima iwekwe kwenye uhifadhi usiofaa.

Bidhaa nyingi (haswa, Oracle, SQL Server, DB2, PostgreSQL, MySQL na SQLite) hufanya kazi na kumbukumbu za miamala kupitia itifaki ya WAL (Write-Ahead Logging). Itifaki hii ina sheria tatu:

1. Kila marekebisho kwenye hifadhidata lazima iambatane na kiingilio cha logi, na lazima ifanywe KABLA data imeandikwa kwa diski.
2. Maingizo katika logi yanapaswa kupangwa kwa mujibu wa utaratibu wa matukio husika.
3. Wakati muamala unafanywa, rekodi ya hii lazima iandikwe kwenye kumbukumbu KABLA muamala haujakamilika.

Meneja wa logi anafuatilia utekelezaji wa sheria hizi. Inapatikana kimantiki kati ya kidhibiti kache na kidhibiti cha ufikiaji wa data. Meneja wa logi huweka kila operesheni inayofanywa na shughuli hadi imeandikwa kwa diski. Inaonekana ni sawa?

KOSA! Baada ya kila kitu ambacho tumepitia katika nakala hii, ni wakati wa kukumbuka kuwa kila kitu kinachohusiana na hifadhidata kinategemea laana ya "athari ya hifadhidata." Kwa kweli, shida ni kwamba unahitaji kutafuta njia ya kuandika kwenye logi wakati wa kudumisha utendaji mzuri. Baada ya yote, ikiwa logi ya shughuli ni polepole, basi inapunguza taratibu nyingine zote.

Mapacha

Mnamo 1992, watafiti katika IBM waliunda toleo la kupanuliwa la WAL, ambalo waliliita ARIES. Kwa namna moja au nyingine, ARIES hutumiwa na hifadhidata nyingi za kisasa. Ikiwa unataka kusoma itifaki hii kwa kina zaidi, unaweza kusoma kazi inayolingana.

Kwa hivyo, ARIES inasimama A algorithms kwa R ecovery na I utulivu E x unyonyaji S mantiki. Teknolojia hii ina kazi mbili:

1. Kutoa utendaji mzuri wakati wa kuandika kumbukumbu.
2. Hakikisha kupona haraka na kwa kuaminika.

Kuna sababu kadhaa kwa nini hifadhidata inapaswa kurudisha nyuma shughuli:

1. Mtumiaji aliighairi.
2. Hitilafu ya seva au mtandao.
3. Muamala ulikiuka uadilifu wa hifadhidata. Kwa mfano, ulitumia hali ya UNIQUE kwenye safu wima, na muamala uliongeza nakala.
4. Uwepo wa vikwazo.

Lakini wakati mwingine database inaweza pia kurejesha shughuli, kwa mfano, katika tukio la kosa la mtandao.

Je, hili linawezekanaje? Ili kujibu hili, kwanza unahitaji kuelewa ni habari gani iliyohifadhiwa kwenye logi.

Kumbukumbu
Kila operesheni (kuongeza / kufuta / kubadilisha) wakati wa utekelezaji wa shughuli husababisha kuonekana kwa kuingia kwenye logi. Ingizo lina:

• LSN (Nambari ya Mfuatano wa Kumbukumbu). Hii ni nambari ya kipekee ambayo maana yake huamuliwa kwa mpangilio wa matukio. Hiyo ni, ikiwa operesheni A ilitokea kabla ya operesheni B, LSN kwa A itakuwa chini ya LSN kwa B. Kwa kweli, njia ya kuzalisha LSN ni ngumu zaidi, kwani pia inahusiana na jinsi logi inavyohifadhiwa.
• TransID. Kitambulisho cha muamala uliofanya operesheni.
• UkurasaID. Mahali kwenye diski ambapo data iliyobadilishwa iko.
• PrevLSN. Kiungo cha ingizo la awali la kumbukumbu lililoundwa na shughuli hiyo hiyo.
• TENDWA. Mbinu ya kurudisha nyuma operesheni.

  Kwa mfano, ikiwa operesheni ya sasisho ilifanywa, basi thamani / hali ya awali ya kipengele kilichobadilishwa (UNDO kimwili) au operesheni ya kinyume ambayo inakuwezesha kurudi kwenye hali ya awali (NDO ya kimantiki) imeandikwa kwa TUNDO. ARIES hutumia zile zenye mantiki tu; kufanya kazi na zile za kimwili ni ngumu sana.

• TENA UPYA. Njia ya kurudia operesheni.

Kwa kuongeza, kila ukurasa kwenye diski (kwa kuhifadhi data, sio kumbukumbu) ina LSN ya operesheni ya mwisho ambayo ilirekebisha data iliyomo.

Kwa kadiri tunavyojua, UNDO haitumiwi tu katika PostgreSQL. Badala yake, mtoza takataka hutumiwa kusafisha matoleo ya zamani ya data. Hii ni kutokana na utekelezaji wa matoleo ya data katika DBMS hii.

Ili iwe rahisi kwako kufikiria muundo wa ingizo la kumbukumbu, hapa kuna mfano uliorahisishwa kwa macho ambao hoja ya USASISHAJI KUTOKA KWA UMRI ULIOWEKA WA MTU = 18; inatekelezwa. Wacha itekelezwe katika nambari ya manunuzi 18:

Kila logi ina LSN ya kipekee. Kumbukumbu zilizounganishwa hurejelea shughuli sawa, na zimeunganishwa kwa mpangilio wa wakati (logi ya mwisho katika orodha inarejelea operesheni ya mwisho).

bafa ya kumbukumbu
Ili kuzuia ukataji miti kuwa kizuizi cha mfumo, bafa ya logi hutumiwa.

Wakati mendesha swali anaomba data iliyorekebishwa:

1. Kidhibiti cha kache huzihifadhi kwenye bafa.
2. Kidhibiti cha kumbukumbu huhifadhi logi inayolingana katika bafa yake mwenyewe.
3. Mtekelezaji wa hoja huamua ikiwa operesheni imekamilika na, ipasavyo, ikiwa data iliyobadilishwa inaweza kuombwa.
4. Meneja wa logi huhifadhi taarifa muhimu katika logi ya shughuli. Wakati wa kufanya kiingilio hiki imedhamiriwa na algorithm.
5. Meneja wa kache anaandika mabadiliko kwenye diski. Wakati wa kurekodi pia umewekwa na algorithm.

Wakati muamala ufanyika, inamaanisha kuwa hatua zote za 1 hadi 5 zimekamilika. Kuandikia kumbukumbu ya muamala ni haraka kwa sababu inawakilisha "kuongeza kumbukumbu mahali fulani kwenye kumbukumbu ya muamala." Wakati huo huo, kuandika data kwa diski ni utaratibu ngumu zaidi, kwa kuzingatia kwamba data lazima isomeke haraka.

KUIBA na sera za NGUVU

Ili kuboresha utendaji, hatua ya 5 inapaswa kufanyika baada ya ahadi, kwa kuwa katika kesi ya kushindwa bado inawezekana kurejesha shughuli kwa kutumia REDO. Hii inaitwa sera ya NO-FORCE.

Lakini hifadhidata pia inaweza kuchagua sera ya FORCE kupunguza mzigo wakati wa kurejesha. Kisha hatua ya 5 inatekelezwa kabla ya ahadi.

Hifadhidata pia huchagua ikiwa itaandika data kwa diski kwa nyongeza (sera ya STEAL) au, ikiwa msimamizi wa bafa lazima asubiri ahadi, iandike yote mara moja (NO-STEAL). Chaguo inategemea kile unachohitaji: kurekodi haraka na kupona kwa muda mrefu au kupona haraka?

Jinsi sera zilizotajwa zinavyoathiri mchakato wa urejeshaji:

• KUIBA/HAKUNA-NGUVU kunahitaji TENGENEZA na UFANYE UPYA. Utendaji ni wa juu zaidi, lakini muundo wa kumbukumbu na michakato ya kurejesha (kama ARES) ni ngumu zaidi. Hifadhidata nyingi hutumia mchanganyiko huu wa sera.
• Kwa KUIBA/NGUVU unahitaji TENDWA tu.
• Kwa HAKUNA-KUIBA/NO-NGUVU - FANYA UPYA pekee.
• Kwa HAKUNA-KUIBA/NGUVU huhitaji chochote hata kidogo. Utendaji katika kesi hii ni ya chini kabisa, na kiasi kikubwa cha kumbukumbu kinahitajika.

Ahueni

Kwa hivyo tunawezaje kutumia magogo yetu ya kushangaza? Hebu tuchukulie kwamba mfanyakazi mpya ameharibu hifadhidata (kanuni #1: daima ni kosa la mgeni!). Unaanzisha upya na mchakato wa kurejesha huanza.
ARIES hurejesha katika hatua tatu:

1. Uchambuzi. Rekodi nzima ya shughuli inasomwa ili mpangilio wa matukio yaliyotokea wakati wa kuanguka kwa hifadhidata uweze kurejeshwa. Hii husaidia kuamua ni muamala upi unahitaji kurejeshwa. Shughuli zote bila agizo la ahadi hurejeshwa. Mfumo pia huamua ni data gani inapaswa kuandikwa kwenye diski wakati wa kushindwa.
2. Rudia. REDO hutumiwa kusasisha hifadhidata hadi hali kabla ya ajali. Kumbukumbu zake huchakatwa kwa mpangilio wa matukio. Kwa kila logi, LSN ya ukurasa kwenye diski iliyo na data inayohitaji kubadilishwa inasomwa.

   Ikiwa LSN(pages_on_disk)>=LSN(entries_in_log), basi data ilikuwa tayari imeandikwa kwenye diski kabla ya kushindwa. Lakini thamani ilifutwa na operesheni ambayo ilifanywa baada ya kuandika kwa logi na kabla ya kushindwa. Kwa hivyo hakuna kitu kimefanywa, kwa kweli.

   Ikiwa LSN(kurasa_kwenye_diski)

   Mchezo wa marudio unafanywa hata kwa miamala ambayo itarejeshwa kwa sababu hurahisisha mchakato wa urejeshaji. Lakini hifadhidata za kisasa labda hazifanyi hivi.

3. Ghairi. Katika hatua hii, shughuli zote ambazo hazijakamilika wakati wa kutofaulu zinarejeshwa. Mchakato huanza na kumbukumbu za hivi punde za kila muamala na huchakata TUNDOS kwa mpangilio wa nyuma kwa kutumia PrevLSN.

Wakati wa mchakato wa kurejesha, logi ya shughuli lazima ifahamu vitendo vilivyofanywa wakati wa kurejesha. Hii ni muhimu ili kusawazisha data iliyohifadhiwa kwenye diski na ile iliyorekodiwa kwenye logi ya shughuli. Inawezekana kufuta rekodi za shughuli ambazo zimerudishwa nyuma, lakini hii ni vigumu sana kufanya. Badala yake, ARIES hufanya maingizo ya kufidia katika kumbukumbu ya muamala ambayo kimantiki yanabatilisha maingizo ya miamala iliyorudishwa nyuma.

Ikiwa shughuli hiyo imefutwa "kwa manually", au kwa meneja wa kufuli, au kutokana na kushindwa kwa mtandao, basi hatua ya uchambuzi haihitajiki. Baada ya yote, habari ya REDO na TUNDO iko kwenye jedwali mbili zilizo kwenye kumbukumbu:

• Katika meza ya shughuli (majimbo ya shughuli zote za sasa zimehifadhiwa hapa).
• Jedwali la kurasa chafu (hii ina habari kuhusu data gani inahitaji kuandikwa kwenye diski).

Mara tu muamala mpya unapoonekana, majedwali haya yanasasishwa na msimamizi wa akiba na msimamizi wa muamala. Na kwa kuwa meza zimehifadhiwa kwenye kumbukumbu, ikiwa hifadhidata itaanguka hupotea.

Hatua ya uchanganuzi inahitajika ili kurejesha majedwali yote mawili kwa kutumia taarifa kutoka kwa kumbukumbu ya muamala. Ili kuharakisha awamu hii, ARIES hutumia vituo vya ukaguzi. Yaliyomo kwenye meza zote mbili, pamoja na LSN ya hivi karibuni wakati wa kuandika, imeandikwa kwenye diski mara kwa mara. Kwa hivyo wakati wa urejeshaji, magogo tu yanayofuata LSN hii yanachambuliwa.

6. Hitimisho

Kama muhtasari wa ziada wa kusoma kuhusu hifadhidata, tunaweza kupendekeza Usanifu wa Makala ya Mfumo wa Hifadhidata. Huu ni utangulizi mzuri wa mada, iliyoandikwa kwa lugha iliyo wazi kabisa.

Ukisoma kwa uangalifu nyenzo zote hapo juu, labda ulipata wazo la jinsi uwezo wa hifadhidata ulivyo. Walakini, nakala hii haizungumzii maswala mengine muhimu:

• Jinsi ya kudhibiti hifadhidata zilizounganishwa na miamala ya kimataifa.
• Jinsi ya kupata snapshot ikiwa hifadhidata inafanya kazi.
• Jinsi ya kuhifadhi na kubana data kwa ufanisi.
• Jinsi ya kusimamia kumbukumbu.

Kwa hivyo fikiria mara mbili kabla ya kuchagua kati ya buggy NoSQL na hifadhidata thabiti ya uhusiano. Usinielewe vibaya, hifadhidata zingine za NoSQL ni nzuri sana. Lakini bado ni mbali na kamilifu na inaweza tu kusaidia kutatua matatizo maalum yanayohusiana na programu fulani.

Kwa hivyo, ikiwa mtu atakuuliza jinsi hifadhidata inavyofanya kazi, basi badala ya kukata tamaa na kuondoka, unaweza kujibu:

Lebo: Ongeza vitambulisho