റിലേഷണൽ ഡാറ്റാബേസുകൾകീകൾ എന്ന് വിളിക്കപ്പെടുന്ന പങ്കിട്ട ഡാറ്റാ ഫീൽഡുകളിലൂടെ പരസ്പരം ബന്ധിപ്പിച്ചിരിക്കുന്ന നിരവധി "ഫ്ലാറ്റ്" (ദ്വിമാന) പട്ടികകളിൽ വിവരങ്ങൾ സംഭരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. റിലേഷണൽ ഡാറ്റാബേസുകൾ ഓൺ-ദി-ഫ്ലൈ റിപ്പോർട്ടുകളിലേക്ക് (സാധാരണയായി SQL വഴി) എളുപ്പത്തിൽ ആക്സസ് നൽകുന്നു, കൂടാതെ അനാവശ്യ വിവരങ്ങൾ ഒഴിവാക്കി വർദ്ധിച്ച ഡാറ്റ വിശ്വാസ്യതയും സമഗ്രതയും നൽകുന്നു.

ലളിതമായ ഡാറ്റാബേസ് എന്താണെന്ന് എല്ലാവർക്കും അറിയാം: ടെലിഫോൺ ഡയറക്ടറികൾ, ഉൽപ്പന്ന കാറ്റലോഗുകൾ, നിഘണ്ടുക്കൾ എന്നിവയെല്ലാം ഡാറ്റാബേസുകളാണ്. അവ ഘടനാപരമായതോ മറ്റുവിധത്തിൽ ക്രമീകരിച്ചതോ ആകാം: പരന്ന ഫയലുകൾ, ശ്രേണി അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ഘടനകൾ, അല്ലെങ്കിൽ റിലേഷണൽ ടേബിളുകൾ. മിക്കപ്പോഴും, വിവരങ്ങൾ സംഭരിക്കാൻ ഓർഗനൈസേഷനുകൾ റിലേഷണൽ ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുന്നു.

ഒരു സ്‌പ്രെഡ്‌ഷീറ്റിന് സമാനമായ കോളങ്ങളും വരികളും ചേർന്ന പട്ടികകളുടെ ശേഖരമാണ് ഡാറ്റാബേസ്. ഓരോ വരിയിലും ഒരു എൻട്രി അടങ്ങിയിരിക്കുന്നു; ഓരോ നിരയിലും എല്ലാ വരികളിൽ നിന്നുമുള്ള ഒരു പ്രത്യേക ഡാറ്റയുടെ എല്ലാ സന്ദർഭങ്ങളും അടങ്ങിയിരിക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു സാധാരണ ടെലിഫോൺ ഡയറക്ടറിയിൽ ടെലിഫോൺ നമ്പറുകൾ, വിളിക്കുന്നവരുടെ പേരുകൾ, കോളർ വിലാസങ്ങൾ എന്നിവ അടങ്ങിയ നിരകൾ അടങ്ങിയിരിക്കുന്നു. ഓരോ വരിയിലും ഒരു നമ്പറും പേരും വിലാസവും അടങ്ങിയിരിക്കുന്നു. ഈ ലളിതമായ രൂപത്തെ അതിന്റെ ദ്വിമാന സ്വഭാവവും എല്ലാ ഡാറ്റയും ഒരൊറ്റ ഫയലിൽ സംഭരിച്ചിരിക്കുന്നതിനാൽ ഫ്ലാറ്റ് ഫയൽ എന്ന് വിളിക്കുന്നു.

എബൌട്ട്, എല്ലാ ഡാറ്റാബേസിനും ഒരു അദ്വിതീയ ഐഡന്റിഫയർ അല്ലെങ്കിൽ കീ ഉള്ള ഒരു കോളമെങ്കിലും ഉണ്ടായിരിക്കും. ഫോൺ ബുക്ക് പരിഗണിക്കുക. കോളർ ജോൺ സ്മിത്തിന് നിരവധി എൻട്രികൾ ഉണ്ടായേക്കാം, എന്നാൽ ഫോൺ നമ്പറുകളൊന്നും ആവർത്തിക്കപ്പെടുന്നില്ല. ഫോൺ നമ്പർ ഒരു കീ ആയി പ്രവർത്തിക്കുന്നു.

വാസ്തവത്തിൽ, എല്ലാം അത്ര ലളിതമല്ല. ഒരേ ടെലിഫോൺ നമ്പർ ഉപയോഗിക്കുന്ന രണ്ടോ അതിലധികമോ ആളുകൾ ടെലിഫോൺ ഡയറക്‌ടറിയിൽ വെവ്വേറെ ലിസ്‌റ്റ് ചെയ്‌തേക്കാം, ഇത് ടെലിഫോൺ നമ്പർ രണ്ടോ അതിലധികമോ സ്ഥലങ്ങളിൽ ദൃശ്യമാകുന്നതിന് കാരണമാകുന്നു, അതുവഴി അദ്വിതീയമല്ലാത്ത ഒന്നിലധികം കീ സ്‌ട്രിംഗുകൾ ഉണ്ട്.

ഡാറ്റ പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു

ഏറ്റവും ലളിതമായ ഡാറ്റാബേസുകളിൽ, ഓരോ റെക്കോർഡും ഒരു വരി ഉൾക്കൊള്ളുന്നു, മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ടെലിഫോൺ കമ്പനി ഓരോ അക്കൗണ്ടിംഗ് വിവരത്തിനും ഒരു പ്രത്യേക കോളം സൃഷ്ടിക്കേണ്ടതുണ്ട്. അതായത്, "ജോടിയാക്കിയ" ഫോണിന്റെ രണ്ടാമത്തെ വരിക്കാരന് ഒന്ന്, മൂന്നാമത്തേതിന് മറ്റൊന്ന് മുതലായവ, എത്ര അധിക സബ്സ്ക്രൈബർമാരെ ആവശ്യമുണ്ട് എന്നതിനെ ആശ്രയിച്ച്.

മറ്റെവിടെയും ഉപയോഗിച്ചിട്ടില്ലെങ്കിലും, ഡാറ്റാബേസിലെ എല്ലാ റെക്കോർഡുകളിലും ഈ അധിക നിരകളെല്ലാം ഉണ്ടായിരിക്കണം എന്നാണ് ഇതിനർത്ഥം. ഒരു കമ്പനി ഒരു പുതിയ സേവനം വാഗ്ദാനം ചെയ്യുമ്പോഴെല്ലാം ഡാറ്റാബേസ് പുനഃസംഘടിപ്പിക്കണം എന്നാണ് ഇതിനർത്ഥം. ടോൺ ഡയലിംഗ് സേവനം അവതരിപ്പിച്ചു - കൂടാതെ ഒരു പുതിയ കോളം ചേർക്കുമ്പോൾ ഡാറ്റാബേസിന്റെ ഘടന മാറുന്നു. കോളർ ഐഡി, കോൾ വെയിറ്റിംഗ് മുതലായവയ്ക്കുള്ള പിന്തുണ അവതരിപ്പിക്കുന്നു - ഡാറ്റാബേസ് വീണ്ടും വീണ്ടും പുനർനിർമ്മിക്കുന്നു.

1960-കളിൽ, ഏറ്റവും വലിയ കമ്പനികൾക്ക് മാത്രമേ അവരുടെ ഡാറ്റ നിയന്ത്രിക്കാൻ കമ്പ്യൂട്ടറുകൾ വാങ്ങാൻ കഴിയുമായിരുന്നുള്ളൂ. കൂടാതെ, സ്റ്റാറ്റിക് ഡാറ്റ മോഡലുകളും കോബോൾ പോലുള്ള പ്രൊസീജറൽ പ്രോഗ്രാമിംഗ് ഭാഷകളും ഉപയോഗിച്ച് നിർമ്മിച്ച ഡാറ്റാബേസുകൾ പരിപാലിക്കാൻ ചെലവേറിയതും എല്ലായ്പ്പോഴും വിശ്വസനീയവുമല്ല. ഒരു ടാസ്ക് പൂർത്തിയാക്കാൻ കമ്പ്യൂട്ടർ കടന്നുപോകേണ്ട സംഭവങ്ങളുടെ ഒരു ശ്രേണിയെ നടപടിക്രമ ഭാഷകൾ നിർവ്വചിക്കുന്നു. അത്തരം സീക്വൻസുകൾ പ്രോഗ്രാമിംഗ് ബുദ്ധിമുട്ടായിരുന്നു, പ്രത്യേകിച്ചും നിങ്ങൾക്ക് ഡാറ്റാബേസിന്റെ ഘടന മാറ്റുകയോ ഒരു പുതിയ തരം റിപ്പോർട്ട് സൃഷ്ടിക്കുകയോ ചെയ്യണമെങ്കിൽ.

ശക്തമായ കണക്ഷനുകൾ

IBM-ന്റെ സാൻ ജോസ് റിസർച്ച് ലബോറട്ടറിയിലെ ഗവേഷകനായ എഡ്ഗർ കോഡ്, തന്റെ അടിസ്ഥാന കൃതിയായ എ റിലേഷണൽ മോഡൽ ഫോർ ലാർജ് ഷെയർഡ് ഡാറ്റാ ബാങ്കുകൾക്കായി റിലേഷണൽ ഡാറ്റാബേസുകളുടെ ആശയം സൃഷ്ടിക്കുകയും വിവരിക്കുകയും ചെയ്തു. ACM-ന്റെ ആശയവിനിമയങ്ങൾ, ജൂൺ 1970).

ഡെവലപ്പർമാർക്ക് അവരുടെ ഡാറ്റാബേസുകൾ വേറിട്ടതും എന്നാൽ ബന്ധപ്പെട്ടതുമായ ടേബിളുകളായി വിഭജിക്കാൻ അനുവദിക്കുന്ന ഒരു മോഡൽ കോഡ് നിർദ്ദേശിച്ചു, ഇത് യഥാർത്ഥ ഡാറ്റാബേസിന്റെ അതേ രൂപഭാവം നിലനിർത്തിക്കൊണ്ട് പ്രകടനം മെച്ചപ്പെടുത്തുന്നു. അതിനുശേഷം, റിലേഷണൽ ഡാറ്റാബേസ് വ്യവസായത്തിന്റെ സ്ഥാപക പിതാവായി കോഡ് കണക്കാക്കപ്പെടുന്നു.

ഈ മോഡൽ ഇനിപ്പറയുന്ന രീതിയിൽ പ്രവർത്തിക്കുന്നു. ടെലിഫോൺ കമ്പനിക്ക് പ്രാഥമിക താക്കോലായി ടെലിഫോൺ നമ്പർ ഉപയോഗിച്ച് ഒരു മാസ്റ്റർ ടേബിൾ സൃഷ്ടിക്കാനും മറ്റ് അടിസ്ഥാന ഉപഭോക്തൃ വിവരങ്ങളോടൊപ്പം സംഭരിക്കാനും കഴിയും. ഈ പ്രൈമറി കീയ്‌ക്കും കോളർ ഐഡി പിന്തുണ, കോൾ വെയ്‌റ്റിംഗ് തുടങ്ങിയ അധിക സേവനങ്ങൾക്കുമായി ഒരു കമ്പനിക്ക് കോളങ്ങളുള്ള ഒരു പ്രത്യേക പട്ടിക നിർവചിക്കാനാകും. കോൾ ബില്ലുകൾ നിയന്ത്രിക്കാൻ അവൾക്ക് മറ്റൊരു ടേബിൾ സൃഷ്ടിക്കാനും കഴിയും, അവിടെ ഓരോ എൻട്രിയിലും ഒരു ഫോൺ നമ്പറും കോൾ ചാർജ് ഡാറ്റയും അടങ്ങിയിരിക്കുന്നു.

വിവിധ ടേബിളുകളിൽ ഡാറ്റ സംഭരിച്ചിട്ടുണ്ടെങ്കിലും അന്തിമ ഉപയോക്താക്കൾക്ക് അവർക്ക് ആവശ്യമുള്ള വിവരങ്ങൾ എളുപ്പത്തിൽ ലഭിക്കും. അതിനാൽ, ഒരു ടെലിഫോൺ കമ്പനി ഉപഭോക്തൃ സേവന പ്രതിനിധിക്ക് ഒരു വരിക്കാരന്റെ ബില്ലിംഗിനെ കുറിച്ചുള്ള വിവരങ്ങളും പ്രത്യേക സേവനങ്ങളുടെ നിലയും അല്ലെങ്കിൽ അവസാന പേയ്‌മെന്റ് ലഭിച്ച സമയവും അതേ സ്ക്രീനിൽ പ്രദർശിപ്പിക്കാൻ കഴിയും.

റിലേഷണൽ ഡാറ്റാബേസുകൾക്കായി കോഡ് 12 നിയമങ്ങൾ രൂപീകരിച്ചു, അവയിൽ മിക്കതും ഡാറ്റയുടെ സമഗ്രത, അപ്‌ഡേറ്റ്, ആക്‌സസ് എന്നിവയെ ബാധിക്കുന്നു. ആദ്യത്തെ രണ്ടെണ്ണം സാങ്കേതികമല്ലാത്ത ഉപയോക്താക്കൾക്ക് പോലും വളരെ വ്യക്തമാണ്.

റൂൾ 1, വിവര നിയമം, ഒരു റിലേഷണൽ ഡാറ്റാബേസിലെ എല്ലാ വിവരങ്ങളും പട്ടികകളിൽ സംഭരിച്ചിരിക്കുന്ന മൂല്യങ്ങളുടെ ഒരു കൂട്ടമായി പ്രതിനിധീകരിക്കുന്നു.

റൂൾ 2, ആക്‌സസ് ഗ്യാരന്റി റൂൾ, ഒരു റിലേഷണൽ ഡാറ്റാബേസിലെ എല്ലാ ഡാറ്റ എലമെന്റും ഒരു പട്ടികയുടെ പേര്, ഒരു പ്രാഥമിക കീ, കോളത്തിന്റെ പേര് എന്നിവ ഉപയോഗിച്ച് ആക്‌സസ് ചെയ്യാൻ കഴിയുമെന്ന് വ്യക്തമാക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, എല്ലാ ഡാറ്റയും പട്ടികകളിൽ സംഭരിച്ചിരിക്കുന്നു, കൂടാതെ ആവശ്യമുള്ള ഡാറ്റാ ഇനം സ്ഥിതി ചെയ്യുന്ന പട്ടികയുടെ പേര്, പ്രാഥമിക കീ, കോളം എന്നിവ നിങ്ങൾക്ക് അറിയാമെങ്കിൽ, അത് എല്ലായ്പ്പോഴും വീണ്ടെടുക്കാൻ കഴിയും.

റിലേഷണൽ ഡാറ്റാബേസുകളുള്ള പ്രൊസീജറൽ പ്രോഗ്രാമിംഗ് ഭാഷകളേക്കാൾ ഡിക്ലറേറ്റീവ് ഉപയോഗിക്കാൻ നിർദ്ദേശിച്ചു എന്നതാണ് കോഡിന്റെ പ്രവർത്തനത്തിന്റെ സാരം. SQL (സ്ട്രക്ചേർഡ് ക്വറി ലാംഗ്വേജ്) പോലുള്ള ഡിക്ലറേറ്റീവ് ഭാഷകൾ ഉപയോക്താക്കൾക്ക് കമ്പ്യൂട്ടറിനോട് പറയാനുള്ള കഴിവ് നൽകുന്നു, "ഒരു നിശ്ചിത മാനദണ്ഡങ്ങൾ പാലിക്കുന്ന എല്ലാ റെക്കോർഡുകളിൽ നിന്നും ഇനിപ്പറയുന്ന ബിറ്റ് ഡാറ്റ വീണ്ടെടുക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു." ഡാറ്റാബേസിൽ നിന്ന് ഈ വിവരങ്ങൾ ലഭിക്കുന്നതിന് എന്ത് നടപടികൾ കൈക്കൊള്ളണമെന്ന് കമ്പ്യൂട്ടർ തന്നെ "മനസ്സിലാക്കും".

സജീവമായി ഉപയോഗിക്കുന്ന ധാരാളം ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കാൻ, ഒറാക്കിൾ, സൈബേസ്, ഐബിഎം, ഇൻഫോർമിക്സ്, മൈക്രോസോഫ്റ്റ് തുടങ്ങിയ പ്രശസ്തരായ നിർമ്മാതാക്കൾ സൃഷ്ടിച്ച റിലേഷണൽ ഡാറ്റാബേസ് മാനേജ്മെന്റ് സോഫ്റ്റ്വെയർ സിസ്റ്റങ്ങൾ ഉപയോഗിക്കുന്നു.

മിക്ക SQL നടപ്പിലാക്കലുകളും ഒരു നിശ്ചിത ഏകദേശത്തിനുള്ളിൽ മാത്രമേ ഇന്റർഓപ്പറബിൾ എന്ന് വിളിക്കാൻ കഴിയൂ എങ്കിലും, ഒരു അന്താരാഷ്ട്ര നിലവാരമായി അംഗീകരിച്ച ഈ സംവിധാനം സങ്കീർണ്ണമായ ഡാറ്റാബേസ്-അധിഷ്ഠിത സിസ്റ്റങ്ങൾ സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു. വെബ്‌സൈറ്റുകൾക്കും റിലേഷണൽ ഡാറ്റാബേസുകൾക്കുമിടയിൽ പ്രോഗ്രാം ചെയ്യാൻ എളുപ്പമുള്ള ഇന്റർഫേസ് അന്തിമ ഉപയോക്താക്കൾക്ക് പുതിയ റെക്കോർഡുകൾ ചേർക്കാനും നിലവിലുള്ളവ അപ്‌ഡേറ്റ് ചെയ്യാനും ഓൺലൈൻ ട്രേഡിംഗ്, ഓൺലൈൻ ലൈബ്രറി കാറ്റലോഗുകളിലേക്കുള്ള ആക്‌സസ് എന്നിവ പോലുള്ള വിവിധ സേവനങ്ങൾക്കായി റിപ്പോർട്ടുകൾ സൃഷ്‌ടിക്കാനുമുള്ള കഴിവ് നൽകുന്നു.

റിലേഷണൽ മോഡൽ

ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ഒരു നിർദ്ദിഷ്‌ട കീ വഴി പരസ്പരം ബന്ധപ്പെട്ട ഒരു കൂട്ടം പട്ടികകൾ ഉപയോഗിക്കുന്നു (ഈ സാഹചര്യത്തിൽ, ഫോൺ നമ്പർ ഫീൽഡ്)

ഡാറ്റാബേസ് (DB) -ഒരു നിർദ്ദിഷ്‌ട വിഷയ മേഖലയുമായി ബന്ധപ്പെട്ടതും ഒരു കമ്പ്യൂട്ടർ ഉപയോഗിച്ച് സംഭരണം, ശേഖരിക്കൽ, പ്രോസസ്സിംഗ് എന്നിവയ്ക്കായി ഉദ്ദേശിച്ചിട്ടുള്ളതുമായ ഘടനാപരമായ ഡാറ്റയുടെ പേരുള്ള ഒരു കൂട്ടമാണിത്.

റിലേഷണൽ ഡാറ്റാബേസ് (RDB)ഡാറ്റാബേസ് സ്കീമയിലെ സ്കീമ ബന്ധങ്ങളുടെ പേരുകളുമായി പൊരുത്തപ്പെടുന്ന ഒരു കൂട്ടം ബന്ധങ്ങളാണ്.

അടിസ്ഥാന സങ്കൽപങ്ങൾറിലേഷണൽ ഡാറ്റാബേസുകൾ:

· ഡാറ്റ തരം- ഒരു നിർദ്ദിഷ്ട നിരയുടെ മൂല്യങ്ങളുടെ തരം.

· ഡൊമെയ്ൻ(ഡൊമെയ്ൻ) - എല്ലാ സാധുവായ ആട്രിബ്യൂട്ട് മൂല്യങ്ങളുടെയും സെറ്റ്.

· ആട്രിബ്യൂട്ട്(ആട്രിബ്യൂട്ട്) - ഒരു ഒബ്‌ജക്‌റ്റിന്റെ പേരുള്ള പ്രോപ്പർട്ടി ചിത്രീകരിക്കുന്ന പട്ടിക കോളം തലക്കെട്ട്, ഉദാഹരണത്തിന്, വിദ്യാർത്ഥിയുടെ അവസാന നാമം, ഓർഡർ തീയതി, ജീവനക്കാരന്റെ ലിംഗഭേദം മുതലായവ.

· കോർട്ടെജ്- യുക്തിപരമായി ബന്ധപ്പെട്ട ആട്രിബ്യൂട്ടുകളുടെ ഒരു കൂട്ടം മൂല്യങ്ങളെ പ്രതിനിധീകരിക്കുന്ന ഒരു പട്ടിക വരി.

· മനോഭാവം(ബന്ധം) - യഥാർത്ഥ ലോക വസ്തുക്കളെക്കുറിച്ചുള്ള വിവരങ്ങൾ പ്രതിഫലിപ്പിക്കുന്ന ഒരു പട്ടിക, ഉദാഹരണത്തിന്, വിദ്യാർത്ഥികൾ, ഓർഡറുകൾ, ജീവനക്കാർ, താമസക്കാർ മുതലായവ.

· പ്രാഥമിക കീ(പ്രാഥമിക കീ) - ഒരു പട്ടികയുടെ ഒരു ഫീൽഡ് (അല്ലെങ്കിൽ ഫീൽഡുകളുടെ കൂട്ടം) അതിലെ ഓരോ റെക്കോർഡുകളും അദ്വിതീയമായി തിരിച്ചറിയുന്നു.

· ഇതര കീപ്രൈമറി കീയുമായി പൊരുത്തപ്പെടാത്ത ഒരു ഫീൽഡ് (അല്ലെങ്കിൽ ഫീൽഡുകളുടെ കൂട്ടം) ഒരു റെക്കോർഡിന്റെ ഒരു ഉദാഹരണം അദ്വിതീയമായി തിരിച്ചറിയുന്നു.

· ബാഹ്യ കീമറ്റൊരു പട്ടികയുടെ പ്രാഥമിക കീയുടെ നിലവിലുള്ള മൂല്യങ്ങളുമായി പൊരുത്തപ്പെടുന്ന ഒരു ഫീൽഡ് (അല്ലെങ്കിൽ ഫീൽഡുകളുടെ കൂട്ടം) ആണ്. നിങ്ങൾ രണ്ട് പട്ടികകൾ ലിങ്കുചെയ്യുമ്പോൾ, ആദ്യ പട്ടികയുടെ പ്രാഥമിക കീ രണ്ടാമത്തെ പട്ടികയുടെ വിദേശ കീയുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു.

· റിലേഷണൽ ഡാറ്റ മോഡൽ (RDM)- ദ്വിമാന പട്ടികകളുടെ രൂപത്തിൽ ഡാറ്റ സംഘടിപ്പിക്കുന്നു.

ഓരോ റിലേഷണൽ ടേബിളിനും ഇനിപ്പറയുന്ന ഗുണങ്ങൾ ഉണ്ടായിരിക്കണം:

1. ഓരോ പട്ടിക റെക്കോർഡും അദ്വിതീയമാണ്, അതായത്. ഫീൽഡുകളിലെ മൂല്യങ്ങളുടെ കൂട്ടം ആവർത്തിക്കില്ല.

2. ഒരു വരിയുടെയും നിരയുടെയും കവലയിൽ എഴുതപ്പെട്ട ഓരോ മൂല്യവും ആറ്റോമിക് (വേർപെടുത്താനാവാത്തതാണ്).

3. ഓരോ ഫീൽഡിന്റെയും മൂല്യങ്ങൾ ഒരേ തരത്തിലുള്ളതായിരിക്കണം.

4. ഓരോ ഫീൽഡിനും തനതായ പേരുണ്ട്.

5. എൻട്രികളുടെ ക്രമം പ്രധാനമല്ല.

ഡാറ്റാബേസിന്റെ പ്രധാന ഘടകങ്ങൾ:

ഫീൽഡ്- ഡാറ്റയുടെ ലോജിക്കൽ ഓർഗനൈസേഷന്റെ ഒരു പ്രാഥമിക യൂണിറ്റ്. ഫീൽഡ് വിവരിക്കാൻ ഇനിപ്പറയുന്ന സവിശേഷതകൾ ഉപയോഗിക്കുന്നു:

· പേര്, ഉദാഹരണത്തിന്, അവസാന നാമം, ആദ്യനാമം, രക്ഷാധികാരി, ജനനത്തീയതി;

· തരം, ഉദാഹരണത്തിന്, സ്ട്രിംഗ്, പ്രതീകം, സംഖ്യ, തീയതി;

· നീളം, ഉദാഹരണത്തിന്, ബൈറ്റുകളിൽ;

· ഒരു സംഖ്യയുടെ ഫ്രാക്ഷണൽ ഭാഗം കാണിക്കുന്നതിനുള്ള രണ്ട് ദശാംശ സ്ഥാനങ്ങൾ പോലെയുള്ള സംഖ്യാ ഡാറ്റയുടെ കൃത്യത.

രേഖപ്പെടുത്തുക- യുക്തിപരമായി ബന്ധപ്പെട്ട ഫീൽഡുകളുടെ മൂല്യങ്ങളുടെ ഒരു കൂട്ടം.

സൂചിക- പട്ടികകൾ തമ്മിലുള്ള ബന്ധം സ്ഥാപിക്കാൻ ഉപയോഗിക്കുന്ന റെക്കോർഡ് തിരയൽ പ്രവർത്തനം വേഗത്തിലാക്കുന്നതിനുള്ള ഒരു മാർഗം. ഒരു സൂചിക ഉപയോഗിക്കുന്ന ഒരു പട്ടികയെ സൂചിക എന്ന് വിളിക്കുന്നു. സൂചികകളുമായി പ്രവർത്തിക്കുമ്പോൾ, വർഗ്ഗീകരണത്തിന്റെ അടിസ്ഥാനമായ സൂചികകളുടെ ഓർഗനൈസേഷനിൽ നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. ഒരു ലളിതമായ സൂചികയെ ഒരു ഫീൽഡ് അല്ലെങ്കിൽ ഒരു ഫീൽഡ് പ്രോസസ്സ് ചെയ്യുന്ന ഒരു ബൂളിയൻ എക്സ്പ്രഷൻ പ്രതിനിധീകരിക്കുന്നു. വിവിധ ഫംഗ്‌ഷനുകൾ ഉപയോഗിക്കാനുള്ള കഴിവുള്ള നിരവധി ഫീൽഡുകൾ ഒരു സംയോജിത സൂചികയെ പ്രതിനിധീകരിക്കുന്നു. പട്ടിക സൂചികകൾ ഒരു സൂചിക ഫയലിൽ സംഭരിച്ചിരിക്കുന്നു.

ഡാറ്റ സമഗ്രതആശയവിനിമയ ഫീൽഡുകളിലെ ഡാറ്റ പരിരക്ഷിക്കുന്നതിനുള്ള ഒരു മാർഗമാണിത്, ഇത് സ്ഥിരമായ (സ്ഥിരമായ) അവസ്ഥയിൽ പട്ടികകൾ നിലനിർത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു (അതായത്, മാതാപിതാക്കളിൽ അനുബന്ധ രേഖകളില്ലാത്ത സബോർഡിനേറ്റ് ടേബിളിൽ റെക്കോർഡുകളുടെ നിലനിൽപ്പ് ഇത് അനുവദിക്കുന്നില്ല. മേശ).

അഭ്യർത്ഥിക്കുക- ഡാറ്റ സാംപ്ലിംഗ് മാനദണ്ഡങ്ങൾ അടങ്ങിയ ഒന്നോ അതിലധികമോ പരസ്പര ബന്ധിത പട്ടികകൾക്കായുള്ള രൂപപ്പെടുത്തിയ ചോദ്യം. ഘടനാപരമായ അന്വേഷണ ഭാഷ SQL (ഘടനാപരമായ അന്വേഷണ ഭാഷ) ഉപയോഗിച്ചാണ് അന്വേഷണം നടത്തുന്നത്. ഒന്നോ അതിലധികമോ പട്ടികകളിൽ നിന്ന് ഡാറ്റ വീണ്ടെടുക്കുന്നത് ഒരു വ്യൂ എന്ന് വിളിക്കപ്പെടുന്ന റെക്കോർഡുകളുടെ ഒരു കൂട്ടത്തിന് കാരണമാകും.

ഡാറ്റ അവതരണം- ഡാറ്റ വീണ്ടെടുക്കുന്നതിന് (ഒന്നോ അതിലധികമോ പട്ടികകളിൽ നിന്ന്) ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന ഒരു പേരുള്ള ചോദ്യം.

ഒരു കാഴ്‌ച പ്രധാനമായും ഒരു അന്വേഷണത്തിന്റെ ഫലമായി സൃഷ്‌ടിച്ച ഒരു താൽക്കാലിക പട്ടികയാണ്. അഭ്യർത്ഥന തന്നെ ഒരു പ്രത്യേക ഫയൽ, റിപ്പോർട്ട്, താൽക്കാലിക ടേബിൾ, ഡിസ്കിലെ ടേബിൾ മുതലായവയിലേക്ക് അയയ്ക്കാം.

റിപ്പോർട്ട് ചെയ്യുക- ഡാറ്റാബേസിൽ നിന്നുള്ള വിവരങ്ങളെ അടിസ്ഥാനമാക്കി ഡോക്യുമെന്റുകൾ വിവരിക്കുകയും അച്ചടിക്കുകയും ചെയ്യുന്ന ഒരു സിസ്റ്റം ഘടകം.

RDB-യുമായി പ്രവർത്തിക്കുന്നതിന്റെ പൊതു സവിശേഷതകൾ:

റിലേഷണൽ ഡാറ്റ മോഡലിന്റെ ഏറ്റവും സാധാരണമായ വ്യാഖ്യാനം ഡാറ്റയുടേതാണെന്ന് തോന്നുന്നു, അത് (വിവിധ പരിഷ്കരണങ്ങളോടെ) തന്റെ മിക്കവാറും എല്ലാ പുസ്തകങ്ങളിലും പുനർനിർമ്മിക്കുന്നു. തീയതി അനുസരിച്ച്, റിലേഷണൽ സമീപനത്തിന്റെ വ്യത്യസ്ത വശങ്ങൾ വിവരിക്കുന്ന മൂന്ന് ഭാഗങ്ങൾ റിലേഷണൽ മോഡലിൽ അടങ്ങിയിരിക്കുന്നു: ഘടനാപരമായ ഭാഗം, കൃത്രിമത്വം ഭാഗം, സമഗ്രമായ ഭാഗം.

റിലേഷണൽ ഡാറ്റാബേസുകളിൽ ഉപയോഗിക്കുന്ന ഏക ഡാറ്റാ ഘടന നോർമലൈസ്ഡ് n-ary റിലേഷൻ ആണെന്ന് മോഡലിന്റെ ഘടനാപരമായ ഭാഗം പറയുന്നു.

മോഡലിന്റെ കൃത്രിമത്വം ഭാഗം റിലേഷണൽ ഡാറ്റാബേസുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള രണ്ട് അടിസ്ഥാന സംവിധാനങ്ങൾ സ്ഥിരീകരിക്കുന്നു - റിലേഷണൽ ബീജഗണിതവും റിലേഷണൽ കാൽക്കുലസും. ആദ്യ മെക്കാനിസം പ്രധാനമായും ക്ലാസിക്കൽ സെറ്റ് സിദ്ധാന്തത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് (ചില പരിഷ്കരണങ്ങളോടെ), രണ്ടാമത്തേത് ഫസ്റ്റ്-ഓർഡർ പ്രെഡിക്കേറ്റ് കാൽക്കുലസിന്റെ ക്ലാസിക്കൽ ലോജിക്കൽ ഉപകരണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഏതെങ്കിലും നിർദ്ദിഷ്ട റിലേഷണൽ ഡാറ്റാബേസ് ഭാഷയുടെ റിലേഷനാലിറ്റിയുടെ അളവ് നൽകുക എന്നതാണ് റിലേഷണൽ മോഡലിന്റെ കൃത്രിമത്വ ഭാഗത്തിന്റെ പ്രധാന പ്രവർത്തനം എന്നത് ശ്രദ്ധിക്കുക: റിലേഷണൽ ബീജഗണിതത്തെക്കാളും റിലേഷണൽ കാൽക്കുലസിനേക്കാളും പ്രകടിപ്പിക്കുന്ന ശക്തിയും ശക്തിയും കുറവാണെങ്കിൽ ഒരു ഭാഷയെ റിലേഷണൽ എന്ന് വിളിക്കുന്നു.

28. അൽഗോരിഥമിക് ഭാഷകൾ. വിവർത്തകർ (വ്യാഖ്യാതാക്കളും കമ്പൈലർമാരും). അൽഗോരിഥമിക് ഭാഷ അടിസ്ഥാനം. പ്രോഗ്രാം ഘടന. ഐഡന്റിഫയറുകൾ. വേരിയബിളുകൾ. ഓപ്പറേറ്റർമാർ. ഏകമാനവും ദ്വിമാനവുമായ അറേകളുടെ പ്രോസസ്സിംഗ്. ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ. സബ്റൂട്ടീനുകൾ. ഡാറ്റ ഫയലുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു.

ഉയർന്ന തലത്തിലുള്ള ഭാഷ- ഒരു പ്രോഗ്രാമിംഗ് ഭാഷ, അതിന്റെ ആശയങ്ങളും ഘടനയും മനുഷ്യന്റെ ധാരണയ്ക്ക് സൗകര്യപ്രദമാണ്.

അൽഗോരിതമിക് ഭാഷ(അൽഗരിഥമിക് ഭാഷ) - ഒരു പ്രോഗ്രാമിംഗ് ഭാഷ - അൽഗോരിതങ്ങൾ എഴുതുന്നതിനായി രൂപകൽപ്പന ചെയ്ത ഒരു കൃത്രിമ (ഔപചാരിക) ഭാഷ. ഒരു പ്രോഗ്രാമിംഗ് ഭാഷയെ അതിന്റെ വിവരണത്താൽ നിർവചിക്കുകയും ഒരു പ്രത്യേക പ്രോഗ്രാമിന്റെ രൂപത്തിൽ നടപ്പിലാക്കുകയും ചെയ്യുന്നു: ഒരു കമ്പൈലർ അല്ലെങ്കിൽ ഇന്റർപ്രെറ്റർ. അൽഗോരിതമിക് ഭാഷകളുടെ ഉദാഹരണങ്ങൾ ബോർലാൻഡ് പാസ്കൽ, സി++, ബേസിക് മുതലായവയാണ്.

അൽഗോരിതം ഭാഷയുടെ അടിസ്ഥാന ആശയങ്ങൾ:

ഭാഷയുടെ ഘടന:

സാധാരണ സംസാരിക്കുന്ന ഭാഷയിൽ നാല് അടിസ്ഥാന ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു: ചിഹ്നങ്ങൾ, വാക്കുകൾ, ശൈലികൾ, വാക്യങ്ങൾ. ഒരു അൽഗോരിതമിക് ഭാഷയിൽ സമാനമായ ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു, വാക്കുകളെ പ്രാഥമിക നിർമ്മാണങ്ങൾ എന്നും വാക്യങ്ങളെ പദപ്രയോഗങ്ങൾ എന്നും വാക്യങ്ങളെ ഓപ്പറേറ്റർമാർ എന്നും വിളിക്കുന്നു.

ചിഹ്നങ്ങൾ, പ്രാഥമിക നിർമ്മിതികൾ, എക്സ്പ്രഷനുകൾ, ഓപ്പറേറ്റർമാർ എന്നിവ ഒരു ശ്രേണിപരമായ ഘടന ഉണ്ടാക്കുന്നു, കാരണം പ്രാഥമിക നിർമ്മാണങ്ങൾ ചിഹ്നങ്ങളുടെ ഒരു ശ്രേണിയിൽ നിന്നാണ് രൂപപ്പെടുന്നത്.

ഭാവങ്ങൾപ്രാഥമിക ഘടനകളുടെയും ചിഹ്നങ്ങളുടെയും ഒരു ശ്രേണിയാണ്,

ഓപ്പറേറ്റർ- പദപ്രയോഗങ്ങൾ, പ്രാഥമിക ഘടനകൾ, ചിഹ്നങ്ങൾ എന്നിവയുടെ ഒരു ശ്രേണി.

ഭാഷാ വിവരണം:

ഭാഷയുടെ സാധുവായ പ്രതീകങ്ങൾ ലിസ്റ്റ് ചെയ്യുന്നതാണ് പ്രതീക വിവരണം. പ്രാഥമിക ഘടനകളുടെ വിവരണം അർത്ഥമാക്കുന്നത് അവയുടെ രൂപീകരണത്തിന്റെ നിയമങ്ങളാണ്. ഒരു പ്രത്യേക ഭാഷയിൽ അർത്ഥമുള്ള ഏതെങ്കിലും പദപ്രയോഗങ്ങളുടെ രൂപീകരണത്തിനുള്ള നിയമങ്ങളാണ് പദപ്രയോഗങ്ങളുടെ വിവരണം. ഓപ്പറേറ്റർമാരുടെ വിവരണത്തിൽ ഭാഷയിൽ അനുവദനീയമായ എല്ലാ തരം ഓപ്പറേറ്റർമാരുടെയും പരിഗണന അടങ്ങിയിരിക്കുന്നു. ഓരോ ഭാഷാ ഘടകത്തിന്റെയും വിവരണം അതിന്റെ SYNTAX ഉം SEMANTICS ഉം ആണ് നൽകിയിരിക്കുന്നത്.

വാക്യഘടനനിർവചനങ്ങൾ ഭാഷാ ഘടകങ്ങൾ നിർമ്മിക്കുന്നതിനുള്ള നിയമങ്ങൾ സ്ഥാപിക്കുന്നു.

അർത്ഥശാസ്ത്രംവാക്യഘടനാപരമായ നിർവചനങ്ങൾ നൽകിയിട്ടുള്ള ഭാഷാ ഘടകങ്ങളുടെ അർത്ഥവും ഉപയോഗ നിയമങ്ങളും നിർവചിക്കുന്നു.

ഭാഷാ ചിഹ്നങ്ങൾ- ഭാഷയിലെ എല്ലാ ഗ്രന്ഥങ്ങളും എഴുതിയതിന്റെ അടിസ്ഥാനത്തിലുള്ള അവിഭാജ്യ അടയാളങ്ങളാണിവ.

പ്രാഥമിക ഘടനകൾ- ഇവ സ്വതന്ത്ര അർത്ഥമുള്ള ഭാഷയുടെ ഏറ്റവും കുറഞ്ഞ യൂണിറ്റുകളാണ്. ഭാഷയുടെ അടിസ്ഥാന ചിഹ്നങ്ങളിൽ നിന്നാണ് അവ രൂപപ്പെടുന്നത്.

എക്സ്പ്രഷൻഒരു അൽഗോരിതം ഭാഷയിൽ, അതിൽ പ്രാഥമിക ഘടനകളും ചിഹ്നങ്ങളും അടങ്ങിയിരിക്കുന്നു; ഒരു നിശ്ചിത മൂല്യം കണക്കാക്കുന്നതിനുള്ള ഒരു നിയമം ഇത് വ്യക്തമാക്കുന്നു.

ഓപ്പറേറ്റർനടപ്പിലാക്കേണ്ട ചില പ്രവർത്തനങ്ങളുടെ പൂർണ്ണമായ വിവരണം വ്യക്തമാക്കുന്നു. ഒരു സങ്കീർണ്ണമായ പ്രവർത്തനം വിവരിക്കാൻ ഒരു കൂട്ടം പ്രസ്താവനകൾ ആവശ്യമായി വന്നേക്കാം.

ഈ സാഹചര്യത്തിൽ, ഓപ്പറേറ്റർമാരെ സംയോജിപ്പിച്ചിരിക്കുന്നു കോമ്പൗണ്ട് ഓപ്പറേറ്റർഅഥവാ തടയുക. പ്രവർത്തനങ്ങൾ, ഓപ്പറേറ്റർമാർ വ്യക്തമാക്കിയ, ഡാറ്റയിൽ എക്സിക്യൂട്ട് ചെയ്യുന്നു. ഡാറ്റ തരങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നൽകുന്ന ഒരു അൽഗോരിതമിക് ഭാഷയുടെ പ്രസ്താവനകളെ ഡിക്ലറേഷനുകൾ അല്ലെങ്കിൽ നോൺ എക്സിക്യൂട്ടബിൾ സ്റ്റേറ്റ്‌മെന്റുകൾ എന്ന് വിളിക്കുന്നു. ഒരു കൂട്ടം വിവരണങ്ങളും ഓപ്പറേറ്റർമാരും ഒരൊറ്റ അൽഗോരിതം സംയോജിപ്പിച്ച് ഒരു അൽഗോരിതം ഭാഷയിൽ ഒരു പ്രോഗ്രാം രൂപീകരിക്കുന്നു. ഒരു അൽഗോരിതം ഭാഷ പഠിക്കുന്ന പ്രക്രിയയിൽ, പഠിക്കുന്ന അൽഗോരിതം ഭാഷയുടെ വിവരണം നടപ്പിലാക്കുന്ന ഭാഷയിൽ നിന്ന് അൽഗോരിതം ഭാഷയെ വേർതിരിച്ചറിയേണ്ടത് ആവശ്യമാണ്. സാധാരണയായി പഠിക്കുന്ന ഭാഷയെ ഒരു ഭാഷ എന്ന് വിളിക്കുന്നു, കൂടാതെ പഠിക്കുന്ന ഭാഷയുടെ വിവരണം നൽകുന്ന ഭാഷയെ - ലോഹഭാഷ.

പരിഭാഷകർ - (ഇംഗ്ലീഷ് വിവർത്തകൻ - വിവർത്തകൻ) ഒരു വിവർത്തക പ്രോഗ്രാമാണ്. ഇത് ഉയർന്ന തലത്തിലുള്ള ഭാഷകളിലൊന്നിൽ എഴുതിയ ഒരു പ്രോഗ്രാമിനെ മെഷീൻ നിർദ്ദേശങ്ങൾ അടങ്ങിയ ഒരു പ്രോഗ്രാമാക്കി മാറ്റുന്നു.

ഏതെങ്കിലും ഉയർന്ന തലത്തിലുള്ള അൽഗോരിതമിക് ഭാഷയിൽ എഴുതിയ ഒരു പ്രോഗ്രാം കമ്പ്യൂട്ടറിൽ നേരിട്ട് പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ല. മെഷീൻ കമാൻഡുകളുടെ ഭാഷ മാത്രമേ കമ്പ്യൂട്ടറിന് മനസ്സിലാകൂ. തൽഫലമായി, ഒരു അൽഗോരിതം ഭാഷയിലുള്ള ഒരു പ്രോഗ്രാം ഒരു നിർദ്ദിഷ്ട കമ്പ്യൂട്ടറിന്റെ കമാൻഡ് ഭാഷയിലേക്ക് വിവർത്തനം ചെയ്യണം (വിവർത്തനം ചെയ്യണം). ഓരോ അൽഗോരിതമിക് ഭാഷയ്ക്കും ഓരോ തരം കമ്പ്യൂട്ടറുകൾക്കും വേണ്ടി സൃഷ്ടിച്ച പ്രത്യേക വിവർത്തക പ്രോഗ്രാമുകളാൽ അത്തരം വിവർത്തനം യാന്ത്രികമായി നടപ്പിലാക്കുന്നു.

രണ്ട് പ്രധാന പ്രക്ഷേപണ രീതികളുണ്ട് - സമാഹാരവും വ്യാഖ്യാനവും.

1. സമാഹാരം: കമ്പൈലർ(ഇംഗ്ലീഷ് കമ്പൈലർ - കംപൈലർ, കളക്ടർ) മുഴുവൻ പ്രോഗ്രാമും വായിക്കുകയും അത് വിവർത്തനം ചെയ്യുകയും മെഷീൻ ഭാഷയിൽ പ്രോഗ്രാമിന്റെ പൂർണ്ണമായ പതിപ്പ് സൃഷ്ടിക്കുകയും ചെയ്യുന്നു, അത് നടപ്പിലാക്കുന്നു.

ചെയ്തത് സമാഹാരംമുഴുവൻ യഥാർത്ഥ പ്രോഗ്രാമും ഉടനടി മെഷീൻ നിർദ്ദേശങ്ങളുടെ ഒരു ശ്രേണിയിലേക്ക് പരിവർത്തനം ചെയ്യപ്പെടുന്നു. ഇതിനുശേഷം, തത്ഫലമായുണ്ടാകുന്ന പ്രോഗ്രാം ലഭ്യമായ ഉറവിട ഡാറ്റയുള്ള ഒരു കമ്പ്യൂട്ടർ ഉപയോഗിച്ച് നടപ്പിലാക്കുന്നു. ഈ രീതിയുടെ പ്രയോജനം, വിവർത്തനം ഒരു തവണ നടത്തുന്നു, തത്ഫലമായുണ്ടാകുന്ന പ്രോഗ്രാമിന്റെ (ഒന്നിലധികം) നിർവ്വഹണം ഉയർന്ന വേഗതയിൽ നടത്താം. അതേ സമയം, തത്ഫലമായുണ്ടാകുന്ന പ്രോഗ്രാമിന് കമ്പ്യൂട്ടറിന്റെ മെമ്മറിയിൽ ധാരാളം ഇടം എടുക്കാൻ കഴിയും, കാരണം വിവർത്തന സമയത്ത് ഒരു ഭാഷാ ഓപ്പറേറ്റർ നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് കമാൻഡുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു. കൂടാതെ, ബ്രോഡ്കാസ്റ്റ് പ്രോഗ്രാമിന്റെ ഡീബഗ്ഗിംഗും പരിഷ്ക്കരണങ്ങളും വളരെ ബുദ്ധിമുട്ടാണ്.

2. വ്യാഖ്യാനം: വ്യാഖ്യാതാവ്(ഇംഗ്ലീഷ് വ്യാഖ്യാതാവ് - വ്യാഖ്യാതാവ്, വ്യാഖ്യാതാവ്) പ്രോഗ്രാം വരി വരിയായി വിവർത്തനം ചെയ്യുകയും നടപ്പിലാക്കുകയും ചെയ്യുന്നു.

ചെയ്തത് വ്യാഖ്യാനങ്ങൾയഥാർത്ഥ പ്രോഗ്രാം കമ്പ്യൂട്ടർ മെമ്മറിയിൽ ഏതാണ്ട് മാറ്റമില്ലാതെ സംഭരിച്ചിരിക്കുന്നു. ഇന്റർപ്രെറ്റർ പ്രോഗ്രാം സോഴ്‌സ് പ്രോഗ്രാമിന്റെ പ്രസ്താവനകൾ ഒരു സമയം ഡീകോഡ് ചെയ്യുകയും ലഭ്യമായ ഡാറ്റ ഉപയോഗിച്ച് അവയുടെ നിർവ്വഹണം ഉടനടി ഉറപ്പാക്കുകയും ചെയ്യുന്നു. വ്യാഖ്യാനിച്ച പ്രോഗ്രാം കമ്പ്യൂട്ടറിന്റെ മെമ്മറിയിൽ കുറച്ച് ഇടം മാത്രമേ എടുക്കൂ, ഡീബഗ് ചെയ്യാനും പരിഷ്കരിക്കാനും എളുപ്പമാണ്. എന്നാൽ പ്രോഗ്രാമിന്റെ നിർവ്വഹണം വളരെ മന്ദഗതിയിലാണ്, കാരണം ഓരോ നിർവ്വഹണത്തിലും എല്ലാ ഓപ്പറേറ്റർമാരുടെയും വ്യാഖ്യാനം പുതുതായി നടപ്പിലാക്കുന്നു.

സമാഹരിച്ച പ്രോഗ്രാമുകൾ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു, എന്നാൽ വ്യാഖ്യാനിച്ചവ പരിഹരിക്കാനും മാറ്റാനും എളുപ്പമാണ്.

ഓരോ നിർദ്ദിഷ്‌ട ഭാഷയും ഒന്നുകിൽ സമാഹരിക്കുന്നതിനോ വ്യാഖ്യാനിക്കുന്നതിനോ ആണ് - അത് സൃഷ്ടിച്ച ഉദ്ദേശ്യത്തെ ആശ്രയിച്ച്. ഉദാഹരണത്തിന്, പ്രോഗ്രാമിന്റെ വേഗത പ്രാധാന്യമുള്ള സങ്കീർണ്ണമായ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ സാധാരണയായി പാസ്കൽ ഉപയോഗിക്കുന്നു. അതിനാൽ, ഈ ഭാഷ സാധാരണയായി ഒരു കമ്പൈലർ ഉപയോഗിച്ചാണ് നടപ്പിലാക്കുന്നത്.

മറുവശത്ത്, പുതിയ പ്രോഗ്രാമർമാർക്കായുള്ള ഒരു ഭാഷയായാണ് ബേസിക് സൃഷ്ടിക്കപ്പെട്ടത്, അവർക്ക് ഒരു പ്രോഗ്രാമിന്റെ വരി-ബൈ-ലൈൻ നിർവ്വഹണത്തിന് നിഷേധിക്കാനാവാത്ത നേട്ടങ്ങളുണ്ട്.

ചിലപ്പോൾ ഒരേ ഭാഷയ്ക്ക് കംപൈലറും ഇന്റർപ്രെറ്ററും ഉണ്ടാകും. ഈ സാഹചര്യത്തിൽ, പ്രോഗ്രാം വികസിപ്പിക്കുന്നതിനും പരിശോധിക്കുന്നതിനും നിങ്ങൾക്ക് ഒരു വ്യാഖ്യാതാവ് ഉപയോഗിക്കാം, തുടർന്ന് അതിന്റെ എക്സിക്യൂഷൻ വേഗത മെച്ചപ്പെടുത്തുന്നതിന് ഡീബഗ്ഗ് ചെയ്ത പ്രോഗ്രാം കംപൈൽ ചെയ്യുക.

• വിവർത്തനം

വിവർത്തകന്റെ കുറിപ്പ്: ലേഖനം വളരെ പഴയതാണെങ്കിലും (2 വർഷം മുമ്പ് പ്രസിദ്ധീകരിച്ചത്) ഉച്ചത്തിലുള്ള തലക്കെട്ട് ഉണ്ടെങ്കിലും, റിലേഷണൽ ഡാറ്റാബേസുകളും NoSQL ഡാറ്റാബേസുകളും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ, അവയുടെ ഗുണങ്ങളും ദോഷങ്ങളും എന്നിവയെക്കുറിച്ച് ഇത് ഇപ്പോഴും നല്ല ആശയം നൽകുന്നു, കൂടാതെ ഒരു ഹ്രസ്വ അവലോകനവും നൽകുന്നു. ബന്ധമില്ലാത്ത സ്റ്റോറേജുകളുടെ.

അടുത്തിടെ, ബന്ധമില്ലാത്ത നിരവധി ഡാറ്റാബേസുകൾ പ്രത്യക്ഷപ്പെട്ടു. നിങ്ങൾക്ക് വെർച്വലി അൺലിമിറ്റഡ് ഓൺ-ഡിമാൻഡ് സ്കേലബിളിറ്റി ആവശ്യമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരു നോൺ-റിലേഷണൽ ഡാറ്റാബേസ് ആവശ്യമാണെന്ന് ഇത് സൂചിപ്പിക്കുന്നു.

ഇത് ശരിയാണെങ്കിൽ, ശക്തമായ റിലേഷണൽ ഡാറ്റാബേസ് ദുർബലമായിത്തീർന്നുവെന്നാണോ ഇതിനർത്ഥം? ഇതിനർത്ഥം റിലേഷണൽ ഡാറ്റാബേസുകളുടെ നാളുകൾ കടന്നുപോകുകയാണെന്നും ഉടൻ തന്നെ പൂർണ്ണമായും ഇല്ലാതാകുമെന്നും? ഈ ലേഖനത്തിൽ, വ്യത്യസ്ത സാഹചര്യങ്ങൾക്ക് ബാധകമായതിനാൽ ഞങ്ങൾ ജനപ്രിയ നോൺ-റിലേഷണൽ ഡാറ്റാബേസ് പ്രസ്ഥാനത്തിലേക്ക് നോക്കും കൂടാതെ അത് റിലേഷണൽ ഡാറ്റാബേസുകളുടെ ഭാവിയെ ബാധിക്കുമോ എന്ന് നോക്കാം.

റിലേഷണൽ ഡാറ്റാബേസുകൾ ഏകദേശം 30 വർഷമായി നിലവിലുണ്ട്. ഈ സമയത്ത്, റിലേഷണൽ സ്റ്റോറേജ് അവസാനിപ്പിക്കുന്ന നിരവധി വിപ്ലവങ്ങൾ പൊട്ടിപ്പുറപ്പെട്ടു. തീർച്ചയായും, ഈ വിപ്ലവങ്ങളൊന്നും നടന്നില്ല, അവയൊന്നും റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സ്ഥാനത്തെ ഒരു അയോട്ട കുലുക്കിയില്ല.

നമുക്ക് അടിസ്ഥാനകാര്യങ്ങളിൽ നിന്ന് ആരംഭിക്കാം

ഒരു റിലേഷണൽ ഡാറ്റാബേസ് എന്നത് പട്ടികകളുടെ (എന്റിറ്റികൾ) ഒരു കൂട്ടമാണ്. പട്ടികകളിൽ നിരകളും വരികളും (ട്യൂപ്പിൾസ്) അടങ്ങിയിരിക്കുന്നു. പട്ടികകൾക്കിടയിൽ നിയന്ത്രണങ്ങൾ നിർവചിക്കാം, കൂടാതെ പട്ടികകൾക്കിടയിൽ ബന്ധങ്ങൾ നിലവിലുണ്ട്. SQL ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഒന്നോ അതിലധികമോ പട്ടികകളിൽ നിന്ന് ഡാറ്റയുടെ സെറ്റുകൾ നൽകുന്ന അന്വേഷണങ്ങൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയും. ഒരു ചോദ്യത്തിനുള്ളിൽ, അവയിൽ ചേരുന്നതിലൂടെ (JOIN) നിരവധി പട്ടികകളിൽ നിന്ന് ഡാറ്റ ലഭിക്കുന്നു, മിക്കപ്പോഴും ടേബിളുകൾ തമ്മിലുള്ള ബന്ധത്തെ നിർവചിക്കുന്ന അതേ നിരകൾ തന്നെ കണക്ഷനും ഉപയോഗിക്കുന്നു. ഡാറ്റയിലെ യോജിപ്പും ആവർത്തനത്തിന്റെ അഭാവവും ഉറപ്പാക്കാൻ ഒരു ഡാറ്റ മോഡൽ രൂപപ്പെടുത്തുന്ന പ്രക്രിയയാണ് നോർമലൈസേഷൻ.

റിലേഷണൽ ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റങ്ങൾ (RDBMS) വഴിയാണ് റിലേഷണൽ ഡാറ്റാബേസുകൾ ആക്സസ് ചെയ്യുന്നത്. ഒറാക്കിൾ, SQL സെർവർ, MySQL, Sybase, DB2, TeraData തുടങ്ങി ഞങ്ങൾ ഉപയോഗിക്കുന്ന മിക്കവാറും എല്ലാ ഡാറ്റാബേസ് സിസ്റ്റങ്ങളും റിലേഷണൽ ആണ്.

ഈ ആധിപത്യത്തിന്റെ കാരണങ്ങൾ വ്യക്തമല്ല. റിലേഷണൽ ഡാറ്റാബേസുകളുടെ ചരിത്രത്തിലുടനീളം, ഡാറ്റാ മാനേജ്‌മെന്റിലെ ലാളിത്യം, കരുത്ത്, വഴക്കം, പ്രകടനം, സ്കേലബിളിറ്റി, അനുയോജ്യത എന്നിവയുടെ മികച്ച സംയോജനം അവർ സ്ഥിരമായി വാഗ്ദാനം ചെയ്തിട്ടുണ്ട്.

എന്നിരുന്നാലും, ഈ സവിശേഷതകളെല്ലാം നൽകുന്നതിന്, റിലേഷണൽ സ്റ്റോറുകൾ അവിശ്വസനീയമാംവിധം സങ്കീർണ്ണമാണ്. ഉദാഹരണത്തിന്, ഒരു ലളിതമായ SELECT ചോദ്യത്തിന് നൂറുകണക്കിന് സാധ്യതയുള്ള നിർവ്വഹണ പാതകൾ ഉണ്ടായിരിക്കാം, അത് ഒപ്റ്റിമൈസർ ക്വറി എക്സിക്യൂഷൻ സമയത്ത് നേരിട്ട് വിലയിരുത്തും. ഇതെല്ലാം ഉപയോക്താക്കളിൽ നിന്ന് മറച്ചിരിക്കുന്നു, എന്നാൽ ആന്തരികമായി RDBMS, ചോദ്യം മികച്ച രീതിയിൽ നിറവേറ്റുന്നതിന് ചെലവ് കണക്കാക്കൽ അൽഗോരിതം പോലുള്ള കാര്യങ്ങളെ അടിസ്ഥാനമാക്കി ഒരു എക്സിക്യൂഷൻ പ്ലാൻ സൃഷ്ടിക്കുന്നു.

റിലേഷണൽ ഡാറ്റാബേസ് പ്രശ്നങ്ങൾ

റിലേഷണൽ സ്റ്റോറുകൾ ലാളിത്യം, ദൃഢത, വഴക്കം, പ്രകടനം, സ്കേലബിളിറ്റി, അനുയോജ്യത എന്നിവയുടെ മികച്ച സംയോജനം നൽകുമ്പോൾ, ഒരൊറ്റ സവിശേഷതയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന താരതമ്യപ്പെടുത്താവുന്ന സിസ്റ്റങ്ങളെ അപേക്ഷിച്ച് ഈ ഓരോ പോയിന്റുകളിലും അവ മികച്ച പ്രകടനം കാഴ്ചവയ്ക്കണമെന്നില്ല. ഇതൊരു വലിയ പ്രശ്നമായിരുന്നില്ല, കാരണം റിലേഷണൽ ഡിബിഎംഎസുകളുടെ മൊത്തത്തിലുള്ള ആധിപത്യം എല്ലാ പോരായ്മകളെയും മറികടക്കുന്നു. എന്നിരുന്നാലും, പരമ്പരാഗത ആർ‌ഡി‌ബികൾ ആവശ്യങ്ങൾ നിറവേറ്റുന്നില്ലെങ്കിൽ, എല്ലായ്‌പ്പോഴും ബദലുകൾ ഉണ്ടായിരുന്നു.

ഇന്ന് സ്ഥിതി അല്പം വ്യത്യസ്തമാണ്. വൈവിധ്യമാർന്ന ആപ്ലിക്കേഷനുകൾ വളരുകയാണ്, അതോടൊപ്പം ഈ സവിശേഷതകളുടെ പ്രാധാന്യം വർദ്ധിക്കുന്നു. ഡാറ്റാബേസുകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച്, ഒരു സവിശേഷത മറ്റെല്ലാറ്റിനേക്കാളും തിളങ്ങാൻ തുടങ്ങുന്നു. ഇത് സ്കേലബിളിറ്റിയാണ്. വെബ് സേവനങ്ങൾ പോലുള്ള ഉയർന്ന ലോഡിൽ കൂടുതൽ ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിക്കുന്നതിനാൽ, അവയുടെ സ്കേലബിളിറ്റി ആവശ്യകതകൾ വളരെ വേഗത്തിൽ മാറുകയും വളരുകയും ചെയ്യും. നിങ്ങളുടെ സ്വന്തം സെർവറിൽ ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ഉണ്ടെങ്കിൽ ആദ്യത്തെ പ്രശ്നം പരിഹരിക്കാൻ വളരെ ബുദ്ധിമുട്ടായിരിക്കും. ഒറ്റരാത്രികൊണ്ട് സെർവർ ലോഡ് മൂന്നിരട്ടിയാകുമെന്ന് നമുക്ക് പറയാം. നിങ്ങളുടെ ഹാർഡ്‌വെയർ എത്ര വേഗത്തിൽ അപ്‌ഗ്രേഡ് ചെയ്യാം? രണ്ടാമത്തെ പ്രശ്നം പരിഹരിക്കുന്നത് റിലേഷണൽ ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുമ്പോൾ ബുദ്ധിമുട്ടുകൾ ഉണ്ടാക്കുന്നു.

റിലേഷണൽ ഡാറ്റാബേസുകൾ ഒരൊറ്റ സെർവറിലാണെങ്കിൽ മാത്രമേ അവ നന്നായി സ്കെയിൽ ചെയ്യപ്പെടുകയുള്ളൂ. ഈ സെർവറിന്റെ ഉറവിടങ്ങൾ തീരുമ്പോൾ, നിങ്ങൾ കൂടുതൽ മെഷീനുകൾ ചേർക്കുകയും അവയ്ക്കിടയിൽ ലോഡ് വിതരണം ചെയ്യുകയും വേണം. ഇവിടെയാണ് റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സങ്കീർണ്ണത സ്കേലബിലിറ്റിക്കെതിരെ കളിക്കാൻ തുടങ്ങുന്നത്. നിങ്ങൾ സെർവറുകളുടെ എണ്ണം കുറച്ച് മാത്രമല്ല, നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് വർദ്ധിപ്പിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, സങ്കീർണ്ണത ഒരു ക്രമത്തിൽ വർദ്ധിക്കും, കൂടാതെ റിലേഷണൽ ഡാറ്റാബേസുകളെ വളരെ ആകർഷകമാക്കുന്ന സ്വഭാവസവിശേഷതകൾ അവയെ ഒരു പ്ലാറ്റ്ഫോമായി ഉപയോഗിക്കാനുള്ള സാധ്യത കുറയ്ക്കുന്നു. വലിയ വിതരണ സംവിധാനങ്ങൾ പൂജ്യത്തിലേക്ക്.

മത്സരാധിഷ്ഠിതമായി തുടരാൻ, ക്ലൗഡ് സർവീസ് വെണ്ടർമാർ ഈ പരിമിതിയെ എങ്ങനെയെങ്കിലും കൈകാര്യം ചെയ്യണം, കാരണം സ്കെയിലബിൾ ഡാറ്റ സ്റ്റോറേജ് ഇല്ലാതെ ഇത് ഏത് തരത്തിലുള്ള ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമാണ്. ഉപയോക്താക്കൾക്ക് സ്കെയിലബിൾ സ്റ്റോറേജ് സ്പേസ് നൽകണമെങ്കിൽ വെണ്ടർമാർക്ക് ഒരു ഓപ്ഷൻ മാത്രമേ നൽകൂ. റിലേഷണൽ ഡാറ്റാബേസുകളിൽ ലഭ്യമായ മറ്റ് ഫീച്ചറുകളുടെ വിലയാണെങ്കിലും ഉയർന്ന സ്കേലബിളിറ്റി ഉള്ള മറ്റ് തരത്തിലുള്ള ഡാറ്റാബേസുകൾ ഉപയോഗിക്കേണ്ടത് ആവശ്യമാണ്.

ഈ ആനുകൂല്യങ്ങളും അവയ്‌ക്കുള്ള നിലവിലുള്ള ഡിമാൻഡും പുതിയ ഡാറ്റാബേസ് മാനേജ്‌മെന്റ് സിസ്റ്റങ്ങളുടെ തരംഗത്തിലേക്ക് നയിച്ചു.

പുതിയ തരംഗം

ഇത്തരത്തിലുള്ള ഡാറ്റാബേസിനെ സാധാരണയായി കീ-വാല്യൂ സ്റ്റോർ എന്ന് വിളിക്കുന്നു. യഥാർത്ഥത്തിൽ, ഔദ്യോഗിക നാമം ഒന്നുമില്ല, അതിനാൽ ഡോക്യുമെന്റ്-ഓറിയന്റഡ്, ആട്രിബ്യൂട്ട്-ഓറിയന്റഡ്, ഡിസ്ട്രിബ്യൂട്ടഡ് ഡാറ്റാബേസുകൾ (അവ റിലേഷണൽ ആയിരിക്കാം), ഷാർഡ് സോർട്ടഡ് അറേകൾ, ഡിസ്ട്രിബ്യൂഡ് ഹാഷ് ടേബിളുകൾ, സ്റ്റോറേജ് കീ-വാല്യൂ എന്നിവയുടെ പശ്ചാത്തലത്തിൽ നിങ്ങൾക്കത് കാണാനാകും. തരം. ഈ പേരുകൾ ഓരോന്നും സിസ്റ്റത്തിന്റെ പ്രത്യേക സവിശേഷതകളെ സൂചിപ്പിക്കുന്നുവെങ്കിലും, അവയെല്ലാം ഒരു തീമിലെ വ്യതിയാനങ്ങളാണ്, ഞങ്ങൾ കീ-വാല്യൂ സ്റ്റോറേജ് എന്ന് വിളിക്കും.

എന്നിരുന്നാലും, നിങ്ങൾ അതിനെ എന്ത് വിളിച്ചാലും, ഈ "പുതിയ" തരം ഡാറ്റാബേസ് അത്ര പുതിയതല്ല മാത്രമല്ല എല്ലായ്പ്പോഴും പ്രധാനമായും റിലേഷണൽ ഡാറ്റാബേസുകളുടെ ഉപയോഗം അനുയോജ്യമല്ലാത്ത ആപ്ലിക്കേഷനുകൾക്കായി ഉപയോഗിക്കുന്നു. എന്നിരുന്നാലും, സ്കേലബിലിറ്റിക്കായി വെബിന്റെയും ക്ലൗഡിന്റെയും ആവശ്യമില്ലാതെ, ഈ സിസ്റ്റങ്ങൾക്ക് ആവശ്യക്കാർ കുറവായിരുന്നു. ഒരു പ്രത്യേക സിസ്റ്റത്തിന് ഏറ്റവും അനുയോജ്യമായ സ്റ്റോറേജ് ഏത് തരത്തിലുള്ളതാണെന്ന് നിർണ്ണയിക്കുക എന്നതാണ് ഇപ്പോൾ വെല്ലുവിളി.
റിലേഷണൽ ഡാറ്റാബേസുകളും കീ-വാല്യൂ സ്റ്റോറുകളും അടിസ്ഥാനപരമായി വ്യത്യസ്തവും വ്യത്യസ്ത പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതുമാണ്. സ്വഭാവസവിശേഷതകൾ താരതമ്യം ചെയ്യുന്നത് അവ തമ്മിലുള്ള വ്യത്യാസം മനസ്സിലാക്കാൻ മാത്രമേ നിങ്ങളെ അനുവദിക്കൂ, എന്നാൽ നമുക്ക് ഇതിൽ നിന്ന് ആരംഭിക്കാം:

സംഭരണത്തിന്റെ സവിശേഷതകൾ

റിലേഷണൽ ഡാറ്റാബേസ്	പ്രധാന മൂല്യമുള്ള സ്റ്റോർ
ഒരു ഡാറ്റാബേസിൽ പട്ടികകൾ അടങ്ങിയിരിക്കുന്നു, പട്ടികകളിൽ നിരകളും വരികളും അടങ്ങിയിരിക്കുന്നു, വരികളിൽ കോളം മൂല്യങ്ങളും അടങ്ങിയിരിക്കുന്നു. ഒരു പട്ടികയുടെ എല്ലാ വരികൾക്കും ഒരേ ഘടനയുണ്ട്.	ഡൊമെയ്‌നുകൾക്കായി, പട്ടികകൾ ഉപയോഗിച്ച് ഒരു സാമ്യം വരയ്ക്കാം, എന്നാൽ പട്ടികകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഡൊമെയ്‌നുകൾക്കായുള്ള ഡാറ്റാ ഘടന നിർവചിച്ചിട്ടില്ല. ഒരു ഡൊമെയ്ൻ ഒരു ബോക്സാണ്, അതിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ളതെന്തും ഇടാം. ഒരേ ഡൊമെയ്‌നിലെ റെക്കോർഡുകൾക്ക് വ്യത്യസ്ത ഘടനകൾ ഉണ്ടായിരിക്കാം.
ഡാറ്റ മോഡൽ 1 മുൻകൂട്ടി നിശ്ചയിച്ചിരിക്കുന്നു. ഇത് ശക്തമായി ടൈപ്പ് ചെയ്‌തിരിക്കുന്നു കൂടാതെ ഡാറ്റാ സമഗ്രത ഉറപ്പാക്കുന്നതിനുള്ള നിയന്ത്രണങ്ങളും ബന്ധങ്ങളും അടങ്ങിയിരിക്കുന്നു.	ഒരു കീ ഉപയോഗിച്ച് റെക്കോർഡുകൾ തിരിച്ചറിയുന്നു, ഓരോ റെക്കോർഡിനും അതുമായി ബന്ധപ്പെട്ട ഒരു ഡൈനാമിക് ആട്രിബ്യൂട്ടുകൾ ഉണ്ട്.
ആപ്ലിക്കേഷന്റെ പ്രവർത്തനക്ഷമതയെക്കാളുപരി, അടങ്ങിയിരിക്കുന്ന ഡാറ്റയുടെ സ്വാഭാവിക പ്രതിനിധാനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഡാറ്റ മോഡൽ.	ചില നിർവ്വഹണങ്ങളിൽ, ആട്രിബ്യൂട്ടുകൾ സ്ട്രിംഗുകൾ മാത്രമായിരിക്കും. മറ്റ് നടപ്പിലാക്കലുകളിൽ, ആട്രിബ്യൂട്ടുകൾക്ക് പ്രോഗ്രാമിംഗിൽ ഉപയോഗിക്കുന്ന തരങ്ങളെ പ്രതിഫലിപ്പിക്കുന്ന ലളിതമായ ഡാറ്റ തരങ്ങളുണ്ട്: പൂർണ്ണസംഖ്യകൾ, സ്ട്രിംഗ് അറേകൾ, ലിസ്റ്റുകൾ.
ഡാറ്റ ഡ്യൂപ്ലിക്കേഷൻ ഒഴിവാക്കാൻ ഡാറ്റ മോഡൽ നോർമലൈസ് ചെയ്തിരിക്കുന്നു. നോർമലൈസേഷൻ പട്ടികകൾ തമ്മിലുള്ള ബന്ധം സൃഷ്ടിക്കുന്നു. ബന്ധങ്ങൾ വ്യത്യസ്ത പട്ടികകളിൽ നിന്നുള്ള ഡാറ്റയെ ബന്ധിപ്പിക്കുന്നു.	ഡൊമെയ്‌നുകൾക്കിടയിലും ഒരു ഡൊമെയ്‌നിനുള്ളിലും, ബന്ധങ്ങൾ വ്യക്തമായി നിർവചിച്ചിട്ടില്ല.

ചേരുന്നില്ല

പ്രധാന മൂല്യമുള്ള സ്റ്റോറുകൾ റെക്കോർഡ് ഓറിയന്റഡ് ആണ്. നൽകിയിരിക്കുന്ന രേഖയുമായി ബന്ധപ്പെട്ട എല്ലാ വിവരങ്ങളും അതിൽ സംഭരിച്ചിരിക്കുന്നു എന്നാണ് ഇതിനർത്ഥം. ഒരു ഡൊമെയ്‌നിൽ (നിങ്ങൾക്ക് ഒരു പട്ടികയായി കരുതാം) എണ്ണമറ്റ വ്യത്യസ്ത എൻട്രികൾ അടങ്ങിയിരിക്കാം. ഉദാഹരണത്തിന്, ഒരു ഡൊമെയ്‌നിൽ ഉപഭോക്താക്കളെയും ഓർഡറുകളെയും കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കാം. വ്യത്യസ്ത ഡൊമെയ്‌നുകൾക്കിടയിൽ ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടുമെന്നാണ് ഇതിനർത്ഥം. ഡിസ്ക് സ്പേസ് വിലകുറഞ്ഞതിനാൽ ഇത് സ്വീകാര്യമായ ഒരു സമീപനമാണ്. പ്രധാന കാര്യം, ബന്ധപ്പെട്ട എല്ലാ ഡാറ്റയും ഒരിടത്ത് സംഭരിക്കുന്നതിന് ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, ഇത് വ്യത്യസ്ത പട്ടികകളിൽ നിന്ന് ഡാറ്റ ചേരേണ്ട ആവശ്യമില്ലാത്തതിനാൽ സ്കേലബിളിറ്റി മെച്ചപ്പെടുത്തുന്നു. ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ഉപയോഗിക്കുമ്പോൾ, ആവശ്യമായ വിവരങ്ങൾ ഒരിടത്ത് ഗ്രൂപ്പുചെയ്യുന്നതിന് ജോയിൻസ് ഉപയോഗിക്കേണ്ടത് ആവശ്യമാണ്.

കീ-വാല്യൂ ജോഡികൾ സംഭരിക്കുന്നതിനുള്ള ബന്ധങ്ങളുടെ ആവശ്യകത കുത്തനെ കുറയുന്നുണ്ടെങ്കിലും, ബന്ധങ്ങൾ ഇപ്പോഴും ആവശ്യമാണ്. അത്തരം ബന്ധങ്ങൾ സാധാരണയായി അണ്ടർലയിങ്ങ് എന്റിറ്റികൾക്കിടയിൽ നിലവിലുണ്ട്. ഉദാഹരണത്തിന്, ഒരു ഓർഡറിംഗ് സിസ്റ്റത്തിന് ഉപഭോക്താക്കൾ, ഉൽപ്പന്നങ്ങൾ, ഓർഡറുകൾ എന്നിവയെക്കുറിച്ചുള്ള ഡാറ്റ അടങ്ങിയിരിക്കുന്ന റെക്കോർഡുകൾ ഉണ്ടായിരിക്കും. ഈ ഡാറ്റ ഒരു ഡൊമെയ്‌നിലോ പലതിലോ ഉള്ളതാണോ എന്നത് പ്രശ്നമല്ല. ഉപഭോക്താവ് ഒരു ഓർഡർ നൽകുമ്പോൾ, ഉപഭോക്താവിനെയും ഓർഡർ വിവരങ്ങളെയും ഒരേ റെക്കോർഡിൽ സൂക്ഷിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല എന്നതാണ് ഏറ്റവും പ്രധാന കാര്യം.
പകരം, ഓർഡർ റെക്കോർഡിൽ അനുബന്ധ ഉപഭോക്താവിലേക്കും ഉൽപ്പന്ന റെക്കോർഡുകളിലേക്കും ചൂണ്ടിക്കാണിക്കുന്ന കീകൾ അടങ്ങിയിരിക്കണം. റെക്കോർഡുകൾക്ക് ഏത് വിവരവും സംഭരിക്കാൻ കഴിയുന്നതിനാൽ, ഡാറ്റ മോഡലിൽ തന്നെ ബന്ധങ്ങൾ നിർവചിക്കപ്പെടാത്തതിനാൽ, ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റത്തിന് ബന്ധങ്ങളുടെ സമഗ്രത പരിശോധിക്കാൻ കഴിയില്ല. ഉപഭോക്താക്കളെയും അവർ ഓർഡർ ചെയ്ത ഉൽപ്പന്നങ്ങളെയും നിങ്ങൾക്ക് ഇല്ലാതാക്കാം എന്നാണ് ഇതിനർത്ഥം. ഡാറ്റയുടെ സമഗ്രത പൂർണ്ണമായും ആപ്ലിക്കേഷനിൽ പതിക്കുന്നു.

ഡാറ്റ ആക്സസ്

റിലേഷണൽ ഡാറ്റാബേസ്	പ്രധാന മൂല്യമുള്ള സ്റ്റോർ
സ്ട്രക്ചർഡ് ക്വറി ലാംഗ്വേജ് (എസ്‌ക്യുഎൽ) ഉപയോഗിച്ച് ഡാറ്റ സൃഷ്‌ടിക്കുകയും അപ്‌ഡേറ്റ് ചെയ്യുകയും ഇല്ലാതാക്കുകയും അന്വേഷിക്കുകയും ചെയ്യുന്നു.	API രീതി കോളുകൾ ഉപയോഗിച്ച് ഡാറ്റ സൃഷ്‌ടിക്കുകയും അപ്‌ഡേറ്റ് ചെയ്യുകയും ഇല്ലാതാക്കുകയും അന്വേഷിക്കുകയും ചെയ്യുന്നു.
SQL അന്വേഷണങ്ങൾക്ക് ഒരു ടേബിളിൽ നിന്നോ ഒന്നിലധികം ടേബിളുകളിൽ നിന്നോ ജോയിൻസ് ഉപയോഗിച്ച് ഡാറ്റ വീണ്ടെടുക്കാൻ കഴിയും.	ചില നിർവ്വഹണങ്ങൾ ഫിൽട്ടർ വ്യവസ്ഥകൾ വ്യക്തമാക്കുന്നതിന് SQL പോലെയുള്ള വാക്യഘടന നൽകുന്നു.
SQL അന്വേഷണങ്ങളിൽ അഗ്രഗേഷനുകളും സങ്കീർണ്ണമായ ഫിൽട്ടറുകളും ഉൾപ്പെടാം.	പലപ്പോഴും നിങ്ങൾക്ക് അടിസ്ഥാന താരതമ്യ ഓപ്പറേറ്ററുകൾ മാത്രമേ ഉപയോഗിക്കാൻ കഴിയൂ (=, !=,<, >, <= и =>).
ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ സാധാരണയായി ട്രിഗറുകൾ, സംഭരിച്ച നടപടിക്രമങ്ങൾ, ഫംഗ്‌ഷനുകൾ എന്നിവ പോലുള്ള ബിൽറ്റ്-ഇൻ ലോജിക് അടങ്ങിയിരിക്കുന്നു.	എല്ലാ ബിസിനസ്സ്, ഡാറ്റ ഇന്റഗ്രിറ്റി ലോജിക്കും ആപ്ലിക്കേഷൻ കോഡിൽ അടങ്ങിയിരിക്കുന്നു.

ആപ്ലിക്കേഷനുകളുമായുള്ള ഇടപെടൽ

പ്രധാന മൂല്യമുള്ള സ്റ്റോറുകൾ: ആനുകൂല്യങ്ങൾ

റിലേഷണൽ സ്റ്റോറുകളെ അപേക്ഷിച്ച് അത്തരം സംവിധാനങ്ങൾക്ക് രണ്ട് വ്യക്തമായ ഗുണങ്ങളുണ്ട്.

ക്ലൗഡ് സേവനങ്ങൾക്ക് അനുയോജ്യം

കീ-വാല്യൂ സ്റ്റോറുകളുടെ ആദ്യ നേട്ടം, അവ റിലേഷണൽ ഡാറ്റാബേസുകളേക്കാൾ ലളിതവും അതിനാൽ കൂടുതൽ അളക്കാവുന്നതുമാണ്. നിങ്ങൾ നിങ്ങളുടെ സ്വന്തം സിസ്റ്റം സഹ-ഹോസ്‌റ്റുചെയ്യുകയാണെങ്കിൽ, നിങ്ങളുടെ ഡാറ്റ സ്റ്റോറിനു പിന്നിൽ വർദ്ധിച്ചുവരുന്ന ലോഡുകൾ കൈകാര്യം ചെയ്യേണ്ട ഒരു ഡസനോ നൂറോ സെർവറുകൾ സ്ഥാപിക്കാൻ പദ്ധതിയിടുകയാണെങ്കിൽ, കീ-വാല്യൂ സ്റ്റോറുകൾ നിങ്ങളുടെ തിരഞ്ഞെടുപ്പാണ്.

അത്തരം സംഭരണം എളുപ്പത്തിലും ചലനാത്മകമായും വികസിപ്പിക്കാൻ കഴിയുന്നതിനാൽ, മൾട്ടി-ടെനന്റ് വെബ് അധിഷ്ഠിത സ്റ്റോറേജ് പ്ലാറ്റ്ഫോം നൽകുന്ന വെണ്ടർമാർക്കും ഇത് ഉപയോഗപ്രദമാണ്. അത്തരം ഒരു ഡാറ്റാബേസ് വലിയ സ്കേലബിളിറ്റി സാധ്യതയുള്ള ഡാറ്റ സംഭരണത്തിന്റെ താരതമ്യേന വിലകുറഞ്ഞ മാർഗത്തെ പ്രതിനിധീകരിക്കുന്നു. ഉപയോക്താക്കൾ സാധാരണയായി അവർ ഉപയോഗിക്കുന്നതിന് മാത്രമേ പണം നൽകൂ, എന്നാൽ അവരുടെ ആവശ്യങ്ങൾ വർദ്ധിച്ചേക്കാം. വിതരണക്കാരന് ചലനാത്മകമായും പ്രായോഗികമായും നിയന്ത്രണങ്ങളില്ലാതെ ലോഡിനെ അടിസ്ഥാനമാക്കി പ്ലാറ്റ്‌ഫോമിന്റെ വലുപ്പം വർദ്ധിപ്പിക്കാൻ കഴിയും.

കോഡുമായി കൂടുതൽ സ്വാഭാവിക സംയോജനം

റിലേഷണൽ ഡാറ്റ മോഡലും കോഡ് ഒബ്‌ജക്റ്റ് മോഡലും സാധാരണയായി വ്യത്യസ്തമായി നിർമ്മിക്കപ്പെടുന്നു, ഇത് ചില പൊരുത്തക്കേടുകളിലേക്ക് നയിക്കുന്നു. റിലേഷണൽ മോഡലിനെ ഒബ്ജക്റ്റ് മോഡലിലേക്ക് മാപ്പ് ചെയ്യുന്ന കോഡ് എഴുതി ഡെവലപ്പർമാർ ഈ പ്രശ്നം പരിഹരിക്കുന്നു. ഈ പ്രക്രിയയ്‌ക്ക് വ്യക്തവും വേഗത്തിലുള്ളതുമായ മൂല്യമില്ല, മാത്രമല്ല ആപ്ലിക്കേഷൻ വികസിപ്പിക്കുന്നതിന് ചെലവഴിക്കാൻ കഴിയുന്ന ഗണ്യമായ സമയമെടുക്കുകയും ചെയ്യും. അതേസമയം, ഒബ്‌ജക്‌റ്റുകളിലേക്ക് കൂടുതൽ സ്വാഭാവികമായി മാപ്പ് ചെയ്യുന്ന ഒരു ഘടനയിൽ പല കീ-വാല്യൂ സ്റ്റോറുകളും ഡാറ്റ സംഭരിക്കുന്നു. ഇത് വികസന സമയം ഗണ്യമായി കുറയ്ക്കും.

കീ-വാല്യൂ സ്റ്റോറുകൾ ഉപയോഗിക്കുന്നതിനുള്ള മറ്റ് വാദഗതികൾ, "റിലേഷണൽ ഡാറ്റാബേസുകൾക്ക് കുഴപ്പമുണ്ടാകാം" (അതിന്റെ അർത്ഥമെന്താണെന്ന് എനിക്കറിയില്ല), അത്ര നിർബന്ധിതമല്ല. എന്നാൽ അത്തരം സംഭരണത്തിനായി നിങ്ങൾ ഒരു വക്താവാകുന്നതിന് മുമ്പ്, അടുത്ത ഭാഗം വായിക്കുക.

പ്രധാന മൂല്യമുള്ള സ്റ്റോറുകൾ: ദോഷങ്ങൾ

റിലേഷണൽ ഡാറ്റാബേസുകളിലെ നിയന്ത്രണങ്ങൾ ഏറ്റവും താഴ്ന്ന തലത്തിൽ ഡാറ്റയുടെ സമഗ്രത ഉറപ്പാക്കുന്നു. നിയന്ത്രണങ്ങൾ പാലിക്കാത്ത ഡാറ്റയ്ക്ക് ഭൗതികമായി ഡാറ്റാബേസിൽ പ്രവേശിക്കാൻ കഴിയില്ല. കീ-വാല്യൂ സ്റ്റോറുകളിൽ അത്തരം നിയന്ത്രണങ്ങളൊന്നുമില്ല, അതിനാൽ ഡാറ്റാ സമഗ്രത നിരീക്ഷിക്കുന്നത് പൂർണ്ണമായും ആപ്ലിക്കേഷനുകളിൽ ആശ്രയിച്ചിരിക്കുന്നു. എന്നിരുന്നാലും, ഏത് കോഡിനും പിശകുകൾ ഉണ്ട്. നന്നായി രൂപകല്പന ചെയ്ത റിലേഷണൽ ഡാറ്റാബേസിലെ പിശകുകൾ സാധാരണയായി ഡാറ്റാ ഇന്റഗ്രിറ്റി പ്രശ്നങ്ങളിലേക്ക് നയിക്കില്ലെങ്കിലും, കീ-വാല്യൂ സ്റ്റോറുകളിലെ പിശകുകൾ സാധാരണയായി സംഭവിക്കുന്നു.

റിലേഷണൽ ഡാറ്റാബേസുകളുടെ മറ്റൊരു നേട്ടം, ഒരു ഡാറ്റ മോഡൽ വികസിപ്പിക്കുന്ന പ്രക്രിയയിലൂടെ കടന്നുപോകാൻ അവ നിങ്ങളെ നിർബന്ധിക്കുന്നു എന്നതാണ്. നിങ്ങൾ മോഡൽ നന്നായി രൂപകൽപ്പന ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, സംഭരിച്ചിരിക്കുന്ന ഡാറ്റയുടെ ഘടനയെ പൂർണ്ണമായും പ്രതിഫലിപ്പിക്കുന്ന ഒരു ലോജിക്കൽ ഘടന ഡാറ്റാബേസിൽ അടങ്ങിയിരിക്കും, പക്ഷേ ആപ്ലിക്കേഷന്റെ ഘടനയുമായി വിരുദ്ധമാണ്. ഇത് ഡാറ്റയെ ആപ്ലിക്കേഷനിൽ നിന്ന് സ്വതന്ത്രമാക്കുന്നു. മറ്റൊരു ആപ്ലിക്കേഷന് അതേ ഡാറ്റ ഉപയോഗിക്കാമെന്നും ഡാറ്റാബേസ് മോഡലിൽ മാറ്റങ്ങളൊന്നും കൂടാതെ ആപ്ലിക്കേഷൻ ലോജിക്ക് മാറ്റാമെന്നും ഇതിനർത്ഥം. ഒരു കീ-വാല്യൂ സ്റ്റോർ ഉപയോഗിച്ച് ഇതേ കാര്യം ചെയ്യാൻ, റിലേഷണൽ മോഡൽ ഡിസൈൻ പ്രോസസ്സ് ക്ലാസ് ഡിസൈൻ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാൻ ശ്രമിക്കുക, ഇത് ഡാറ്റയുടെ സ്വാഭാവിക ഘടനയെ അടിസ്ഥാനമാക്കി ജനറിക് ക്ലാസുകൾ സൃഷ്ടിക്കുന്നു.

ഒപ്പം അനുയോജ്യതയെക്കുറിച്ച് മറക്കരുത്. റിലേഷണൽ ഡാറ്റാബേസുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ക്ലൗഡ് അധിഷ്ഠിത സംഭരണത്തിന് പൊതുവായ മാനദണ്ഡങ്ങൾ വളരെ കുറവാണ്. അവ ആശയപരമായി വ്യത്യസ്തമല്ലെങ്കിലും, അവയ്‌ക്കെല്ലാം വ്യത്യസ്‌ത API-കളും അഭ്യർത്ഥന ഇന്റർഫേസുകളും അവയുടെ സ്വന്തം പ്രത്യേകതകളും ഉണ്ട്. അതിനാൽ, നിങ്ങളുടെ വെണ്ടറെ നിങ്ങൾക്ക് നന്നായി വിശ്വസിക്കാം, കാരണം എന്തെങ്കിലും സംഭവിച്ചാൽ, നിങ്ങൾക്ക് മറ്റൊരു സേവന ദാതാവിലേക്ക് എളുപ്പത്തിൽ മാറാൻ കഴിയില്ല. മിക്കവാറും എല്ലാ ആധുനിക കീ-വാല്യൂ സ്റ്റോറുകളും ബീറ്റ 2-ലാണെന്ന വസ്തുത കണക്കിലെടുക്കുമ്പോൾ, റിലേഷണൽ ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുന്നതിനേക്കാൾ വിശ്വാസ്യത കൂടുതൽ അപകടകരമാകും.

പരിമിതമായ ഡാറ്റ അനലിറ്റിക്സ്

സാധാരണഗതിയിൽ, എല്ലാ ക്ലൗഡ് സ്റ്റോറേജും ഒരു മൾട്ടി-ടെനൻസി അടിസ്ഥാനത്തിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അതായത് ധാരാളം ഉപയോക്താക്കളും ആപ്ലിക്കേഷനുകളും ഒരേ സിസ്റ്റം ഉപയോഗിക്കുന്നു. മൊത്തത്തിലുള്ള സിസ്റ്റം ഹൈജാക്ക് ചെയ്യപ്പെടാതിരിക്കാൻ, വെണ്ടർമാർ സാധാരണയായി ഏതെങ്കിലും വിധത്തിൽ അഭ്യർത്ഥനകൾ നടപ്പിലാക്കുന്നത് നിയന്ത്രിക്കുന്നു. ഉദാഹരണത്തിന്, SimpleDB-യിൽ, ഒരു അന്വേഷണം പൂർത്തിയാക്കാൻ 5 സെക്കൻഡിൽ കൂടുതൽ സമയമെടുക്കില്ല. Google AppEngine Datastore-ൽ, നിങ്ങൾക്ക് ഒരു അഭ്യർത്ഥനയിൽ 1000-ൽ കൂടുതൽ റെക്കോർഡുകൾ ലഭിക്കില്ല 3.

ലളിതമായ യുക്തിക്ക് ഈ നിയന്ത്രണങ്ങൾ ഭയാനകമല്ല (ചെറിയ എണ്ണം റെക്കോർഡുകൾ സൃഷ്ടിക്കുക, അപ്ഡേറ്റ് ചെയ്യുക, ഇല്ലാതാക്കുക, വീണ്ടെടുക്കുക). എന്നാൽ നിങ്ങളുടെ ആപ്പ് ജനപ്രിയമായാലോ? നിങ്ങൾക്ക് ധാരാളം പുതിയ ഉപയോക്താക്കളും ധാരാളം പുതിയ ഡാറ്റയും ലഭിച്ചു, ഇപ്പോൾ നിങ്ങൾ പുതിയ അനുഭവങ്ങൾ ഉപയോക്താക്കൾക്ക് ലഭ്യമാക്കാനോ ഡാറ്റയിൽ നിന്ന് എങ്ങനെയെങ്കിലും പ്രയോജനം നേടാനോ ആഗ്രഹിക്കുന്നു. ഡാറ്റാ വിശകലനത്തിനായി ലളിതമായ ചോദ്യങ്ങൾ പോലും നടപ്പിലാക്കാൻ നിങ്ങൾക്ക് ഇവിടെ ബുദ്ധിമുട്ട് നേരിടാം. ആപ്പ് ഉപയോഗ പാറ്റേണുകൾ ട്രാക്കുചെയ്യുന്നത് പോലെയുള്ള ഫീച്ചറുകൾ അല്ലെങ്കിൽ ഉപയോക്തൃ ചരിത്രത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു ശുപാർശ സിസ്റ്റം മികച്ച രീതിയിൽ നടപ്പിലാക്കാൻ ബുദ്ധിമുട്ടാണ്. ഏറ്റവും മോശം, അവ അസാധ്യമാണ്.

ഈ സാഹചര്യത്തിൽ, അനലിറ്റിക്‌സിന് ഒരു പ്രത്യേക ഡാറ്റാബേസ് നിർമ്മിക്കുന്നതാണ് നല്ലത്, അത് നിങ്ങളുടെ കീ-വാല്യൂ സ്റ്റോറിൽ നിന്നുള്ള ഡാറ്റ ഉപയോഗിച്ച് പൂരിപ്പിക്കും. ഇത് എങ്ങനെ ചെയ്യാമെന്ന് മുൻകൂട്ടി ചിന്തിക്കുക. നിങ്ങൾ ക്ലൗഡിലോ ഇൻ-ഹൗസിലോ സെർവർ ഹോസ്റ്റ് ചെയ്യുമോ? നിങ്ങളും നിങ്ങളുടെ ദാതാവും തമ്മിലുള്ള സിഗ്നൽ കാലതാമസം കാരണം പ്രശ്നങ്ങൾ ഉണ്ടാകുമോ? നിങ്ങളുടെ സംഭരണം ഈ ഡാറ്റാ കൈമാറ്റത്തെ പിന്തുണയ്ക്കുന്നുണ്ടോ? നിങ്ങൾക്ക് 100 ദശലക്ഷം റെക്കോർഡുകൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരേ സമയം 1000 റെക്കോർഡുകൾ എടുക്കാൻ കഴിയുമെങ്കിൽ, എല്ലാ ഡാറ്റയും മൈഗ്രേറ്റ് ചെയ്യാൻ എത്രമാത്രം എടുക്കും?

എന്നിരുന്നാലും, എല്ലാറ്റിനുമുപരിയായി സ്കേലബിളിറ്റിക്ക് മുൻഗണന നൽകരുത്. കൂടുതൽ ഫീച്ചറുകളും ക്രമീകരണങ്ങളും നൽകുന്നതിനാൽ നിങ്ങളുടെ ഉപയോക്താക്കൾ മറ്റൊരു സേവനത്തിന്റെ സേവനങ്ങൾ ഉപയോഗിക്കാൻ തീരുമാനിക്കുകയാണെങ്കിൽ അത് ഉപയോഗശൂന്യമാകും.

ക്ലൗഡ് സ്റ്റോറേജ്

പല വെബ് സേവന ദാതാക്കളും മൾട്ടി-ടെനന്റ് കീ-വാല്യൂ സ്റ്റോറുകൾ വാഗ്ദാനം ചെയ്യുന്നു. അവയിൽ മിക്കതും മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന മാനദണ്ഡങ്ങൾ പാലിക്കുന്നു, എന്നാൽ ഓരോന്നിനും അതിന്റേതായ വ്യതിരിക്തമായ സവിശേഷതകളുണ്ട്, മുകളിൽ വിവരിച്ച മാനദണ്ഡങ്ങളിൽ നിന്ന് വ്യത്യസ്തമാണ്. SimpleDB, Google AppEngine Datastore, SQL Data Services എന്നിവ പോലുള്ള പ്രത്യേക സംഭരണ ​​ഉദാഹരണങ്ങൾ നോക്കാം.

ആമസോൺ: സിമ്പിൾ ഡിബി

Amazon WebServices-ൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ആട്രിബ്യൂട്ട്-ഓറിയന്റഡ് കീ-വാല്യൂ സ്റ്റോറാണ് SimpleDB. SimpleDB ബീറ്റയിലാണ്; ഉപയോക്താക്കൾക്ക് ഇത് സൗജന്യമായി ഉപയോഗിക്കാം - അവരുടെ ആവശ്യങ്ങൾ ഒരു നിശ്ചിത പരിധി കവിയാത്തിടത്തോളം.

സിമ്പിൾ ഡിബിക്ക് നിരവധി പരിമിതികളുണ്ട്. ആദ്യം, അന്വേഷണ നിർവ്വഹണ സമയം 5 സെക്കൻഡായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. രണ്ടാമതായി, സ്ട്രിംഗുകൾ ഒഴികെയുള്ള ഡാറ്റ തരങ്ങളൊന്നുമില്ല. എല്ലാം ഒരു സ്ട്രിംഗ് ആയി സംഭരിക്കുകയും വീണ്ടെടുക്കുകയും താരതമ്യം ചെയ്യുകയും ചെയ്യുന്നു, അതിനാൽ തീയതികൾ താരതമ്യം ചെയ്യുന്നതിന് നിങ്ങൾ അവയെ ISO8601 ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യേണ്ടതുണ്ട്. മൂന്നാമതായി, ഏത് സ്‌ട്രിംഗിന്റെയും പരമാവധി വലുപ്പം 1024 ബൈറ്റുകളാണ്, ഇത് നിങ്ങൾക്ക് ആട്രിബ്യൂട്ടായി സംഭരിക്കാൻ കഴിയുന്ന വാചകത്തിന്റെ വലുപ്പം (ഉദാഹരണത്തിന്, ഒരു ഉൽപ്പന്ന വിവരണം) പരിമിതപ്പെടുത്തുന്നു. എന്നിരുന്നാലും, ഡാറ്റാ ഘടന വഴക്കമുള്ളതിനാൽ, "ഉൽപ്പന്ന വിവരണം1", "ഉൽപ്പന്ന വിവരണം2" മുതലായവ ആട്രിബ്യൂട്ടുകൾ ചേർത്ത് നിങ്ങൾക്ക് ഈ പരിമിതി പരിഹരിക്കാനാകും. എന്നാൽ ആട്രിബ്യൂട്ടുകളുടെ എണ്ണവും പരിമിതമാണ് - പരമാവധി 256 ആട്രിബ്യൂട്ടുകൾ. SimpleDB ബീറ്റയിലായിരിക്കുമ്പോൾ, ഡൊമെയ്ൻ വലുപ്പം 10 ജിഗാബൈറ്റായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, കൂടാതെ മുഴുവൻ ഡാറ്റാബേസിനും 1 ടെറാബൈറ്റിൽ കൂടുതൽ ഉൾക്കൊള്ളാൻ കഴിയില്ല.

സിമ്പിൾ ഡിബിയുടെ പ്രധാന സവിശേഷതകളിലൊന്ന് അന്തിമ സ്ഥിരത മോഡലിന്റെ ഉപയോഗമാണ്. ഈ മോഡൽ മൾട്ടി-ത്രെഡഡ് വർക്കിന് അനുയോജ്യമാണ്, എന്നാൽ ഒരിക്കൽ നിങ്ങൾ ഒരു റെക്കോർഡിലെ ആട്രിബ്യൂട്ടിന്റെ മൂല്യം മാറ്റിയാൽ, തുടർന്നുള്ള വായനകളിൽ ആ മാറ്റങ്ങൾ കാണാനിടയില്ല. സംഭവങ്ങളുടെ അത്തരമൊരു വികാസത്തിന്റെ സാധ്യത വളരെ കുറവാണ്, എന്നിരുന്നാലും, ഇത് ഓർമ്മിക്കേണ്ടതാണ്. വിൽപ്പന സമയത്ത് നിങ്ങളുടെ ഡാറ്റ പൊരുത്തമില്ലാത്തതിനാൽ അവസാന ടിക്കറ്റ് അഞ്ച് വാങ്ങുന്നവർക്ക് വിൽക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല.

Google AppEngine ഡാറ്റ സ്റ്റോർ

Google-ന്റെ AppEngine ഡാറ്റാസ്റ്റോർ നിർമ്മിച്ചിരിക്കുന്നത് BigTable-ന്റെ മുകളിലാണ്

AppEngine Datastore SimpleDB-യെക്കാൾ കൂടുതൽ ഡാറ്റ തരങ്ങളെ ഒരൊറ്റ റെക്കോർഡിനുള്ളിൽ പിന്തുണയ്ക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു റെക്കോർഡിനുള്ളിൽ ശേഖരങ്ങൾ ഉൾക്കൊള്ളാൻ കഴിയുന്ന ലിസ്റ്റുകൾ.

Google AppEngine ഉപയോഗിച്ച് വികസിപ്പിക്കുമ്പോൾ നിങ്ങൾ മിക്കവാറും ഉപയോഗിക്കാനിടയുള്ള ഡാറ്റ സ്റ്റോറാണിത്. എന്നിരുന്നാലും, SimpleDB പോലെയല്ല, നിങ്ങൾക്ക് Google വെബ് സേവനങ്ങൾക്ക് പുറത്ത് AppEngine ഡാറ്റാസ്റ്റോർ (അല്ലെങ്കിൽ BigTable) ഉപയോഗിക്കാൻ കഴിയില്ല.

Microsoft: SQL ഡാറ്റ സേവനങ്ങൾ

SQL ഡാറ്റ സേവനങ്ങൾ Microsoft Azure പ്ലാറ്റ്‌ഫോമിന്റെ ഭാഗമാണ്. SQL ഡാറ്റ സേവനങ്ങൾ സൗജന്യമാണ്, ബീറ്റയിൽ, കൂടാതെ ഡാറ്റാബേസ് വലുപ്പ പരിധികളുമുണ്ട്. SQL ഡാറ്റ സേവനങ്ങൾ ഒരു പ്രത്യേക ആപ്ലിക്കേഷനാണ് - ഡാറ്റ സംഭരിക്കുന്ന നിരവധി SQL സെർവറുകളിൽ ഒരു ആഡ്-ഓൺ. ഈ സ്റ്റോറുകൾ റിലേഷണൽ ആയിരിക്കാം, എന്നാൽ നിങ്ങൾക്ക് SDS മുകളിൽ വിവരിച്ച ഉൽപ്പന്നങ്ങൾ പോലെ തന്നെ ഒരു പ്രധാന മൂല്യമുള്ള സ്റ്റോറാണ്.

ക്ലൗഡ് അല്ലാത്ത സംഭരണം

ക്ലൗഡിന് പുറത്ത് സ്വയം ഇൻസ്റ്റാൾ ചെയ്ത് ഉപയോഗിക്കാവുന്ന നിരവധി സ്റ്റോറേജ് ഓപ്ഷനുകളും ഉണ്ട്. ഈ പ്രോജക്‌റ്റുകളെല്ലാം ചെറുപ്പമാണ്, ആൽഫയിലോ ബീറ്റയിലോ, ഓപ്പൺ സോഴ്‌സ് ആണ്. ഓപ്പൺ സോഴ്‌സ് ഉപയോഗിച്ച്, കുത്തക ഉൽപ്പന്നങ്ങളേക്കാൾ സാധ്യതയുള്ള പ്രശ്‌നങ്ങളെയും പരിമിതികളെയും കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ ബോധമുണ്ടാകാം.

CouchDB

CouchDB സൗജന്യമായി ലഭ്യമായ, ഓപ്പൺ സോഴ്‌സ്, ഡോക്യുമെന്റ്-ഓറിയന്റഡ് ഡാറ്റാബേസ് ആണ്. JSON ഒരു ഡാറ്റ സ്റ്റോറേജ് ഫോർമാറ്റായി ഉപയോഗിക്കുന്നു. "കാഴ്ചകൾ" ഉപയോഗിച്ച് ഡോക്യുമെന്റ്-ഓറിയന്റഡ്, റിലേഷണൽ ഡാറ്റാബേസുകൾ തമ്മിലുള്ള വിടവ് നികത്താൻ CouchDB ലക്ഷ്യമിടുന്നു. അത്തരം കാഴ്‌ചകളിൽ ഡോക്യുമെന്റുകളിൽ നിന്നുള്ള ഡാറ്റ ഒരു പട്ടിക പോലുള്ള രൂപത്തിൽ അടങ്ങിയിരിക്കുന്നു, കൂടാതെ സൂചികകൾ നിർമ്മിക്കാനും അന്വേഷണങ്ങൾ പ്രവർത്തിപ്പിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

നിലവിൽ, CouchDB യഥാർത്ഥത്തിൽ വിതരണം ചെയ്ത ഒരു ഡാറ്റാബേസ് അല്ല. സെർവറുകൾക്കിടയിൽ ഡാറ്റ സമന്വയിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന റെപ്ലിക്കേഷൻ ഫംഗ്‌ഷനുകൾ ഇതിന് ഉണ്ട്, എന്നാൽ ഇത് ഉയർന്ന അളവിലുള്ള അന്തരീക്ഷം നിർമ്മിക്കുന്നതിന് ആവശ്യമായ വിതരണമല്ല. എന്നിരുന്നാലും, CouchDB ഡവലപ്പർമാർ ഇതിൽ പ്രവർത്തിക്കുന്നു.

പ്രോജക്റ്റ് വോൾഡ്മോർട്ട്

വോൾഡ്‌മോർട്ട് പ്രോജക്‌റ്റ് എന്നത് ഒരു വലിയ സെർവറിലുടനീളം തിരശ്ചീനമായി സ്‌കെയിൽ ചെയ്യാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു ഡിസ്ട്രിബ്യൂഡ് കീ-വാല്യൂ ഡാറ്റാബേസാണ്. ലിങ്ക്ഡ്ഇൻ വികസന പ്രക്രിയയിൽ നിന്നാണ് ഇത് ജനിച്ചത്, ഉയർന്ന സ്കേലബിലിറ്റി ആവശ്യകതകളുള്ള നിരവധി സിസ്റ്റങ്ങൾക്കായി ഇത് ഉപയോഗിച്ചു. വോൾഡ്‌മോർട്ട് പ്രോജക്റ്റ് ഒരു പരിമിതമായ സ്ഥിരത മോഡലും ഉപയോഗിക്കുന്നു.

മോംഗോ

ഗീർ മാഗ്‌നുസണും ഡ്വൈറ്റ് മെറിമാനും (DoubleClick-ൽ നിന്ന് നിങ്ങൾക്കറിയാവുന്ന) 10gen-ൽ വികസിപ്പിച്ചെടുത്ത ഒരു ഡാറ്റാബേസാണ് മോംഗോ. CouchDB പോലെ, JSON ഫോർമാറ്റിൽ ഡാറ്റ സംഭരിക്കുന്ന ഒരു ഡോക്യുമെന്റ്-ഓറിയന്റഡ് ഡാറ്റാബേസാണ് മോംഗോ. എന്നിരുന്നാലും, മോംഗോ ഒരു പ്യുവർ കീ-വാല്യൂ സ്റ്റോറിനേക്കാൾ ഒരു ഒബ്ജക്റ്റ് ബേസ് ആണ്.

ചാറ്റൽ മഴ

കീ-വാല്യൂ സ്റ്റോറുകൾ പ്രതിരോധിക്കാൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള വളരെ വ്യത്യസ്തമായ ഒരു സമീപനത്തെയാണ് ചാറ്റൽ മഴ പ്രതിനിധീകരിക്കുന്നത്. MySQL 6.0 ന്റെ ഫോർക്ക് ആയി ചാറ്റൽ മഴ ആരംഭിച്ചു. പിന്നീട്, ലളിതവും വേഗമേറിയതുമായ ഒരു DBMS സൃഷ്‌ടിക്കുന്നതിനായി ഡവലപ്പർമാർ നിരവധി ഫംഗ്‌ഷനുകൾ (കാഴ്‌ചകൾ, ട്രിഗറുകൾ, കംപൈൽ ചെയ്‌ത എക്‌സ്‌പ്രഷനുകൾ, സംഭരിച്ച നടപടിക്രമങ്ങൾ, അന്വേഷണ കാഷെ, ACL-കൾ, ചില ഡാറ്റ തരങ്ങൾ എന്നിവ ഉൾപ്പെടെ) നീക്കം ചെയ്‌തു. എന്നിരുന്നാലും, റിലേഷണൽ ഡാറ്റ സംഭരിക്കുന്നതിന് ഇപ്പോഴും ഡ്രിസിൽ ഉപയോഗിക്കാം. 16-ഓ അതിലധികമോ കോറുകളുള്ള സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കുന്ന വെബ്, ക്ലൗഡ് ആപ്ലിക്കേഷനുകൾക്കായി രൂപകൽപ്പന ചെയ്ത ഒരു സെമി-റിലേഷണൽ പ്ലാറ്റ്ഫോം നിർമ്മിക്കുക എന്നതാണ് ഡവലപ്പർമാരുടെ ലക്ഷ്യം.

പരിഹാരം

ആത്യന്തികമായി, നിങ്ങളുടെ ആപ്ലിക്കേഷനായി ഒരു നോൺ-റിലേഷണൽ കീ-വാല്യൂ സ്റ്റോർ തിരഞ്ഞെടുക്കുന്നതിന് നാല് കാരണങ്ങളുണ്ട്:

1. നിങ്ങളുടെ ഡാറ്റ വളരെ ഡോക്യുമെന്റ്-ഓറിയന്റഡ് ആണ്, കൂടാതെ റിലേഷണൽ മോഡലിനേക്കാൾ കീ-വാല്യൂ ഡാറ്റ മോഡലിന് ഇത് കൂടുതൽ അനുയോജ്യമാണ്.
2. നിങ്ങളുടെ ഡൊമെയ്ൻ മോഡൽ വളരെ ഒബ്ജക്റ്റ്-ഓറിയന്റഡ് ആണ്, അതിനാൽ ഒരു കീ-വാല്യൂ സ്റ്റോർ ഉപയോഗിക്കുന്നത് ഡാറ്റ രൂപാന്തരപ്പെടുത്തുന്നതിന് ആവശ്യമായ അധിക കോഡിന്റെ അളവ് കുറയ്ക്കും.
3. ഡാറ്റ വെയർഹൗസ് വിലകുറഞ്ഞതും നിങ്ങളുടെ വെണ്ടറുടെ വെബ് സേവനങ്ങളുമായി എളുപ്പത്തിൽ സംയോജിപ്പിക്കുന്നതുമാണ്.
4. നിങ്ങളുടെ പ്രധാന പ്രശ്നം ഉയർന്ന ഡിമാൻഡ് സ്കേലബിളിറ്റിയാണ്.

എന്നിരുന്നാലും, നിങ്ങളുടെ തീരുമാനം എടുക്കുമ്പോൾ, നിർദ്ദിഷ്ട ഡാറ്റാബേസുകളുടെ പരിമിതികളെക്കുറിച്ചും നോൺ-റിലേഷണൽ ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുമ്പോൾ നിങ്ങൾ നേരിടേണ്ടിവരുന്ന അപകടസാധ്യതകളെക്കുറിച്ചും അറിഞ്ഞിരിക്കുക.

മറ്റെല്ലാ ആവശ്യങ്ങൾക്കും, നല്ല പഴയ റിലേഷണൽ DBMS തിരഞ്ഞെടുക്കുന്നതാണ് നല്ലത്. അപ്പോൾ അവർ നശിച്ചുപോയോ? തീർച്ചയായും ഇല്ല. ഇപ്പോഴെങ്കിലും.

1 - എന്റെ അഭിപ്രായത്തിൽ, "ഡാറ്റ ഘടന" എന്ന പദം ഇവിടെ കൂടുതൽ അനുയോജ്യമാണ്, പക്ഷേ ഞാൻ യഥാർത്ഥ ഡാറ്റ മോഡൽ ഉപേക്ഷിച്ചു.
2 - മിക്കവാറും, രചയിതാവ് അർത്ഥമാക്കുന്നത് അവയുടെ കഴിവുകളുടെ കാര്യത്തിൽ, നോൺ-റിലേഷണൽ ഡാറ്റാബേസുകൾ ആപേക്ഷികമായവയെക്കാൾ താഴ്ന്നതാണെന്നാണ്.
3 - ഡാറ്റ ഇതിനകം കാലഹരണപ്പെട്ടതായിരിക്കാം; ലേഖനം ഫെബ്രുവരി 2009 മുതലുള്ളതാണ്.

ടാഗ് ചേർക്കുക

റിലേഷണൽ മോഡൽ

റിലേഷണൽ ഡാറ്റാബേസ് മോഡൽ 1969-ൽ ഗണിതശാസ്ത്രജ്ഞനും ഐബിഎം ഗവേഷകനുമായ ഇ.എഫ്. കോഡ് (ഇ.എഫ്. കോഡ്). റിലേഷണൽ ഡാറ്റാബേസുകളെക്കുറിച്ചുള്ള ചില അടിസ്ഥാന വിവരങ്ങൾക്ക്, അവലോകന ലേഖനം കാണുക " ഡിബി, ഡിബിഎംഎസ്" 2. റിലേഷണൽ ഡാറ്റാബേസുകൾ നിലവിൽ പ്രബലമായതിനാൽ, ഈ ലേഖനത്തിൽ (അതുപോലെ ലേഖനങ്ങളിലും " ഡാറ്റ വിവരണം”, “ഡാറ്റ പ്രോസസ്സിംഗ്" ഒപ്പം " ഡാറ്റാബേസ് ഡിസൈൻ” 2) റിലേഷണൽ മോഡലിന്റെ ഏറ്റവും അത്യാവശ്യമായ ആശയങ്ങൾ വിശദമായി ചർച്ചചെയ്യുന്നു.

റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സിദ്ധാന്തം തുടക്കത്തിൽ കർശനമായ ഗണിതശാസ്ത്ര ഭാഷയിലാണ് രൂപപ്പെടുത്തിയതെന്നും കാര്യങ്ങളുടെ സാരാംശം നന്നായി വിവരിക്കുന്ന കൃത്യമായ കർശനമായ, ഔപചാരികമായി നിർവചിക്കപ്പെട്ട ഗണിതശാസ്ത്ര ആശയങ്ങളാണെന്നും നമുക്ക് ഉടനടി ശ്രദ്ധിക്കാം. അതേസമയം, മിക്ക കേസുകളിലും, അവതരണത്തിന്റെ സുതാര്യതയ്‌ക്ക് അനുകൂലമായി പദാവലിയുടെ കാഠിന്യം ത്യജിക്കാൻ വലിയ കേടുപാടുകൾ കൂടാതെ സാധ്യമാണ്, അതാണ് ഞങ്ങൾ ചെയ്യാൻ ശ്രമിക്കുന്നത്.

റിലേഷണൽ മോഡലിന്റെ പ്രധാന ആശയം ഇപ്രകാരമാണ്. ഡാറ്റാബേസിൽ ക്രമരഹിതമായ ഒരു ശ്രേണി അടങ്ങിയിരിക്കുന്നു പട്ടികകൾ(ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ - ഒരു പട്ടികയിൽ നിന്ന്). നോൺ പ്രൊസീജറൽ (ഡിക്ലറേറ്റീവ്) പ്രവർത്തനങ്ങളിലൂടെ പട്ടികകൾ കൈകാര്യം ചെയ്യാൻ കഴിയും - അഭ്യർത്ഥിക്കുന്നു, അതിന്റെ ഫലങ്ങളും പട്ടികകളാണ്.

പലപ്പോഴും "ബന്ധം" എന്ന വാക്ക് ( ബന്ധമുള്ള) "റിലേഷണൽ മോഡൽ" എന്ന പദത്തിൽ, കണക്ഷനുകൾ ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ സ്ഥാപിച്ചിരിക്കുന്നു എന്ന വസ്തുതയെ അടിസ്ഥാനമാക്കിയാണ് വ്യാഖ്യാനിക്കുന്നത് ( ബന്ധപ്പെടുത്തുക) പട്ടികകൾക്കിടയിൽ. ഈ വിശദീകരണം സൗകര്യപ്രദമാണ്, പക്ഷേ അത് കൃത്യമല്ല. കോഡിന്റെ യഥാർത്ഥ വ്യവസ്ഥിതിയിൽ, കണക്ഷൻ നിബന്ധനകൾ ( ബന്ധങ്ങൾ), ഗുണവിശേഷങ്ങൾ ( ഗുണവിശേഷങ്ങൾ) ഒപ്പം ട്യൂപ്പിൾസ് ( ട്യൂപ്പിൾസ്പട്ടികകൾ, നിരകൾ (ഫീൽഡുകൾ), വരികൾ (റെക്കോഡുകൾ) എന്നിവ നമ്മിൽ ഭൂരിഭാഗവും കൂടുതൽ പരിചിതമായ പദങ്ങൾ ഉപയോഗിക്കുന്നിടത്താണ് ) ഉപയോഗിച്ചത്.

ഒരു വിഷയ മേഖലയുടെ വിവര മാതൃക നിർമ്മിക്കുമ്പോൾ (കാണുക "" ഡിബി, ഡിബിഎംഎസ്”, “ഡാറ്റാബേസ് ഡിസൈൻ” 2) വേറിട്ടു നിൽക്കുക സാരാംശം(വസ്തുക്കൾ), അവയെ വിവരിക്കുക പ്രോപ്പർട്ടികൾഒരു (സ്വഭാവങ്ങൾ, ആട്രിബ്യൂട്ടുകൾ) മോഡലിംഗ് ആവശ്യങ്ങൾക്ക് അത്യന്താപേക്ഷിതമാണ്, കൂടാതെ എന്റിറ്റികൾ തമ്മിലുള്ള ബന്ധങ്ങൾ സ്ഥാപിക്കപ്പെടുന്നു. ഇൻഫോളോജിക്കിൽ നിന്ന് ഡാറ്റാോളജിക്കൽ റിലേഷണൽ മോഡലിലേക്ക് മാറുന്ന ഘട്ടത്തിൽ, പട്ടികകൾ പ്രത്യക്ഷപ്പെടുന്നു. സാധാരണയായി, ഓരോ എന്റിറ്റിയെയും ഒരു പട്ടിക പ്രതിനിധീകരിക്കുന്നു. പട്ടികയുടെ ഓരോ വരിയും (ഒരു റെക്കോർഡ്) എന്റിറ്റിയുടെ ഒരു സംഭവവുമായി പൊരുത്തപ്പെടുന്നു, കൂടാതെ ഓരോ ഫീൽഡും ഒരു നിശ്ചിത പ്രോപ്പർട്ടി (ആട്രിബ്യൂട്ട്) വിവരിക്കുന്നു..

ഉദാഹരണത്തിന്, ഓരോ വ്യക്തിയുടെയും അവസാന നാമം, പേരിന്റെ ആദ്യഭാഗം, രക്ഷാധികാരി, TIN, താമസിക്കുന്ന രാജ്യം, ജനനത്തീയതി എന്നിവയുൾപ്പെടെ ആളുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഞങ്ങൾക്ക് സംഭരിക്കേണ്ടതുണ്ടെങ്കിൽ, എന്റിറ്റി വ്യക്തിയാണ്, കൂടാതെ നിർദ്ദിഷ്ട ഡാറ്റയാണ് ആട്രിബ്യൂട്ടുകൾ. എന്റിറ്റി തന്നെ സ്വാഭാവികമായും പട്ടികയുടെ പേരായി മാറുന്നു.

പട്ടിക "മനുഷ്യൻ"

റിലേഷണൽ മോഡലിന് ഒരു പട്ടികയിലെ ഓരോ വരിയും അദ്വിതീയമായിരിക്കണം, അതായത്. അതിനാൽ ഏതെങ്കിലും രണ്ട് വരികൾ കുറഞ്ഞത് ഒരു ആട്രിബ്യൂട്ടിന്റെ മൂല്യത്തിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

നിങ്ങൾക്ക് ഡാറ്റ തന്നെ അവതരിപ്പിക്കേണ്ടിവരുമ്പോൾ പരമ്പരാഗത പട്ടിക ഫോം ഉപയോഗപ്രദമാണ്. മുകളിലുള്ള ഉദാഹരണത്തിലെന്നപോലെ, നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ ഘടന- ഫീൽഡ് നാമങ്ങൾ, തുടർന്ന് വ്യക്തത, ഡയഗ്രമുകളിലെ എളുപ്പത്തിലുള്ള ഉപയോഗം, സ്ഥലം ലാഭിക്കൽ എന്നിവയിൽ നിന്ന്, ഇത് ഇനിപ്പറയുന്ന രീതിയിൽ ചിത്രീകരിക്കുന്നത് കൂടുതൽ സൗകര്യപ്രദമാണ്:

കീകൾ

താക്കോൽ പട്ടികകൾതന്നിരിക്കുന്ന പട്ടികയ്ക്കുള്ളിൽ തനതായ മൂല്യങ്ങൾ അടങ്ങിയ ഒരു ഫീൽഡ് അല്ലെങ്കിൽ ഫീൽഡുകളുടെ ഗ്രൂപ്പാണ്. കീ അനുബന്ധ പട്ടിക നിരയെ അദ്വിതീയമായി തിരിച്ചറിയുന്നു. കീയിൽ ഒരൊറ്റ ഫീൽഡ് അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, അതിനെ പലപ്പോഴും വിളിക്കുന്നു ലളിതമായ, പലരിൽ നിന്നാണെങ്കിൽ - സംയുക്തം. മുകളിലുള്ള ഉദാഹരണത്തിൽ, പ്രധാനം TIN ഫീൽഡാണ് (ഒരു രാജ്യത്തിനുള്ളിൽ TIN-കൾ അദ്വിതീയമാണെന്ന് ഞങ്ങൾ കരുതുന്നു).

ഒരു സംയുക്ത കീ ഉള്ള ഒരു പട്ടികയുടെ ഉദാഹരണം നോക്കാം. കാലാവസ്ഥാ പ്രവചന വെബ്‌സൈറ്റുകൾ പലപ്പോഴും വിവരങ്ങൾ ഇനിപ്പറയുന്ന രീതിയിൽ അവതരിപ്പിക്കുന്നു: ഓരോ തീയതിക്കും, അവർ രാത്രിയിലും രാവിലെയും ഉച്ചയ്ക്കും വൈകുന്നേരവും പ്രവചിച്ച താപനിലയെ സൂചിപ്പിക്കുന്നു. ഈ വിവരങ്ങൾ സംഭരിക്കുന്നതിന്, നിങ്ങൾക്ക് ഇതുപോലുള്ള ഒരു പട്ടിക ഉപയോഗിക്കാം:

ഈ പട്ടികയിൽ, തീയതിയോ ദിവസത്തിന്റെ സമയമോ താപനില ഫീൽഡുകളോ കീകളല്ല - ഈ ഓരോ ഫീൽഡിലും മൂല്യങ്ങൾ ആവർത്തിക്കാം. എന്നാൽ ദിവസ ഫീൽഡുകളുടെ തീയതി + സമയം എന്നിവയുടെ സംയോജനം അദ്വിതീയവും ഒരു പട്ടിക നിരയെ അതുല്യമായി തിരിച്ചറിയുന്നതുമാണ്. ഇതൊരു സംയുക്ത കീയാണ്.

കീയുടെ തിരഞ്ഞെടുപ്പ് അവ്യക്തമല്ലാത്ത സാഹചര്യങ്ങളുണ്ട്. നമുക്ക് ആദ്യത്തെ ഉദാഹരണത്തിലേക്ക് മടങ്ങാം. അവസാന നാമം, ആദ്യനാമം, രക്ഷാധികാരി, ടിൻ, ജനനത്തീയതി എന്നിവയ്‌ക്ക് പുറമേ, ഒരു പൊതു പാസ്‌പോർട്ടിന്റെ സീരീസും നമ്പറും ഒരു വിദേശ പാസ്‌പോർട്ടിന്റെ സീരീസും നമ്പറും സംഭരിക്കേണ്ടത് ആവശ്യമാണെന്ന് പറയാം. പട്ടിക ഇതുപോലെ കാണപ്പെടും:

ഈ പട്ടികയിൽ നിങ്ങൾക്ക് മൂന്ന് കീകൾ വരെ തിരഞ്ഞെടുക്കാം. അവയിലൊന്ന് ലളിതമാണ് (TIN), മറ്റ് രണ്ടെണ്ണം സംയുക്തമാണ് (സീരീസ് + ജനറൽ പാസ്‌പോർട്ട് നമ്പർ, സീരീസ് + വിദേശ പാസ്‌പോർട്ട് നമ്പർ). അത്തരമൊരു സാഹചര്യത്തിൽ, ഡാറ്റാബേസ് ഓർഗനൈസുചെയ്യുന്നതിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഡവലപ്പർ ഏറ്റവും സൗകര്യപ്രദമായ കീ തിരഞ്ഞെടുക്കുന്നു (പൊതുവേ, മൂല്യം കണ്ടെത്താൻ ഏറ്റവും കുറഞ്ഞ സമയം എടുക്കുന്ന കീ). ഈ കേസിൽ തിരഞ്ഞെടുത്ത കീയെ പലപ്പോഴും പ്രധാന കീ എന്ന് വിളിക്കുന്നു, അല്ലെങ്കിൽ പ്രാഥമിക, കീ, ഒരു കീ ഉണ്ടാക്കാൻ കഴിയുന്ന നിരകളുടെ മറ്റ് കോമ്പിനേഷനുകൾ എന്നിവയാണ് സാധ്യമാണ്, അല്ലെങ്കിൽ ഇതര, കീകൾ. ഒരു പട്ടികയിൽ എല്ലായ്‌പ്പോഴും സാധ്യമായ ഒരു കീയെങ്കിലും ഉണ്ടെന്ന് ശ്രദ്ധിക്കുക, കാരണം വരികൾ ആവർത്തിക്കാൻ കഴിയില്ല, അതിനാൽ, എല്ലാ നിരകളുടെയും സംയോജനം സാധ്യമായ കീയാണെന്ന് ഉറപ്പുനൽകുന്നു.

പട്ടികകൾ ചിത്രീകരിക്കുമ്പോൾ, പട്ടികകളുടെ പ്രാഥമിക കീകൾ ഹൈലൈറ്റ് ചെയ്യുന്നത് പതിവാണ്. ഉദാഹരണത്തിന്, പ്രസക്തമായ ഫീൽഡുകൾ പലപ്പോഴും അടിവരയിടുന്നു. മൈക്രോസോഫ്റ്റ് ആക്‌സസ് പ്രധാന ഫീൽഡുകൾ ബോൾഡിൽ ഹൈലൈറ്റ് ചെയ്യുന്നു.

ഒരു കീ തിരഞ്ഞെടുക്കുന്നതിലെ അവ്യക്തതയേക്കാൾ പലപ്പോഴും, സംഭരിക്കേണ്ട ഡാറ്റയിൽ ഒരു കീയുടെ അഭാവത്തെ ഡെവലപ്പർമാർ അഭിമുഖീകരിക്കുന്നു. വിഷയ മേഖലയെ വിശകലനം ചെയ്യുന്ന പ്രക്രിയയിൽ സമാനമായ ഒരു വസ്തുത സ്ഥാപിക്കാവുന്നതാണ്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ആളുകളുടെ ഒരു ലളിതമായ ലിസ്റ്റ് സംഭരിക്കേണ്ടതുണ്ടെങ്കിൽ - പേരുകളുടെ പേരുകൾ, അവസാന നാമങ്ങൾ, രക്ഷാധികാരികൾ, ജനനത്തീയതികൾ, ഈ ആട്രിബ്യൂട്ടുകളുടെ ഒരു കൂട്ടത്തിൽ ഒരു കീയും ഇല്ല - രണ്ട് വ്യത്യസ്ത ആളുകൾക്ക് ഒരേ പോലെയുള്ള അവസ്ഥയാണ് സങ്കൽപ്പിക്കാവുന്ന ഒരു സാഹചര്യം. ഡാറ്റ പൂർണ്ണമായും. ഈ സാഹചര്യത്തിൽ, നിങ്ങൾ കൃത്രിമമായി ഒരു അധിക ഫീൽഡ് നൽകണം, ഉദാഹരണത്തിന്, ഒരു അദ്വിതീയ വ്യക്തി നമ്പർ. അത്തരമൊരു താക്കോൽ ചിലപ്പോൾ സാഹിത്യത്തിൽ വിളിക്കപ്പെടുന്നു പകരക്കാരൻ. കാര്യക്ഷമതയുടെ കാരണങ്ങളാൽ പലപ്പോഴും ഒരു സറോഗേറ്റ് കീ അവതരിപ്പിക്കപ്പെടുന്നു. ഉദാഹരണത്തിന്, ഒരു പട്ടികയിൽ ഒരു നീണ്ട സംയുക്ത കീ ഉണ്ടെങ്കിൽ, ഡെവലപ്പർമാർ പലപ്പോഴും ഒരു അധിക ഹ്രസ്വ സംഖ്യാ സറോഗേറ്റ് കീ അവതരിപ്പിക്കുകയും അതിനെ പ്രാഥമിക കീ ആക്കുകയും ചെയ്യുന്നു. "അസുലഭമായ" (തിരയാൻ ഫലപ്രദമല്ലാത്ത) ഡാറ്റ തരം ഉള്ള ഒരു ലളിതമായ കീ ഉണ്ടെങ്കിൽ പോലും ഇത് പലപ്പോഴും ചെയ്യാറുണ്ട്, ഉദാഹരണത്തിന്, ഒരു സ്ട്രിംഗ്. അത്തരം പ്രവർത്തനങ്ങൾ ഇനി സിദ്ധാന്തത്തിന് പ്രസക്തമല്ല, പക്ഷേ പലപ്പോഴും പ്രായോഗികമായി നേരിടുന്നു.

അനാവശ്യ ഫീൽഡുകൾ ഉൾപ്പെടുത്തി (പട്ടികയിലെ എല്ലാ ഫീൽഡുകളും ഉൾപ്പെടുത്തിയില്ലെങ്കിൽ) കീ മിക്കവാറും എല്ലായ്‌പ്പോഴും വിപുലീകരിക്കാൻ കഴിയുമെന്ന് ശ്രദ്ധയുള്ള വായനക്കാരൻ ശ്രദ്ധിച്ചേക്കാം. ഔപചാരികമായി, അത്തരമൊരു കീ ഒരു താക്കോലായി തുടരും, എന്നാൽ പ്രായോഗിക കാഴ്ചപ്പാടിൽ, ഇത് ആശയങ്ങളുടെ ഒരു ഗെയിം മാത്രമാണ്. കീയുടെ ദൈർഘ്യം (സങ്കീർണ്ണത) കുറയ്ക്കാൻ എല്ലായ്പ്പോഴും പരിശ്രമിക്കേണ്ടത് ആവശ്യമായതിനാൽ അത്തരം കീകൾ സാധ്യമാണെന്ന് പോലും കണക്കാക്കില്ല.

സാധാരണ രൂപങ്ങൾ, സാധാരണവൽക്കരണം

നമുക്ക് പേപ്പറിലോ വേഡിലോ വരയ്ക്കാൻ കഴിയുന്ന എല്ലാ ടേബിളും ഒരു റിലേഷണൽ ഡാറ്റാബേസ് ടേബിളാകണമെന്നില്ല. റിലേഷണൽ മോഡൽ ആവശ്യകതയുടെ വീക്ഷണകോണിൽ നിന്ന് ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ ഉപയോഗിക്കാവുന്ന എല്ലാ പട്ടികയും ശരിയല്ല.

ഒന്നാമതായി, ഒരേ കോളത്തിനുള്ളിലെ എല്ലാ ഡാറ്റയും ഒരേ തരത്തിലായിരിക്കണമെന്ന് ആവശ്യപ്പെടുന്നു(തരങ്ങളെക്കുറിച്ച് കാണുക“ഡാറ്റ വിവരണം” 2). ഈ വീക്ഷണകോണിൽ, ചുവടെയുള്ള ഉദാഹരണം ചർച്ച ചെയ്യുന്നതിൽ പോലും അർത്ഥമില്ല:

രണ്ടാമതായി, പട്ടികയ്ക്ക് ഒരു പ്രാഥമിക കീ അസൈൻ ചെയ്യേണ്ടതുണ്ട്.

ഈ ആവശ്യകതകൾ ആവശ്യമാണ്, പക്ഷേ പര്യാപ്തമല്ല. റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സിദ്ധാന്തം "സാധാരണ രൂപങ്ങൾ" എന്ന് വിളിക്കപ്പെടുന്ന ആശയങ്ങൾ അവതരിപ്പിക്കുന്നു - പട്ടികകളിൽ ഡാറ്റ സംഘടിപ്പിക്കുന്നതിനുള്ള ആവശ്യകതകൾ. ആവശ്യകതകൾ കൂടുതൽ കർശനമാകുന്നതിനാൽ സാധാരണ ഫോമുകൾ തുടർച്ചയായി അക്കമിട്ടിരിക്കുന്നു. ശരിയായി രൂപകൽപ്പന ചെയ്ത ഡാറ്റാബേസിൽ, പട്ടികകൾ കുറഞ്ഞത് മൂന്നാമത്തെ സാധാരണ രൂപത്തിലെങ്കിലും ആയിരിക്കും. അതനുസരിച്ച്, ആദ്യത്തെ മൂന്ന് സാധാരണ രൂപങ്ങൾ ഞങ്ങൾ പരിഗണിക്കും. മുകളിൽ രൂപപ്പെടുത്തിയ രണ്ട് അടിസ്ഥാന ആവശ്യകതകൾ നിറവേറ്റുന്ന പട്ടികകളാണ് ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്നതെന്ന് നമുക്ക് ഓർക്കാം.

ആദ്യത്തെ സാധാരണ രൂപം (1NF)

ഒരു പട്ടികയിൽ അടങ്ങിയിരിക്കുന്ന എല്ലാ ഡാറ്റയും ആറ്റോമിക് ആയിരിക്കണം എന്ന് ആദ്യ സാധാരണ ഫോം നിർദ്ദേശിക്കുന്നു(അവിഭാജ്യമായ). അനുബന്ധ ആറ്റോമിക് ഡാറ്റ തരങ്ങളുടെ ലിസ്റ്റ് നിർണ്ണയിക്കുന്നത് DBMS ആണ്. 1NF ആവശ്യകത പൂർണ്ണമായും സ്വാഭാവികമാണ്. ഓരോ റെക്കോർഡിന്റെയും ഓരോ ഫീൽഡിലും ഒരു മൂല്യം മാത്രമേ അടങ്ങിയിരിക്കാവൂ, അറേയോ മറ്റേതെങ്കിലും ഡാറ്റാ ഘടനയോ അല്ല എന്നാണ് ഇതിനർത്ഥം. 1NF-ൽ ഇല്ലാത്ത ഒരു പട്ടികയുടെ അർത്ഥവത്തായ ഒരു ഉദാഹരണം നൽകാം. ഒരു പ്രത്യേക വിഷയത്തിലെ വിദ്യാർത്ഥികളുടെ ഗ്രേഡുകളുടെ ലിസ്‌റ്റുകൾ നമുക്കിടാം.

റേറ്റിംഗ് ഫീൽഡിന്റെ മൂല്യം ആറ്റോമിക് അല്ലാത്തതിനാൽ, പട്ടിക 1NF ന്റെ ആവശ്യകതകൾ നിറവേറ്റുന്നില്ല.

റേറ്റിംഗുകളുടെ ഒരു ലിസ്റ്റ് അവതരിപ്പിക്കുന്നതിനുള്ള സാധ്യമായ മാർഗം ലേഖനത്തിനായുള്ള മാർഗ്ഗനിർദ്ദേശങ്ങളിൽ വിവരിച്ചിരിക്കുന്നു. "ഡിബി ഡിസൈൻ" 2.

രണ്ടാമത്തെ സാധാരണ രൂപം (2NF)

ഒരു പട്ടിക 1NF-ൽ ആണെങ്കിൽ രണ്ടാമത്തെ സാധാരണ രൂപത്തിലാണെന്ന് പറയപ്പെടുന്നു, കൂടാതെ ഓരോ നോൺ-കീ കോളവും പ്രാഥമിക കീയെ പൂർണ്ണമായും ആശ്രയിച്ചിരിക്കുന്നു.മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഓരോ ഫീൽഡിന്റെയും മൂല്യം പൂർണ്ണമായും പ്രാഥമിക കീയുടെ മൂല്യത്താൽ നിർണ്ണയിക്കപ്പെടണം. ഒരു പ്രാഥമിക കീയെ ആശ്രയിക്കുന്നത് കീയുടെ മൊത്തത്തിലുള്ള ആശ്രിതത്വമായാണ് മനസ്സിലാക്കുന്നത്, അല്ലാതെ അതിന്റെ വ്യക്തിഗത ഘടകത്തെയല്ല (ഒരു സംയോജിത കീയുടെ കാര്യത്തിൽ) എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. 2NF-ൽ ഇല്ലാത്ത ഒരു പട്ടികയുടെ ഉദാഹരണം പറയാം. ഇത് ചെയ്യുന്നതിന്, നമുക്ക് കാലാവസ്ഥാ പ്രവചനത്തിന്റെ ഉദാഹരണത്തിലേക്ക് മടങ്ങുകയും പട്ടികയിലേക്ക് മറ്റൊരു കോളം ചേർക്കുകയും ചെയ്യാം - സൂര്യോദയ സമയം (ഇത് പൂർണ്ണമായും വിശ്വസനീയമായ ഉദാഹരണമാണ്; കാലാവസ്ഥാ പ്രവചന സൈറ്റുകളിൽ ഇത്തരത്തിലുള്ള വിവരങ്ങൾ പലപ്പോഴും നൽകാറുണ്ട്).

ഞങ്ങൾ ഓർക്കുന്നതുപോലെ, ഈ പട്ടികയ്ക്ക് ഒരു സംയുക്ത കീ തീയതി+ദിവസത്തിന്റെ സമയം ഉണ്ട്. താപനില ഫീൽഡ് പൂർണ്ണമായും പ്രാഥമിക കീയെ ആശ്രയിച്ചിരിക്കുന്നു - അതിൽ പ്രശ്നങ്ങളൊന്നുമില്ല. എന്നാൽ സൺറൈസ് ഫീൽഡ് ഡേറ്റ് ഫീൽഡിനെ മാത്രം ആശ്രയിച്ചിരിക്കുന്നു.പകലിന്റെ സമയം സ്വാഭാവികമായും സൂര്യോദയ സമയത്തെ ബാധിക്കില്ല.

ഇവിടെ ചോദ്യം ചോദിക്കുന്നത് ഉചിതമാണ്: 2NF ന്റെ പ്രായോഗിക അർത്ഥം എന്താണ്? ഈ നിയന്ത്രണങ്ങളുടെ പ്രയോജനം എന്താണ്? ഇത് വലുതാണെന്ന് മാറുന്നു. മുകളിലുള്ള ഉദാഹരണത്തിൽ ഡവലപ്പർ 2NF ആവശ്യകതകൾ അവഗണിക്കുന്നുവെന്ന് നമുക്ക് പറയാം. ഒന്നാമതായി, വിളിക്കപ്പെടുന്നവ ആവർത്തനം- അനാവശ്യ ഡാറ്റയുടെ സംഭരണം. എല്ലാത്തിനുമുപരി, ഒരു നിശ്ചിത തീയതിയിലുള്ള ഒരു റെക്കോർഡിനായി സൂര്യോദയ സമയം ഇതിനകം സംഭരിച്ചിട്ടുണ്ടെങ്കിൽ, ഒരു നിശ്ചിത തീയതിയിലുള്ള മറ്റെല്ലാ റെക്കോർഡുകൾക്കും ഇത് സമാനമായിരിക്കണം, പൊതുവേ പറഞ്ഞാൽ, അത് സംഭരിക്കേണ്ട ആവശ്യമില്ല.

“ആയിരിക്കണം” എന്ന വാക്കുകൾ ശ്രദ്ധിക്കാം. ഇല്ലെങ്കിലോ? എല്ലാത്തിനുമുപരി, ഡാറ്റാബേസ് തലത്തിൽ ഇത് ഒരു തരത്തിലും നിയന്ത്രിക്കപ്പെടുന്നില്ല - പട്ടികയിലെ കീ സംയോജിതമാണ്, സമാനമായ തീയതികൾ ഉണ്ടാകാം (അർത്ഥത്തിന്റെ കാര്യത്തിൽ മിക്കവാറും ഉണ്ടാകും). ഔപചാരികമായ നിയന്ത്രണങ്ങളൊന്നും ("ഇത് സംഭവിക്കില്ല" എന്ന ഞങ്ങളുടെ ധാരണ അവയിലൊന്നല്ല) ഒരേ തീയതിയിലെ വ്യത്യസ്ത സൂര്യോദയ സമയങ്ങളെ സൂചിപ്പിക്കുന്നത് വിലക്കുന്നില്ല.

മൂന്നാമത്തെ സാധാരണ രൂപം (3NF)

ഒരു ടേബിൾ 2NF ആണെങ്കിൽ 3NF-ൽ ഉണ്ടെന്നും എല്ലാ നോൺ-കീ കോളങ്ങളും പരസ്പരം സ്വതന്ത്രമാണെന്നും പറയപ്പെടുന്നു.

നിരകളുടെ പരസ്പര ആശ്രിതത്വം ഇനിപ്പറയുന്ന രീതിയിൽ സൗകര്യപ്രദമായി മനസ്സിലാക്കാം: മറ്റൊന്ന് മാറ്റാതെ അവയിലൊന്ന് മാറ്റുന്നത് അസാധ്യമാണെങ്കിൽ നിരകൾ പരസ്പരം ആശ്രയിച്ചിരിക്കുന്നു.

3NF-ൽ ഇല്ലാത്ത ഒരു പട്ടികയുടെ ഒരു ഉദാഹരണം പറയാം. രാജ്യത്തിന്റെ വിവിധ പ്രദേശങ്ങളിൽ താമസിക്കുന്ന ആളുകളുടെ ഹോം ടെലിഫോൺ നമ്പറുകൾ സംഭരിക്കുന്നതിനുള്ള ലളിതമായ നോട്ട്ബുക്കിന്റെ ഒരു ഉദാഹരണം നോക്കാം.

ഈ പട്ടികയ്ക്ക് നോൺ-കീ കോളങ്ങളായ സിറ്റി, സിറ്റി കോഡ് എന്നിവയ്ക്കിടയിൽ ഒരു ആശ്രിതത്വം ഉണ്ട്, അതിനാൽ പട്ടിക 3NF-ൽ ഇല്ല.

സബ്ജക്ട് ഏരിയ വിശകലനം ചെയ്തുകൊണ്ട് ഡെവലപ്പർ മുകളിൽ പറഞ്ഞ ആശ്രിതത്വത്തിന്റെ സാന്നിധ്യം നിർണ്ണയിക്കുന്നു എന്നത് ശ്രദ്ധിക്കുക - ഔപചാരികമായ ഒരു രീതിയിലും അത്തരമൊരു കൂട്ടിയിടി കാണാൻ കഴിയില്ല. സബ്ജക്റ്റ് ഏരിയയുടെ സവിശേഷതകൾ മാറ്റുമ്പോൾ, നിരകൾ തമ്മിലുള്ള ആശ്രിതത്വം അപ്രത്യക്ഷമായേക്കാം. ഉദാഹരണത്തിന്, ഒരേ നഗരത്തിനുള്ളിൽ വ്യത്യസ്ത കോഡുകൾ നൽകിയിട്ടുണ്ടെങ്കിൽ (മോസ്കോയിലെ 495, 499 എന്നിവ പോലെ), 3NF ആവശ്യകതകളുടെ ലംഘനവുമായി ബന്ധപ്പെട്ട നിരകൾ മേലിൽ ബന്ധപ്പെട്ടിരിക്കില്ല.

റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സിദ്ധാന്തത്തിൽ, ഉയർന്ന ഓർഡർ ഫോമുകളും പരിഗണിക്കപ്പെടുന്നു - ബോയ്സ്-കോഡ് സാധാരണ രൂപം, 4NF, 5NF എന്നിവയും അതിലും ഉയർന്നതും. ഈ ഫോമുകൾക്ക് പ്രായോഗിക പ്രാധാന്യം ഇല്ല, കൂടാതെ ഡവലപ്പർമാർ, ചട്ടം പോലെ, എല്ലായ്പ്പോഴും 3NF ൽ നിർത്തുന്നു.

ഡാറ്റാബേസ് നോർമലൈസേഷൻ

തിരഞ്ഞെടുത്ത സാധാരണ രൂപത്തിലേക്ക് ഡാറ്റാബേസ് ടേബിളുകൾ കുറയ്ക്കുന്ന പ്രക്രിയയാണ് നോർമലൈസേഷൻ. 2NF-ലേക്കുള്ള നോർമലൈസേഷൻ, ഒരു ചട്ടം പോലെ, വിഘടനത്തിലേക്ക് വരുന്നു - ഒരു ടേബിൾ പലതായി വിഭജിക്കുന്നു. സാധാരണയായി ആശ്രിത (കണക്കുകൂട്ടിയ) നിരകൾ നീക്കം ചെയ്തുകൊണ്ട് 3NF-ലേക്കുള്ള നോർമലൈസേഷൻ സാധ്യമാക്കാം. ചില സന്ദർഭങ്ങളിൽ, 3NF-ലേക്ക് നോർമലൈസ് ചെയ്യുമ്പോൾ, നിങ്ങൾ വിഘടിപ്പിക്കുകയും വേണം.

മൾട്ടി-ടേബിൾ ഡാറ്റാബേസുകൾ, പട്ടികകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ, വിദേശ കീകൾ

പ്രായോഗികമായി, സിംഗിൾ-ടേബിൾ ഡാറ്റാബേസുകൾ വളരെ അപൂർവമാണ്, കാരണം ഒരു ഡൊമെയ്ൻ ഡാറ്റാബേസ് മോഡലിംഗ് വീക്ഷണകോണിൽ നിന്ന്, ഒരു പട്ടികയുടെ സാന്നിധ്യം ഒരു എന്റിറ്റിയുടെ സാന്നിധ്യം അർത്ഥമാക്കുന്നു. അതാകട്ടെ, നിരവധി എന്റിറ്റികളുടെ സാന്നിധ്യം സാധാരണയായി അവ തമ്മിലുള്ള ബന്ധങ്ങളുടെ സാന്നിധ്യം അർത്ഥമാക്കുന്നു.

ഒരു സമ്പൂർണ്ണ ഡാറ്റാബേസ് രൂപകൽപ്പനയുടെ ലക്ഷ്യം സജ്ജീകരിക്കാതെ, മൾട്ടി-ടേബിൾ ഡാറ്റാബേസുകളിൽ ബന്ധങ്ങൾ പ്രകടിപ്പിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ഒരു ഉദാഹരണം നോക്കാം.

ക്ലാസുകളായി തിരിച്ചിരിക്കുന്ന വിദ്യാർത്ഥികളും ചില വിഷയങ്ങൾ പഠിപ്പിക്കുന്ന അധ്യാപകരും ഉള്ള ഒരു സ്കൂളിലാണ് നമ്മൾ ഇടപെടുന്നതെന്ന് കരുതുക. ഞങ്ങൾ ഉടനടി നാല് എന്റിറ്റികളെ വേർതിരിക്കുന്നു: വിദ്യാർത്ഥികൾ, അധ്യാപകർ, ക്ലാസുകൾ, വസ്തുക്കൾ. ഈ എന്റിറ്റികൾ ഞങ്ങൾക്ക് ഇതിനകം നാല് പട്ടികകൾ നൽകുന്നു.

അടുത്തതായി, എന്റിറ്റി ആട്രിബ്യൂട്ടുകളുടെ പ്രശ്നം പരിഹരിക്കേണ്ടതുണ്ട് - ഞങ്ങൾ ഏത് തരത്തിലുള്ള വിവരങ്ങളാണ് സംഭരിക്കുക. ഞങ്ങളുടെ ഉദാഹരണം പ്രകടന ആവശ്യങ്ങൾക്ക് മാത്രമായതിനാൽ, സംഭരിച്ചിരിക്കുന്ന വിവരങ്ങളുടെ അളവ് കുറയ്ക്കാൻ ഞങ്ങൾ ശ്രമിക്കും. ഓരോ വിദ്യാർത്ഥിക്കും കുടുംബപ്പേരും ആദ്യനാമവും സംഭരിക്കാൻ ഞങ്ങൾ സമ്മതിക്കും, ക്ലാസിനായി - സമാന്തര നമ്പറും സമാന്തരമായി ക്ലാസിനെ തിരിച്ചറിയുന്ന അക്ഷരവും, അധ്യാപകന് - കുടുംബപ്പേര്, ആദ്യനാമം, രക്ഷാധികാരി, വിഷയത്തിന് - അതിന്റെ പേര് മാത്രം. .

ഇപ്പോൾ നമുക്ക് പ്രാഥമിക കീകൾ ഉപയോഗിച്ച് പ്രശ്നം പരിഹരിക്കേണ്ടതുണ്ട്. വിദ്യാർത്ഥികളുടെയും അധ്യാപകരുടെയും പട്ടികകൾക്ക് അടിസ്ഥാനപരമായി ഒരു കീ ഇല്ല, അതിനാൽ ഞങ്ങൾ അവയിൽ ഒരു സറോഗേറ്റ് സംഖ്യാ കീ അവതരിപ്പിക്കും - ഒരു നമ്പർ. ക്ലാസുകളുടെയും ഇനങ്ങളുടെയും പട്ടികകൾക്ക്, പൊതുവായി പറഞ്ഞാൽ, കീകളുണ്ട്. ക്ലാസുകളുടെ പട്ടികയിൽ, കീ സംയോജിതമാണ്, അത് പാരലൽ നമ്പർ + ലെറ്റർ ആട്രിബ്യൂട്ടുകളാൽ രൂപം കൊള്ളുന്നു, ഒബ്‌ജക്റ്റുകളുടെ പട്ടികയിൽ, ഒരു ലളിതമായ കീ ഒരൊറ്റ ഫീൽഡ് ഉൾക്കൊള്ളുന്നു - ഒബ്‌ജക്റ്റിന്റെ പേര്. ഞങ്ങൾ കീകളെ കുറിച്ച് സംസാരിച്ചപ്പോൾ, സറോഗേറ്റ് കീകൾ പലപ്പോഴും കാര്യക്ഷമത കാരണങ്ങളാലാണ് ചേർക്കുന്നത്, കോമ്പൗണ്ട് കീകൾ അല്ലെങ്കിൽ സ്ട്രിംഗുകൾ പോലെയുള്ള അസൌകര്യമുള്ള തരത്തിലുള്ള കീ ഫീൽഡുകൾ ഒഴിവാക്കാൻ ശ്രമിക്കുന്നതായി ഞങ്ങൾ സൂചിപ്പിച്ചത് ഓർക്കുക. അത് ഞങ്ങൾ ചെയ്യും. ഓരോ ടേബിളിലേക്കും ഒരു സറോഗേറ്റ് സംഖ്യാ കീ ചേർക്കാം.

തൽഫലമായി, വിവരിച്ച എന്റിറ്റികളുമായി ബന്ധപ്പെട്ട ഇനിപ്പറയുന്ന പട്ടികകളുടെ കൂട്ടം ഞങ്ങൾക്ക് ലഭിക്കും.

നമ്മൾ ഏത് വിഷയ മേഖലയാണ് കൈകാര്യം ചെയ്യുന്നതെന്ന് മനസിലാക്കുമ്പോൾ, ഞങ്ങളുടെ എന്റിറ്റികൾ സ്വന്തമായി നിലവിലില്ലെന്ന് ഞങ്ങൾക്കറിയാം - ഞങ്ങൾ മുകളിൽ വിവരിച്ച ചില ബന്ധങ്ങളാൽ അവ ബന്ധപ്പെട്ടിരിക്കുന്നു. എന്നാൽ അവയെ സാങ്കേതികമായി എങ്ങനെ ബന്ധിപ്പിക്കാം? അധിക ഫീൽഡുകളും അധിക പട്ടികകളും അവതരിപ്പിക്കാതെ നിങ്ങൾക്ക് ഇവിടെ ചെയ്യാൻ കഴിയില്ല. എന്റിറ്റികൾ തമ്മിലുള്ള ബന്ധം ക്രമത്തിൽ നോക്കാം.

ഒരു നിശ്ചിത ക്ലാസിലേക്ക് ഒരു വിദ്യാർത്ഥിയെ അസൈൻ ചെയ്യാൻ, "വിദ്യാർത്ഥി" പട്ടികയിൽ ഞങ്ങൾ ഒരു അധിക ഫീൽഡ് ക്ലാസ് നമ്പർ ചേർക്കുന്നു. (അതിന്റെ തരം "ക്ലാസ്" പട്ടികയിലെ ക്ലാസ് നമ്പർ ഫീൽഡിന്റെ തരവുമായി പൂർണ്ണമായും പൊരുത്തപ്പെടണമെന്ന് വ്യക്തമാണ്.) ഇപ്പോൾ നമുക്ക് ക്ലാസ് നമ്പർ ഫീൽഡുകളുടെ പൊരുത്തപ്പെടുത്തൽ മൂല്യങ്ങൾ ഉപയോഗിച്ച് "വിദ്യാർത്ഥി", "ക്ലാസ്" പട്ടികകൾ ലിങ്ക് ചെയ്യാം. (ഞങ്ങൾ ഈ ഫീൽഡുകൾക്ക് ഒരേ പേര് നൽകിയത് യാദൃശ്ചികമല്ല, പ്രായോഗികമായി ഇത് പലപ്പോഴും കണക്റ്റിംഗ് ഫീൽഡുകൾ എളുപ്പത്തിൽ നാവിഗേറ്റ് ചെയ്യുന്നതിനാണ് ചെയ്യുന്നത്). “ക്ലാസ്” ടേബിളിലെ ഒരു റെക്കോർഡ് “വിദ്യാർത്ഥി” പട്ടികയിലെ നിരവധി റെക്കോർഡുകളുമായി പൊരുത്തപ്പെടാമെന്നത് ശ്രദ്ധിക്കുക (പ്രായോഗികമായി മിക്കവാറും യോജിക്കുന്നു - ഒരു വിദ്യാർത്ഥിയുടെ ക്ലാസ് സങ്കൽപ്പിക്കാൻ പ്രയാസമാണ്). അത്തരം പട്ടികകൾ ബന്ധവുമായി ബന്ധപ്പെട്ടതാണെന്ന് പറയപ്പെടുന്നു " ഒന്നിൽ നിന്ന് പലതും" കൂടാതെ "വിദ്യാർത്ഥി" പട്ടികയിലെ ക്ലാസ് നമ്പർ ഫീൽഡ് വിളിക്കുന്നു വിദേശ കീ. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, വിദേശ കീകളുടെ ഉദ്ദേശ്യം പട്ടികകൾ ലിങ്ക് ചെയ്യുക എന്നതാണ്. ഒരു വിദേശ കീ എപ്പോഴും ബന്ധപ്പെട്ട പട്ടികയുടെ പ്രാഥമിക കീയെ സൂചിപ്പിക്കുന്നു എന്നത് ശ്രദ്ധിക്കുക (അതായത് വിദേശ കീ "പല" വശത്താണ്). ഒരു വിദേശിയുമായി ബന്ധപ്പെട്ട പ്രാഥമിക കീയെ വിളിക്കുന്നു മാതാപിതാക്കളുടെ, ഈ പദം വളരെ കുറവാണ് ഉപയോഗിക്കുന്നതെങ്കിലും.

മൈക്രോസോഫ്റ്റ് ആക്സസ് ശൈലിയിലുള്ള ഒരു ഡയഗ്രം ഉപയോഗിച്ച് നമുക്ക് ഇത് ചിത്രീകരിക്കാം (ആക്സസ് "ഡാറ്റ സ്കീമ" എന്നതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ലേഖനത്തിൽ എഴുതിയിരിക്കുന്നു "ഡാറ്റ വിവരണം" 2).

ഇനി നമുക്ക് അധ്യാപകരെയും വിഷയങ്ങളെയും കുറിച്ച് ചിന്തിക്കാം. വിഷയ മേഖല വിശകലനം ചെയ്യുന്നു (ഇതാണ് ഒരേയൊരു മാർഗ്ഗം - എല്ലാത്തിനുമുപരി, ഔപചാരിക മാതൃകയിൽ നിന്ന് തന്നെ കാര്യങ്ങളുടെ യഥാർത്ഥ അവസ്ഥ വേർതിരിച്ചെടുക്കുന്നത് അസാധ്യമാണ്), “അധ്യാപകൻ”, “വിഷയം” എന്നീ എന്റിറ്റികൾ തമ്മിലുള്ള ബന്ധം വ്യത്യസ്തമാണെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കുന്നു. മുകളിൽ ചർച്ച ചെയ്തതിൽ നിന്ന്. എല്ലാത്തിനുമുപരി, നിരവധി അധ്യാപകർക്ക് ഒരു വിഷയം പഠിപ്പിക്കാൻ മാത്രമല്ല, ഒരു അധ്യാപകന് നിരവധി വിഷയങ്ങൾ പഠിപ്പിക്കാനും കഴിയും. അതിനാൽ, ഈ സ്ഥാപനങ്ങൾ തമ്മിൽ ഒരു ബന്ധമുണ്ട് " പലതും പലതും" അധിക ഫീൽഡുകൾ അവതരിപ്പിക്കാതെ നിങ്ങൾക്ക് ഇവിടെ ചെയ്യാൻ കഴിയില്ല (ഇത് പരീക്ഷിക്കുക!). ഒരു അധിക പട്ടിക അവതരിപ്പിച്ചുകൊണ്ട് പലതും പലതുമായ ബന്ധങ്ങൾ എല്ലായ്പ്പോഴും പരിഹരിക്കപ്പെടും. അതായത്, ഇനിപ്പറയുന്ന ഘടനയുള്ള "ടീച്ചർ-സബ്ജക്റ്റ്" പട്ടിക ഞങ്ങൾ സംഘടിപ്പിക്കുന്നു:

പട്ടിക "അധ്യാപക വിഷയം"

ഈ പട്ടികയ്‌ക്ക് അതിന്റെ രണ്ട് ഫീൽഡുകളിൽ നിന്ന് രൂപീകരിച്ച ഒരു സംയുക്ത കീ ഉണ്ട്. "ടീച്ചർ" ടേബിളും "സബ്ജക്റ്റ്" ടേബിളും ഈ ടേബിളുമായി ഒന്നിൽ നിന്ന് നിരവധി ബന്ധത്തിൽ ബന്ധപ്പെട്ടിരിക്കുന്നു (തീർച്ചയായും, രണ്ട് സാഹചര്യങ്ങളിലും "പലതും" "ടീച്ചർ-സബ്ജക്റ്റ്" വശത്താണ്). അതനുസരിച്ച്, "ടീച്ചർ-സബ്ജക്റ്റ്" ടേബിളിൽ രണ്ട് വിദേശ കീകൾ ഉണ്ട് (രണ്ടും ഒരു സംയോജിത പ്രൈമറി കീയുടെ ഭാഗങ്ങളാണ്, അത് നിരോധിക്കപ്പെട്ടിട്ടില്ല), അത് അനുബന്ധ പട്ടികകളുമായി ബന്ധിപ്പിക്കുന്നതിന് സഹായിക്കുന്നു.

പ്രായോഗികമായി, പരിഗണിക്കപ്പെടുന്ന "ഒന്നിൽ നിന്ന് പലതും" "പലതും പലതും" ബന്ധങ്ങൾക്ക് പുറമേ, "" എന്ന ബന്ധവുമുണ്ട്. ഒന്ന് മുതൽ ഒന്ന് വരെ" ഒരു സൈദ്ധാന്തിക വീക്ഷണകോണിൽ, അത്തരമൊരു ബന്ധം താൽപ്പര്യമുള്ളതല്ല, കാരണം പരസ്പരം ബന്ധിപ്പിച്ചിരിക്കുന്ന രണ്ട് പട്ടികകൾ എല്ലായ്പ്പോഴും ഒന്നായി സംയോജിപ്പിക്കാം. എന്നിരുന്നാലും, യഥാർത്ഥ ഡാറ്റാബേസുകളിൽ, ഡാറ്റാ പ്രോസസ്സിംഗ് ഒപ്റ്റിമൈസ് ചെയ്യാൻ ഒരു-ടു-വൺ ബന്ധം ഉപയോഗിക്കുന്നു. നമുക്ക് ഇത് ഒരു ഉദാഹരണത്തിലൂടെ വിശദീകരിക്കാം.

ആളുകളെക്കുറിച്ചുള്ള വ്യത്യസ്തമായ ധാരാളം വിവരങ്ങൾ ഞങ്ങൾ സംഭരിക്കുന്നു എന്ന് പറയാം - എല്ലാത്തരം ഡോക്യുമെന്റുകൾ, ടെലിഫോൺ നമ്പറുകൾ, വിലാസങ്ങൾ മുതലായവയിൽ നിന്നുള്ള ഡാറ്റ. മിക്കവാറും, ഈ ഡാറ്റയിൽ ഭൂരിഭാഗവും വളരെ അപൂർവ്വമായി മാത്രമേ ഉപയോഗിക്കപ്പെടുകയുള്ളൂ. പലപ്പോഴും നമുക്ക് അവസാന നാമം, ആദ്യ നാമം, രക്ഷാധികാരി, ടെലിഫോൺ നമ്പർ എന്നിവ മാത്രമേ ആവശ്യമുള്ളൂ. അപ്പോൾ രണ്ട് ടേബിളുകൾ ഓർഗനൈസുചെയ്‌ത് അവയെ ഒന്ന്-ടു-വൺ ബന്ധത്തിൽ ബന്ധപ്പെടുത്തുന്നത് അർത്ഥമാക്കുന്നു. പതിവായി ഉപയോഗിക്കുന്ന വിവരങ്ങൾ ഒരു (ചെറിയ) പട്ടികയിലും ബാക്കിയുള്ളവ മറ്റൊന്നിലും സൂക്ഷിക്കുക. സ്വാഭാവികമായും, വൺ-ടു-വൺ ബന്ധവുമായി ബന്ധപ്പെട്ട പട്ടികകൾക്ക് ഒരേ പ്രാഥമിക താക്കോലാണുള്ളത്.

സമഗ്രത നിയമങ്ങൾ

റിലേഷണൽ മോഡൽ ഡാറ്റാബേസ് സമഗ്രതയ്ക്കുള്ള രണ്ട് പൊതു നിയമങ്ങൾ നിർവ്വചിക്കുന്നു: ഒബ്ജക്റ്റ് ഇന്റഗ്രിറ്റി, റഫറൻഷ്യൽ ഇന്റഗ്രിറ്റി.

സമഗ്രത നിയമം വസ്തുക്കൾവളരെ ലളിതമാണ്. അത് ടേബിൾ പ്രൈമറി കീകളിൽ null (null) മൂല്യങ്ങൾ അടങ്ങിയിരിക്കരുത്.

റഫറൻഷ്യൽ ഇന്റഗ്രിറ്റി റൂൾ വിദേശ കീകളിൽ അവയുടെ പാരന്റ് കീകളുമായി പൊരുത്തപ്പെടാത്ത മൂല്യങ്ങൾ അടങ്ങിയിരിക്കരുതെന്ന് ആവശ്യപ്പെടുന്നു. മുകളിൽ ചർച്ച ചെയ്ത ഉദാഹരണത്തിലേക്ക് മടങ്ങുമ്പോൾ, ഉദാഹരണത്തിന്, "ക്ലാസ്സുകൾ" പട്ടികയിൽ സൂചിപ്പിച്ചിരിക്കുന്ന ക്ലാസിൽ മാത്രമേ വിദ്യാർത്ഥികൾ ഉൾപ്പെട്ടിട്ടുള്ളൂവെന്ന് ഞങ്ങൾ ആവശ്യപ്പെടണം.

മിക്ക DBMS-കൾക്കും ഡാറ്റയുടെ സമഗ്രത നിരീക്ഷിക്കാൻ കഴിയും (തീർച്ചയായും, ഡാറ്റാ ഘടനകളെ വിവരിക്കുന്ന ഘട്ടത്തിൽ ഇതിന് ഡെവലപ്പറിൽ നിന്നുള്ള അനുബന്ധ ശ്രമങ്ങൾ ആവശ്യമാണ്). പ്രത്യേകിച്ചും, റഫറൻഷ്യൽ സമഗ്രത നിലനിർത്താൻ മെക്കാനിസങ്ങൾ ഉപയോഗിക്കുന്നു കാസ്കേഡിംഗ്പ്രവർത്തനങ്ങൾ. കാസ്‌കേഡിംഗ് സൂചിപ്പിക്കുന്നത്, ഒരു "മാതാപിതാക്കളുടെ" ടേബിളിൽ നിന്ന് ഒരു ടേബിളിൽ നിന്ന് ഒരു റെക്കോർഡ് ഇല്ലാതാക്കുമ്പോൾ, ഒന്നിൽ നിന്ന് നിരവധി ബന്ധങ്ങൾ ഉപയോഗിച്ച് മറ്റൊരു ടേബിളിലേക്ക് കണക്റ്റ് ചെയ്യുമ്പോൾ, ബന്ധപ്പെട്ട എല്ലാ റെക്കോർഡുകളും "നിരവധി" പട്ടികയിൽ നിന്ന് സ്വയമേവ ഇല്ലാതാക്കപ്പെടും (DBMS തന്നെ, ഉപയോക്തൃ ഇടപെടൽ ഇല്ലാതെ). ഇത് സ്വാഭാവികമാണ്, കാരണം അത്തരം രേഖകൾ “വായുവിൽ തൂങ്ങിക്കിടക്കുന്നു”; അവ മേലിൽ ഒന്നിനോടും ബന്ധപ്പെട്ടിട്ടില്ല.

ഇൻഡെക്സിംഗ്

പ്രായോഗിക പ്രയോഗത്തിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഇൻഡെക്സിംഗ് വളരെ പ്രധാനമാണ്, എന്നാൽ ശുദ്ധമായ സിദ്ധാന്തത്തിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന് ഐച്ഛികമാണ്. ഇൻഡെക്‌സിംഗിന്റെ പ്രധാന ലക്ഷ്യം തിരയൽ ഒപ്റ്റിമൈസ് ചെയ്യുക (വേഗത കൂട്ടുക) ആണ് (അതനുസരിച്ച്, ഡാറ്റാബേസിലുള്ള മറ്റ് ചില പ്രവർത്തനങ്ങൾ). ഏത് സാഹചര്യത്തിലും ഇൻഡെക്‌സിംഗ് ചെയ്യുന്നതിന് അധിക ഉറവിടങ്ങൾ ആവശ്യമാണ് (പ്രത്യേക സൂചിക ഫയലുകൾ മിക്കപ്പോഴും ഫിസിക്കൽ തലത്തിലാണ് സൃഷ്ടിക്കുന്നത്). ഇൻഡെക്‌സിംഗ് ഡാറ്റ പരിഷ്‌ക്കരണവുമായി ബന്ധപ്പെട്ട പ്രവർത്തനങ്ങളെ മന്ദഗതിയിലാക്കിയേക്കാം; അതിനാൽ, അപൂർവ്വമായി പരിഷ്‌ക്കരിക്കപ്പെടുന്നതും പതിവായി തിരയുന്നതുമായ പട്ടികകൾ സാധാരണയായി സൂചികയിലാക്കുന്നു.

ഒരു സൂചിക ഫയൽ ഒരു സാധാരണ പുസ്തക സൂചികയുമായി വളരെ സാമ്യമുള്ളതാണ്. ഓരോ സൂചിക മൂല്യത്തിനും, ആ മൂല്യം ഉൾക്കൊള്ളുന്ന പട്ടിക വരികളുടെ ഒരു ലിസ്റ്റ് സംഭരിച്ചിരിക്കുന്നു. അതനുസരിച്ച്, തിരയാൻ, നിങ്ങൾ മുഴുവൻ പട്ടികയിലൂടെയും നോക്കേണ്ടതില്ല - സൂചികയിലേക്ക് നോക്കുക. എന്നിരുന്നാലും, റെക്കോർഡുകൾ പരിഷ്കരിക്കുമ്പോൾ, നിങ്ങൾ സൂചിക പുനർനിർമ്മിക്കേണ്ടതായി വന്നേക്കാം. ഇതിന് അധിക സമയമെടുക്കുന്നു.

തീർച്ചയായും, അടിസ്ഥാന കമ്പ്യൂട്ടർ സയൻസ് കോഴ്‌സിന്റെ ഭാഗമായി റിലേഷണൽ ഡാറ്റാബേസുകളുടെ സിദ്ധാന്തം അവതരിപ്പിക്കുന്നതിൽ യാതൊരു ചോദ്യവുമില്ല! എന്നിരുന്നാലും, ഈ ലേഖനം ഞങ്ങളുടെ വിജ്ഞാനകോശത്തിന് വളരെ പ്രധാനമാണ്, കാരണം ഈ സാഹചര്യത്തിൽ ഞങ്ങൾ പാഠങ്ങളിൽ പൂർണ്ണമായി അവതരിപ്പിക്കാൻ കഴിയാത്ത മെറ്റീരിയലുകളാണ് കൈകാര്യം ചെയ്യുന്നത്, പക്ഷേ അധ്യാപകൻ അത് മാസ്റ്റർ ചെയ്യണം. എന്തുകൊണ്ട്?

ഒന്നാമതായി, അടിസ്ഥാന കോഴ്സിന്റെ ചട്ടക്കൂടിനുള്ളിൽ നിരവധി ആശയങ്ങൾ പഠിക്കുന്നതിനാൽ. ഇതിൽ ഡാറ്റയുടെയും ടേബിൾ കീകളുടെയും ടേബിൾ വ്യൂ ഉൾപ്പെടുന്നു. മൊത്തത്തിലുള്ള ചിത്രം അവതരിപ്പിക്കാതെ ചില ആശയങ്ങൾ മാത്രം കൃത്യമായും കൃത്യമായും അവതരിപ്പിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണെന്ന് നമുക്കെല്ലാവർക്കും അറിയാം.

രണ്ടാമതായി, കുട്ടികളുമായി ലളിതമായ ഡാറ്റാബേസ് അന്വേഷണങ്ങൾ നടത്തുന്നു (പ്രസക്തമായ മെറ്റീരിയൽ ലേഖനത്തിൽ അവതരിപ്പിച്ചിരിക്കുന്നു "ഡാറ്റ പ്രോസസ്സിംഗ്" 2), റിലേഷണൽ സിദ്ധാന്തത്തിന്റെ വീക്ഷണകോണിൽ നിന്ന് ശരിയായ പട്ടികകൾ കൈകാര്യം ചെയ്യേണ്ടത് ആവശ്യമാണ്. ഈ പട്ടികകൾ ശരിയാണെന്ന് വിദ്യാർത്ഥികളോട് വിശദീകരിക്കേണ്ട ആവശ്യമില്ല, എന്നാൽ "എങ്കിൽ ..., പിന്നെ പട്ടിക തെറ്റായിരിക്കും", എന്നാൽ മോശം ഉദാഹരണങ്ങൾ ഉപയോഗിക്കുന്നത് അസ്വീകാര്യമാണ്.

ഒരു പ്രത്യേക കമ്പ്യൂട്ടർ സയൻസ് കോഴ്സിൽ, സാഹചര്യം അടിസ്ഥാനപരമായി വ്യത്യസ്തമായിരിക്കാം. സ്പെഷ്യലൈസ്ഡ് ക്ലാസുകളിലെ ഏറ്റവും പ്രധാനപ്പെട്ടതും വളരെ ഉൽപ്പാദനക്ഷമവുമായ ജോലി പ്രോജക്റ്റ് വർക്കാണ്. വിദ്യാഭ്യാസ പ്രോജക്റ്റുകളുടെ ഭാഗമായി, ലളിതമായ ഡാറ്റാബേസുകൾ വികസിപ്പിക്കുന്നത് സാധ്യമാണ്, അത് ആവശ്യമാണ്, ഇവിടെ അവതരിപ്പിച്ച സിദ്ധാന്തത്തിന്റെ അടിത്തറയില്ലാതെ ഒരാൾക്ക് ചെയ്യാൻ കഴിയില്ല. എന്നിരുന്നാലും, ഇനിപ്പറയുന്നവ കണക്കിലെടുക്കണം:

മാതൃകാപരമായ വിഷയ മേഖലകൾ വളരെ വലുതായിരിക്കരുത്;

അവർ വിദ്യാർത്ഥികൾക്ക് വളരെ പരിചിതരായിരിക്കണം (ഈ അർത്ഥത്തിൽ, എല്ലാവർക്കും മടുത്തിരുന്ന "സ്കൂൾ" പ്രോജക്റ്റ് ഏറ്റവും മോശം തിരഞ്ഞെടുപ്പല്ല!);

സിദ്ധാന്തത്തിന്റെ അടിസ്ഥാനകാര്യങ്ങൾ ശ്രദ്ധിച്ച ശേഷം വിദ്യാർത്ഥികൾക്ക് സ്വയം എന്തെങ്കിലും രൂപകൽപ്പന ചെയ്യാൻ കഴിയുമെന്ന് പ്രതീക്ഷിക്കുന്നത് നിഷ്കളങ്കമാണ്. നിങ്ങളുടെ പ്രവൃത്തികളെ വിശദമായി ന്യായീകരിച്ചുകൊണ്ട് നിങ്ങൾ അവരോടൊപ്പം ഓരോ ഘട്ടങ്ങളിലൂടെയും കടന്നുപോകണം.

എല്ലാ ആധുനിക ഡാറ്റാബേസുകളും CBO (കോസ്റ്റ് ബേസ്ഡ് ഒപ്റ്റിമൈസേഷൻ), കോസ്റ്റ് ഒപ്റ്റിമൈസേഷൻ ഉപയോഗിക്കുന്നു. ഓരോ പ്രവർത്തനത്തിനും അതിന്റെ "ചെലവ്" നിർണ്ണയിക്കപ്പെടുന്നു, തുടർന്ന് "വിലകുറഞ്ഞ" പ്രവർത്തന ശൃംഖലകൾ ഉപയോഗിച്ച് അഭ്യർത്ഥനയുടെ ആകെ ചെലവ് കുറയ്ക്കുന്നു എന്ന വസ്തുതയിലാണ് അതിന്റെ സാരാംശം.

കോസ്റ്റ് ഒപ്റ്റിമൈസേഷൻ നന്നായി മനസ്സിലാക്കാൻ, രണ്ട് ടേബിളുകളിൽ ചേരുന്നതിനുള്ള മൂന്ന് പൊതു വഴികൾ ഞങ്ങൾ നോക്കും കൂടാതെ ഒരു ലളിതമായ ജോയിൻ ക്വറി പോലും ഒപ്റ്റിമൈസറിന്റെ പേടിസ്വപ്നമായി മാറുന്നത് എങ്ങനെയെന്ന് നോക്കാം. ഞങ്ങളുടെ ചർച്ചയിൽ, ഞങ്ങൾ സമയ സങ്കീർണ്ണതയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും, എന്നിരുന്നാലും ഒപ്റ്റിമൈസർ പ്രോസസ്സർ ഉറവിടങ്ങൾ, മെമ്മറി, I/O പ്രവർത്തനങ്ങൾ എന്നിവയുടെ അടിസ്ഥാനത്തിൽ "ചെലവ്" കണക്കാക്കുന്നു. സമയ സങ്കീർണ്ണത ഒരു ഏകദേശ ആശയമാണ്, ആവശ്യമായ പ്രോസസർ ഉറവിടങ്ങൾ നിർണ്ണയിക്കാൻ, നിങ്ങൾ കൂട്ടിച്ചേർക്കൽ, ഇഫ് സ്റ്റേറ്റ്‌മെന്റുകൾ, ഗുണനം, ആവർത്തനം മുതലായവ ഉൾപ്പെടെയുള്ള എല്ലാ പ്രവർത്തനങ്ങളും കണക്കാക്കേണ്ടതുണ്ട്.

കൂടാതെ:

• ഓരോ ഹൈ-ലെവൽ ഓപ്പറേഷനും നടത്തുന്നതിന്, പ്രോസസർ വ്യത്യസ്തമായ ലോ-ലെവൽ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു.
• പ്രൊസസർ പ്രവർത്തനങ്ങളുടെ വില (സൈക്കിളുകളുടെ കാര്യത്തിൽ) വ്യത്യസ്ത തരം പ്രോസസ്സറുകൾക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു, അതായത്, ഇത് നിർദ്ദിഷ്ട സിപിയു ആർക്കിടെക്ചറിനെ ആശ്രയിച്ചിരിക്കുന്നു.

അതിനാൽ, സങ്കീർണ്ണതയുടെ രൂപത്തിൽ നമുക്ക് വിലയിരുത്താൻ എളുപ്പമായിരിക്കും. എന്നാൽ മിക്കപ്പോഴും ഡാറ്റാബേസ് പ്രകടനം ഡിസ്ക് സബ്സിസ്റ്റം വഴി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, അല്ലാതെ പ്രോസസർ ഉറവിടങ്ങളല്ല.

ബി-ട്രീസിൽ നോക്കിയപ്പോൾ ഞങ്ങൾ അവരെക്കുറിച്ച് സംസാരിച്ചു. നിങ്ങൾ ഓർക്കുന്നതുപോലെ, സൂചികകൾ ഇതിനകം അടുക്കിയിരിക്കുന്നു. വഴിയിൽ, മറ്റ് തരത്തിലുള്ള സൂചികകൾ ഉണ്ട്, ഉദാഹരണത്തിന്, ബിറ്റ്മാപ്പ് സൂചിക. എന്നാൽ ബി-ട്രീ സൂചികകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ സിപിയു, മെമ്മറി, ഡിസ്ക് ഉപയോഗം എന്നിവയിൽ അവ ഒരു പ്രയോജനവും നൽകുന്നില്ല. കൂടാതെ, പ്ലാൻ നിർവ്വഹിക്കുന്നതിനുള്ള ചെലവ് കുറയ്ക്കാൻ ഇത് സഹായിക്കുമെങ്കിൽ, നിലവിലുള്ള അന്വേഷണങ്ങൾക്കായി പല ആധുനിക ഡാറ്റാബേസുകളും ചലനാത്മകമായി താൽക്കാലിക സൂചികകൾ സൃഷ്ടിക്കാൻ കഴിയും.

4.4.2. അപ്പീൽ രീതികൾ

യൂണിയൻ ഓപ്പറേറ്റർമാരെ ഉപയോഗിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾ ആദ്യം ആവശ്യമായ ഡാറ്റ നേടണം. ഇനിപ്പറയുന്ന വഴികളിൽ നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും.

• പൂർണ പരിശോധന.ഡാറ്റാബേസ് മുഴുവൻ പട്ടികയും സൂചികയും വായിക്കുന്നു. നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, ഡിസ്ക് സബ്സിസ്റ്റത്തിന് ഒരു പട്ടികയേക്കാൾ ഒരു സൂചിക വായിക്കുന്നത് വിലകുറഞ്ഞതാണ്.
• റേഞ്ച് സ്കാനിംഗ്.ഉദാഹരണത്തിന്, നിങ്ങൾ എവിടെ വയസ്സ് > 20 വയസ്സും വയസ്സും പോലുള്ള പ്രവചനങ്ങൾ ഉപയോഗിക്കുമ്പോൾ ഉപയോഗിക്കുന്നു< 40. Конечно, для сканирования диапазона индекса вам нужно иметь индекс для поля AGE.

  ലേഖനത്തിന്റെ ആദ്യ ഭാഗത്തിൽ, ഒരു ശ്രേണി അന്വേഷണത്തിന്റെ സമയ സങ്കീർണ്ണത M + log(N) ആയി നിർവചിച്ചിരിക്കുന്നതായി ഞങ്ങൾ ഇതിനകം കണ്ടെത്തി, ഇവിടെ N എന്നത് സൂചികയിലെ ഡാറ്റയുടെ എണ്ണമാണ്, കൂടാതെ M എന്നത് അതിനുള്ളിലെ വരികളുടെ കണക്കാക്കിയ എണ്ണമാണ്. പരിധി. സ്ഥിതിവിവരക്കണക്കുകൾക്ക് നന്ദി, ഈ രണ്ട് വേരിയബിളുകളുടെയും മൂല്യങ്ങൾ ഞങ്ങൾക്കറിയാം. ഒരു റേഞ്ച് സ്കാൻ സൂചികയുടെ ഒരു ഭാഗം മാത്രമേ വായിക്കൂ, അതിനാൽ പ്രവർത്തനത്തിന് ഒരു പൂർണ്ണ സ്കാനേക്കാൾ കുറവാണ് ചിലവ്.

• അദ്വിതീയ മൂല്യങ്ങൾക്കായി സ്കാൻ ചെയ്യുക.സൂചികയിൽ നിന്ന് നിങ്ങൾക്ക് ഒരു മൂല്യം മാത്രം ലഭിക്കേണ്ട സന്ദർഭങ്ങളിൽ ഉപയോഗിക്കുന്നു.
• വരി ഐഡി വഴി ആക്‌സസ്സ്.ഡാറ്റാബേസ് ഒരു സൂചിക ഉപയോഗിക്കുകയാണെങ്കിൽ, മിക്കപ്പോഴും അത് അതുമായി ബന്ധപ്പെട്ട വരികൾക്കായി തിരയുന്നതായിരിക്കും. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഇനിപ്പറയുന്ന അഭ്യർത്ഥന നടത്തുന്നു:

  28 വയസ്സുള്ള വ്യക്തിയിൽ നിന്ന് അവസാനത്തെ പേര്, FIRSTNAME തിരഞ്ഞെടുക്കുക
  ഞങ്ങൾക്ക് പ്രായ കോളത്തിൽ ഒരു സൂചിക ഉണ്ടെങ്കിൽ, ഒപ്റ്റിമൈസർ എല്ലാ 28 വയസ്സുകാരെയും കണ്ടെത്തുന്നതിന് സൂചിക ഉപയോഗിക്കും, തുടർന്ന് സൂചികയിൽ പ്രായ വിവരങ്ങൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ എന്നതിനാൽ പട്ടികയിലെ അനുബന്ധ വരികളുടെ ഐഡികൾ അന്വേഷിക്കും.

  ഞങ്ങൾക്ക് മറ്റൊരു അഭ്യർത്ഥന ഉണ്ടെന്ന് പറയാം:

  വ്യക്തിയിൽ നിന്ന് TYPE_PERSON.CATEGORY തിരഞ്ഞെടുക്കുക, TYPE_PERSON എവിടെയാണ് PERSON.AGE = TYPE_PERSON.AGE
  TYPE_PERSON എന്നതുമായി ലയിപ്പിക്കാൻ, PERSON നിരയിലെ ഒരു സൂചിക ഉപയോഗിക്കും. എന്നാൽ PERSON പട്ടികയിൽ നിന്ന് ഞങ്ങൾ വിവരങ്ങൾ അഭ്യർത്ഥിക്കാത്തതിനാൽ, വരി ഐഡികൾ വഴി ആരും അത് ആക്‌സസ് ചെയ്യില്ല.

  I/O യുടെ കാര്യത്തിൽ ഇത് ചെലവേറിയതിനാൽ ഈ സമീപനം വളരെ കുറച്ച് കോളുകൾക്ക് മാത്രമേ അനുയോജ്യമാകൂ. നിങ്ങളുടെ ഐഡി ഇടയ്ക്കിടെ ആക്‌സസ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, ഒരു പൂർണ്ണ സ്കാൻ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.

• മറ്റ് രീതികൾ. ഒറാക്കിൾ ഡോക്യുമെന്റേഷനിൽ നിങ്ങൾക്ക് അവയെക്കുറിച്ച് വായിക്കാം. വ്യത്യസ്ത ഡാറ്റാബേസുകൾ വ്യത്യസ്ത പേരുകൾ ഉപയോഗിച്ചേക്കാം, എന്നാൽ തത്വങ്ങൾ എല്ലായിടത്തും ഒന്നുതന്നെയാണ്.

4.4.3. യൂണിയൻ പ്രവർത്തനങ്ങൾ

അതിനാൽ, ഡാറ്റ എങ്ങനെ നേടാമെന്ന് ഞങ്ങൾക്കറിയാം, അത് സംയോജിപ്പിക്കാനുള്ള സമയമാണിത്. എന്നാൽ ആദ്യം, നമുക്ക് ചില പുതിയ നിബന്ധനകൾ നിർവചിക്കാം: ആന്തരിക ആശ്രിതത്വങ്ങളും ബാഹ്യ ആശ്രിതത്വങ്ങളും. ആശ്രിതത്വം ഇതായിരിക്കാം:

• മേശ,
• സൂചിക,
• മുമ്പത്തെ പ്രവർത്തനത്തിന്റെ ഇന്റർമീഡിയറ്റ് ഫലം (ഉദാഹരണത്തിന്, മുൻ ജോയിൻ).

നമ്മൾ രണ്ട് ഡിപൻഡൻസികൾ സംയോജിപ്പിക്കുമ്പോൾ, ലയന അൽഗോരിതങ്ങൾ അവയെ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു. A JOIN B എന്നത് A, B എന്നിവയുടെ യൂണിയൻ ആണെന്ന് പറയാം, ഇവിടെ A എന്നത് ഒരു ബാഹ്യ ആശ്രിതത്വവും B എന്നത് ആന്തരിക ആശ്രിതത്വവുമാണ്.

മിക്കപ്പോഴും, A JOIN B യുടെ വില B JOIN A യുടെ വിലയ്ക്ക് തുല്യമല്ല.

ബാഹ്യ ആശ്രിതത്വത്തിൽ N ഘടകങ്ങളും ആന്തരിക ആശ്രിതത്വത്തിൽ M-ഉം അടങ്ങിയിരിക്കുന്നുവെന്ന് നമുക്ക് അനുമാനിക്കാം. നിങ്ങൾ ഓർക്കുന്നതുപോലെ, സ്ഥിതിവിവരക്കണക്കുകൾക്ക് നന്ദി, ഒപ്റ്റിമൈസർ ഈ മൂല്യങ്ങൾ അറിയുന്നു. N ഉം M ഉം കാർഡിനൽ ഡിപൻഡൻസി നമ്പറുകളാണ്.

• നെസ്റ്റഡ് ലൂപ്പുകൾ ഉപയോഗിക്കുന്ന യൂണിയൻ.സംയോജിപ്പിക്കാനുള്ള ഏറ്റവും ലളിതമായ മാർഗമാണിത്.

  

  ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു: ഒരു ബാഹ്യ ആശ്രിതത്വത്തിന്റെ ഓരോ സ്ട്രിംഗിനും, ആന്തരിക ആശ്രിതത്വത്തിന്റെ എല്ലാ സ്ട്രിംഗുകളിലും പൊരുത്തങ്ങൾ കാണപ്പെടുന്നു.

  സ്യൂഡോകോഡ് ഉദാഹരണം:

  Nested_loop_join(അറേ പുറം, അറേ അകം) ഓരോ വരിയും a ഇൻ പുറത്തെ ഓരോ വരിയും b ഇൻനറിലെ എങ്കിൽ (match_join_condition(a,b)) write_result_in_output(a,b) അവസാനിച്ചാൽ അവസാനം
  ഇതൊരു ഇരട്ട ആവർത്തനമായതിനാൽ, സമയ സങ്കീർണ്ണത O(N*M) ആയി നിർവചിക്കപ്പെടുന്നു.

  ഓരോ N ബാഹ്യ ആശ്രിത വരികൾക്കും, നിങ്ങൾ M ബാഹ്യ ആശ്രിത വരികൾ കണക്കാക്കേണ്ടതുണ്ട്. അതായത്, ഈ അൽഗോരിതത്തിന് ഡിസ്കിൽ നിന്ന് N + N*M റീഡുകൾ ആവശ്യമാണ്. ആന്തരിക ആശ്രിതത്വം ആവശ്യത്തിന് ചെറുതാണെങ്കിൽ, നിങ്ങൾക്ക് അത് പൂർണ്ണമായും മെമ്മറിയിൽ ഉൾപ്പെടുത്താം, തുടർന്ന് ഡിസ്ക് സബ്സിസ്റ്റത്തിന് M + N റീഡുകൾ മാത്രമേ ഉണ്ടാകൂ. അതിനാൽ ആന്തരിക ആശ്രിതത്വം മെമ്മറിയിൽ ഉൾക്കൊള്ളിക്കുന്നതിന് കഴിയുന്നത്ര ഒതുക്കമുള്ളതാക്കാൻ ശുപാർശ ചെയ്യുന്നു.

  സമയ സങ്കീർണ്ണതയുടെ വീക്ഷണകോണിൽ നിന്ന്, വ്യത്യാസമില്ല.

  നിങ്ങൾക്ക് ഒരു സൂചിക ഉപയോഗിച്ച് ആന്തരിക ആശ്രിതത്വം മാറ്റിസ്ഥാപിക്കാം, ഇത് I/O പ്രവർത്തനങ്ങൾ സംരക്ഷിക്കും.
  ആന്തരിക ആശ്രിതത്വം മെമ്മറിയിൽ പൂർണ്ണമായും യോജിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഡിസ്ക് കൂടുതൽ സാമ്പത്തികമായി ഉപയോഗിക്കുന്ന മറ്റൊരു അൽഗോരിതം ഉപയോഗിക്കാം.

  • രണ്ട് ആശ്രിതത്വങ്ങളും വരി വരിയായി വായിക്കുന്നതിനുപകരം, അവ വരികളുടെ ഗ്രൂപ്പുകളായി (ബഞ്ച്) വായിക്കുന്നു, ഓരോ ഡിപൻഡൻസിയിൽ നിന്നും ഒരു ഗ്രൂപ്പ് മെമ്മറിയിൽ സൂക്ഷിക്കുന്നു.
  • ഈ ഗ്രൂപ്പുകളിൽ നിന്നുള്ള സ്ട്രിംഗുകൾ പരസ്പരം താരതമ്യം ചെയ്യുന്നു, കണ്ടെത്തിയ മത്സരങ്ങൾ പ്രത്യേകം സൂക്ഷിക്കുന്നു.
  • തുടർന്ന് പുതിയ ഗ്രൂപ്പുകൾ മെമ്മറിയിലേക്ക് ലോഡ് ചെയ്യുകയും പരസ്പരം താരതമ്യം ചെയ്യുകയും ചെയ്യുന്നു.
  അങ്ങനെ ഗ്രൂപ്പുകൾ തീരും വരെ.

  അൽഗോരിതം ഉദാഹരണം:

  // ഡിസ്ക് I/O കുറയ്ക്കാൻ മെച്ചപ്പെടുത്തിയ പതിപ്പ്. nested_loop_join_v2(ഫയൽ പുറം, ഫയൽ അകത്തെ) പുറത്തെ ഓരോ ബഞ്ച് ba // ba ഇപ്പോൾ ഓരോ ബഞ്ച് bb അകത്തെ മെമ്മറിയിൽ ആണ് // bb ഇപ്പോൾ ഓരോ വരിയും a in ba ഓരോ വരിയും bb ലെ ഓരോ വരിയും ba മെമ്മറിയിലാണ് (match_join_condition( a,b)) write_result_in_output(a,b) അവസാനം ആണെങ്കിൽ അവസാനം
  ഈ സാഹചര്യത്തിൽ, സമയ സങ്കീർണ്ണത അതേപടി തുടരുന്നു, പക്ഷേ ഡിസ്ക് ആക്സസ്സിന്റെ എണ്ണം കുറയുന്നു: (ബാഹ്യ ഗ്രൂപ്പുകളുടെ എണ്ണം + ബാഹ്യ ഗ്രൂപ്പുകളുടെ എണ്ണം * ആന്തരിക ഗ്രൂപ്പുകളുടെ എണ്ണം). ഗ്രൂപ്പിന്റെ വലുപ്പം കൂടുന്നതിനനുസരിച്ച്, ഡിസ്ക് ആക്‌സസുകളുടെ എണ്ണം കൂടുതൽ കുറയുന്നു.

  ശ്രദ്ധിക്കുക: ഈ അൽഗോരിതത്തിൽ, ഓരോ ആക്‌സസിലും കൂടുതൽ ഡാറ്റ റീഡുചെയ്യുന്നു, എന്നാൽ ആക്‌സസുകൾ തുടർച്ചയായതിനാൽ ഇത് പ്രശ്‌നമല്ല.

• ഹാഷ് ചേരുക.ഇത് കൂടുതൽ സങ്കീർണ്ണമായ പ്രവർത്തനമാണ്, എന്നാൽ പല കേസുകളിലും അതിന്റെ വില കുറവാണ്.

  

  അൽഗോരിതം ഇപ്രകാരമാണ്:

  1. ആന്തരിക ആശ്രിതത്വത്തിൽ നിന്നുള്ള എല്ലാ ഘടകങ്ങളും വായിക്കുന്നു.
  2. മെമ്മറിയിൽ ഒരു ഹാഷ് ടേബിൾ സൃഷ്ടിച്ചിരിക്കുന്നു.
  3. ബാഹ്യ ആശ്രിതത്വത്തിൽ നിന്നുള്ള എല്ലാ ഘടകങ്ങളും ഓരോന്നായി വായിക്കുന്നു.
  4. ഓരോ ഘടകത്തിനും, ഒരു ഹാഷ് കണക്കാക്കുന്നു (ഹാഷ് ടേബിളിൽ നിന്നുള്ള അനുബന്ധ ഫംഗ്ഷൻ ഉപയോഗിച്ച്) അതുവഴി ആന്തരിക ഡിപൻഡൻസിയിലെ അനുബന്ധ ബ്ലോക്ക് കണ്ടെത്താനാകും.
  5. ബ്ലോക്കിൽ നിന്നുള്ള ഘടകങ്ങൾ ബാഹ്യ ആശ്രിതത്വത്തിൽ നിന്നുള്ള ഘടകങ്ങളുമായി താരതമ്യം ചെയ്യുന്നു.
  സമയ സങ്കീർണ്ണതയുടെ അടിസ്ഥാനത്തിൽ ഈ അൽഗോരിതം വിലയിരുത്തുന്നതിന്, നിരവധി അനുമാനങ്ങൾ നടത്തേണ്ടതുണ്ട്:
  • ആന്തരിക ആശ്രിതത്വത്തിൽ X ബ്ലോക്കുകൾ അടങ്ങിയിരിക്കുന്നു.
  • ഹാഷ് ഫംഗ്ഷൻ രണ്ട് ഡിപൻഡൻസികൾക്കും ഏതാണ്ട് തുല്യമായി ഹാഷുകൾ വിതരണം ചെയ്യുന്നു. അതായത്, എല്ലാ ബ്ലോക്കുകൾക്കും ഒരേ വലിപ്പമുണ്ട്.
  • ഒരു ബാഹ്യ ആശ്രിതത്വത്തിന്റെ ഘടകങ്ങളും ഒരു ബ്ലോക്കിനുള്ളിലെ എല്ലാ ഘടകങ്ങളും തമ്മിലുള്ള പൊരുത്തം കണ്ടെത്തുന്നതിനുള്ള ചെലവ് ബ്ലോക്കിനുള്ളിലെ മൂലകങ്ങളുടെ എണ്ണത്തിന് തുല്യമാണ്.
  അപ്പോൾ സമയ സങ്കീർണ്ണത ഇതിന് തുല്യമായിരിക്കും:

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

  ഹാഷ് ഫംഗ്‌ഷൻ മതിയായ ചെറിയ ബ്ലോക്കുകൾ സൃഷ്‌ടിക്കുന്നുവെങ്കിൽ, സമയ സങ്കീർണ്ണത O(M + N) ആയിരിക്കും.

  കൂടുതൽ മെമ്മറി കാര്യക്ഷമവും കൂടുതൽ I/O പ്രവർത്തനങ്ങൾ ആവശ്യമില്ലാത്തതുമായ മറ്റൊരു ഹാഷ് ജോയിൻ രീതിയുണ്ട്:

  1. രണ്ട് ഡിപൻഡൻസികൾക്കും ഹാഷ് ടേബിളുകൾ കണക്കാക്കുന്നു.
  2. ഡിസ്കിൽ സ്ഥാപിച്ചു.
  3. തുടർന്ന് അവ പരസ്പരം ഘട്ടം ഘട്ടമായി താരതമ്യം ചെയ്യുന്നു (ഒരു ബ്ലോക്ക് മെമ്മറിയിലേക്ക് ലോഡ് ചെയ്യുന്നു, രണ്ടാമത്തേത് വരി വരിയായി വായിക്കുന്നു).
  ലയനം വഴി അസോസിയേഷൻ.ഡാറ്റ അടുക്കുന്നതിന് കാരണമാകുന്ന ഏക ലയന രീതി ഇതാണ്. ഈ ലേഖനത്തിൽ, ആശ്രിതത്വങ്ങൾ ബാഹ്യവും ആന്തരികവുമായി വിഭജിക്കപ്പെടാത്ത ഒരു ലളിതമായ കേസ് ഞങ്ങൾ പരിഗണിക്കുന്നു, കാരണം അവ ഒരേപോലെയാണ് പെരുമാറുന്നത്. എന്നിരുന്നാലും, യഥാർത്ഥ ജീവിതത്തിൽ, തനിപ്പകർപ്പുകളിൽ പ്രവർത്തിക്കുമ്പോൾ അവ വ്യത്യാസപ്പെട്ടിരിക്കാം.

  ലയന പ്രവർത്തനത്തെ രണ്ട് ഘട്ടങ്ങളായി തിരിക്കാം:

  1. (ഓപ്ഷണലായി) ആദ്യം ഒരു സോർട്ട് ജോയിൻ നടത്തുന്നു, അവിടെ രണ്ട് സെറ്റ് ഇൻപുട്ട് ഡാറ്റയും ജോയിൻ കീകൾ ഉപയോഗിച്ച് അടുക്കുന്നു.
  2. തുടർന്ന് ലയനം നടക്കുന്നു.
  അടുക്കുന്നു

  മെർജ് സോർട്ട് അൽഗോരിതം ഇതിനകം മുകളിൽ ചർച്ച ചെയ്തിട്ടുണ്ട്; ഈ സാഹചര്യത്തിൽ, മെമ്മറി സംരക്ഷിക്കുന്നത് നിങ്ങൾക്ക് പ്രധാനമാണെങ്കിൽ അത് തികച്ചും ന്യായമാണ്.

  എന്നാൽ ഡാറ്റാ സെറ്റുകൾ ഇതിനകം അടുക്കി വച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന്:

  • പട്ടിക നേറ്റീവ് ആയി ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിൽ.
  • ആശ്രിതത്വം എന്നത് ചേരുന്ന അവസ്ഥയുള്ള ഒരു സൂചികയാണെങ്കിൽ.
  • ഒരു ഇന്റർമീഡിയറ്റ് അടുക്കിയ ഫലത്തോടെയാണ് യൂണിയൻ സംഭവിക്കുന്നതെങ്കിൽ.
  ലയനത്തിലൂടെ ഏകീകരണം

  

  ഈ ഓപ്പറേഷൻ മെർജ് സോർട്ടിലെ ലയന പ്രവർത്തനവുമായി വളരെ സാമ്യമുള്ളതാണ്. എന്നാൽ രണ്ട് ഡിപൻഡൻസികളുടെയും എല്ലാ ഘടകങ്ങളും തിരഞ്ഞെടുക്കുന്നതിനുപകരം, ഞങ്ങൾ തുല്യ ഘടകങ്ങൾ മാത്രം തിരഞ്ഞെടുക്കുന്നു.

  1. രണ്ട് ഡിപൻഡൻസികളുടെയും നിലവിലുള്ള രണ്ട് ഘടകങ്ങളെ താരതമ്യം ചെയ്യുന്നു.
  2. അവ തുല്യമാണെങ്കിൽ, തത്ഫലമായുണ്ടാകുന്ന പട്ടികയിലേക്ക് അവ നൽകപ്പെടും, തുടർന്ന് അടുത്ത രണ്ട് ഘടകങ്ങൾ താരതമ്യം ചെയ്യുന്നു, ഓരോ ആശ്രിതത്വത്തിൽ നിന്നും ഒന്ന്.
  3. അവ തുല്യമല്ലെങ്കിൽ, താരതമ്യം ആവർത്തിക്കുന്നു, എന്നാൽ രണ്ട് മൂലകങ്ങളിൽ ചെറുതായതിന് പകരം, ഒരേ ആശ്രിതത്വത്തിൽ നിന്നുള്ള അടുത്ത ഘടകം എടുക്കുന്നു, കാരണം ഈ കേസിൽ യാദൃശ്ചികതയുടെ സാധ്യത കൂടുതലാണ്.
  4. ഡിപൻഡൻസികളിലൊന്നിന്റെ ഘടകങ്ങൾ തീരുന്നതുവരെ 1-3 ഘട്ടങ്ങൾ ആവർത്തിക്കുന്നു.
  രണ്ട് ഡിപൻഡൻസികളും ഇതിനകം അടുക്കിയിട്ടുണ്ടെങ്കിൽ, സമയ സങ്കീർണ്ണത O(N + M) ആണ്.

  രണ്ട് ഡിപൻഡൻസികളും ഇപ്പോഴും അടുക്കേണ്ടതുണ്ടെങ്കിൽ, സമയ സങ്കീർണ്ണത O(N * Log(N) + M * Log(M)) ആണ്.

  ഈ അൽഗോരിതം നന്നായി പ്രവർത്തിക്കുന്നു, കാരണം രണ്ട് ഡിപൻഡൻസികളും ഇതിനകം അടുക്കിയിരിക്കുന്നു, അവയ്ക്കിടയിൽ നമ്മൾ അങ്ങോട്ടും ഇങ്ങോട്ടും പോകേണ്ടതില്ല. എന്നിരുന്നാലും, ഇവിടെ ചില ലഘൂകരണങ്ങൾ ഉണ്ട്: ഒരേ ഡാറ്റ ഒന്നിലധികം തവണ സംഭവിക്കുന്ന സാഹചര്യങ്ങളെ അൽഗോരിതം കൈകാര്യം ചെയ്യുന്നില്ല, അതായത് ഒന്നിലധികം പൊരുത്തങ്ങൾ സംഭവിക്കുമ്പോൾ. വാസ്തവത്തിൽ, അൽഗോരിതത്തിന്റെ കൂടുതൽ സങ്കീർണ്ണമായ പതിപ്പാണ് ഉപയോഗിക്കുന്നത്. ഉദാഹരണത്തിന്:

  MergeJoin(relation a, relation b) relation output integer a_key:=0; പൂർണ്ണസംഖ്യ b_key:=0; while (a!=null and b!=null) if (a< b) a_key++; else if (a >b) b_key++; അല്ലാത്തപക്ഷം //പ്രെഡിക്കേറ്റിൽ ചേരുക തൃപ്തികരമായ write_result_in_output(a,b) //സൂചികകളുടെ പൂർണ്ണസംഖ്യ a_key_temp:=a_key വർദ്ധിപ്പിക്കുമ്പോൾ നാം ശ്രദ്ധിക്കേണ്ടതുണ്ട്; പൂർണ്ണസംഖ്യ b_key_temp:=b_key; എങ്കിൽ (a != b) b_key_temp:= b_key + 1; എങ്കിൽ (b != a) a_key_temp:= a_key + 1; എങ്കിൽ അവസാനിപ്പിക്കുക (b == a && b == a) a_key_temp:= a_key + 1; b_key_temp:= b_key + 1; a_key:= a_key_temp; b_key:= b_key_temp; അവസാനം എങ്കിൽ അവസാനം സമയത്ത്

ഏത് അൽഗോരിതം തിരഞ്ഞെടുക്കണം?

സംയോജിപ്പിക്കാനുള്ള ഏറ്റവും നല്ല മാർഗമുണ്ടെങ്കിൽ, ഈ ഇനങ്ങളെല്ലാം നിലനിൽക്കില്ല. അതിനാൽ, ഈ ചോദ്യത്തിനുള്ള ഉത്തരം ഒരു കൂട്ടം ഘടകങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു:

• ലഭ്യമായ മെമ്മറിയുടെ അളവ്. ഇത് പര്യാപ്തമല്ലെങ്കിൽ, ശക്തമായ ഒരു ഹാഷ് ജോയിനിനെക്കുറിച്ച് മറക്കുക. കുറഞ്ഞത്, അതിന്റെ നിർവ്വഹണം പൂർണ്ണമായും മെമ്മറിയിലാണ്.
• രണ്ട് ഇൻപുട്ട് ഡാറ്റാ സെറ്റുകളുടെ വലിപ്പം.നിങ്ങൾക്ക് ഒരു ടേബിൾ വലുതും മറ്റൊന്ന് വളരെ ചെറുതും ആണെങ്കിൽ, നെസ്റ്റഡ് ലൂപ്പുകൾ ഉപയോഗിച്ച് ഒരു ജോയിൻ വേഗത്തിൽ പ്രവർത്തിക്കും, കാരണം ഹാഷ് ജോയിനിൽ ഹാഷുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ചെലവേറിയ നടപടിക്രമം ഉൾപ്പെടുന്നു. നിങ്ങൾക്ക് വളരെ വലിയ രണ്ട് ടേബിളുകൾ ഉണ്ടെങ്കിൽ, നെസ്റ്റഡ് ലൂപ്പുകൾ ഉപയോഗിച്ച് ചേരുന്നത് എല്ലാ CPU ഉറവിടങ്ങളും ഉപയോഗിക്കും.
• സൂചികകളുടെ ലഭ്യത.നിങ്ങൾക്ക് രണ്ട് ബി-ട്രീ സൂചികകൾ ഉണ്ടെങ്കിൽ, ഒരു മെർജ് ജോയിൻ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.
• ഞാൻ ഫലങ്ങൾ അടുക്കേണ്ടതുണ്ടോ?നിങ്ങൾ തരംതിരിക്കാത്ത ഡാറ്റാ സെറ്റുകളിൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ വിലകൂടിയ ഒരു ലയന ചേരൽ (അതിക്രമത്തിൽ) ഉപയോഗിക്കാൻ ആഗ്രഹിച്ചേക്കാം. അപ്പോൾ ഔട്ട്പുട്ടിൽ നിങ്ങൾക്ക് അടുക്കിയ ഡാറ്റ ലഭിക്കും, അത് മറ്റൊരു യൂണിയന്റെ ഫലങ്ങളുമായി സംയോജിപ്പിക്കാൻ കൂടുതൽ സൗകര്യപ്രദമാണ്. അല്ലെങ്കിൽ ചോദ്യം പരോക്ഷമായോ പ്രത്യക്ഷമായോ ഓർഡർ പ്രകാരം/ഗ്രൂപ്പ് പ്രകാരം/ഡിസ്റ്റിങ്ക് ഓപ്പറേറ്റർമാർ പ്രകാരം അടുക്കിയ ഡാറ്റ ലഭിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതിനാൽ.
• ഔട്ട്പുട്ട് ഡിപൻഡൻസികൾ അടുക്കിയിട്ടുണ്ടോ?. ഈ സാഹചര്യത്തിൽ, ഒരു മെർജ് ജോയിൻ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.
• ഏത് തരത്തിലുള്ള ഡിപൻഡൻസികളാണ് നിങ്ങൾ ഉപയോഗിക്കുന്നത്?. തുല്യത പ്രകാരം ചേരണോ (tableA.column1 = tableB.column2)? ആന്തരിക ആശ്രിതത്വങ്ങൾ, ബാഹ്യ ആശ്രിതത്വം, കാർട്ടീഷ്യൻ ഉൽപ്പന്നം അല്ലെങ്കിൽ സ്വയം ചേരുക? വ്യത്യസ്ത സാഹചര്യങ്ങളിൽ, ചില ലയന രീതികൾ പ്രവർത്തിക്കുന്നില്ല.
• ഡാറ്റ വിതരണം. ജോയിൻ വ്യവസ്ഥയാൽ ഡാറ്റ നിരസിക്കപ്പെട്ടാൽ (ഉദാഹരണത്തിന്, നിങ്ങൾ അവസാന നാമത്തിലാണ് ആളുകളിൽ ചേരുന്നത്, പക്ഷേ പലപ്പോഴും നെയിംസേക്കുകൾ ഉണ്ട്), പിന്നെ ഒരു ഹാഷ് ജോയിൻ ഒരിക്കലും ഉപയോഗിക്കരുത്. അല്ലെങ്കിൽ ഹാഷ് ഫംഗ്ഷൻ വളരെ മോശം ആന്തരിക വിതരണമുള്ള ബക്കറ്റുകൾ സൃഷ്ടിക്കും.
• ഒന്നിലധികം പ്രക്രിയകളിൽ/ത്രെഡുകളിലേക്ക് ലയിപ്പിക്കേണ്ടത് ആവശ്യമാണോ?

അറിവിനായി വിശക്കുന്നവർക്ക് DB2, ORACLE, SQL സെർവർ എന്നിവയ്ക്കുള്ള ഡോക്യുമെന്റേഷനിലേക്ക് കടക്കാം.

4.4.4. ലളിതമായ ഉദാഹരണങ്ങൾ

ചില ആളുകളുടെ പൂർണ്ണമായ ചിത്രം ലഭിക്കാൻ നമുക്ക് അഞ്ച് ടേബിളുകളിൽ ചേരണമെന്ന് പറയാം. ഓരോ വ്യക്തിക്കും ഉണ്ടായിരിക്കാം:

• നിരവധി മൊബൈൽ ഫോൺ നമ്പറുകൾ.
• ഒന്നിലധികം ഇമെയിൽ വിലാസങ്ങൾ.
• ഒന്നിലധികം ഭൗതിക വിലാസങ്ങൾ.
• നിരവധി ബാങ്ക് അക്കൗണ്ട് നമ്പറുകൾ.

അതായത്, നിങ്ങൾ ഈ അഭ്യർത്ഥനയ്ക്ക് വേഗത്തിൽ ഉത്തരം നൽകേണ്ടതുണ്ട്:

വ്യക്തി, മൊബൈലുകൾ, മെയിലുകൾ, വിലാസങ്ങൾ, ബാങ്ക്_അക്കൗണ്ടുകൾ എന്നിവയിൽ നിന്ന് * തിരഞ്ഞെടുക്കുക. PERSON_ID = മൊബൈൽ .PERSON_ID
ഒപ്റ്റിമൈസർ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള മികച്ച മാർഗം കണ്ടെത്തേണ്ടതുണ്ട്. എന്നാൽ രണ്ട് പ്രശ്നങ്ങളുണ്ട്:

1. ഏത് ചേരൽ രീതിയാണ് ഞാൻ ഉപയോഗിക്കേണ്ടത്? 0, 1 അല്ലെങ്കിൽ 2 സൂചികകൾ ഉപയോഗിക്കുന്നതിനുള്ള ഓപ്‌ഷനോടുകൂടിയ മൂന്ന് ഓപ്ഷനുകൾ (ഹാഷ് ജോയിൻ, മെർജ് ജോയിൻ, നെസ്റ്റഡ് ലൂപ്പ് ജോയിൻ) ഉണ്ട്. സൂചികകളും വ്യത്യസ്തമാകുമെന്ന് പറയേണ്ടതില്ല.
2. ഏത് ക്രമത്തിലാണ് ലയനം നടത്തേണ്ടത്?

ഉദാഹരണത്തിന്, നാല് ടേബിളുകളുടെ മൂന്ന് ജോയിനുകൾക്കുള്ള സാധ്യമായ പ്ലാനുകൾ ചുവടെയുണ്ട്:

വിവരിച്ചതിനെ അടിസ്ഥാനമാക്കി, നിങ്ങളുടെ ഓപ്ഷനുകൾ എന്തൊക്കെയാണ്?

1. ഒരു ബ്രൂട്ട് ഫോഴ്സ് സമീപനം ഉപയോഗിക്കുക. സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിച്ച്, സാധ്യമായ ഓരോ അന്വേഷണ നിർവ്വഹണ പ്ലാനുകളുടെയും വില കണക്കാക്കി ഏറ്റവും വിലകുറഞ്ഞത് തിരഞ്ഞെടുക്കുക. എന്നാൽ ധാരാളം ഓപ്ഷനുകൾ ഉണ്ട്. ഓരോ ജോയിൻ ഓർഡറിനും, മൂന്ന് വ്യത്യസ്ത ജോയിൻ രീതികൾ ഉപയോഗിക്കാം, ആകെ 34=81 എക്സിക്യൂഷൻ പ്ലാനുകൾ. ഒരു ബൈനറി ട്രീയുടെ കാര്യത്തിൽ, ജോയിൻ ഓർഡർ തിരഞ്ഞെടുക്കുന്നതിലെ പ്രശ്നം ഒരു പെർമ്യൂട്ടേഷൻ പ്രശ്നമായി മാറുന്നു, കൂടാതെ ഓപ്ഷനുകളുടെ എണ്ണം (2 * 4) ആണ്! / (4 + 1)!.. ഫലമായി, വളരെ ലളിതമായ ഈ ഉദാഹരണത്തിൽ, സാധ്യമായ അന്വേഷണ നിർവ്വഹണ പ്ലാനുകളുടെ ആകെ എണ്ണം 34 * (2 * 4) ആണ്! / (4 + 1)! = 27,216. ഒരു ലയനം ചേരുന്നതിന് 0, 1, അല്ലെങ്കിൽ 2 ബി-ട്രീ സൂചികകൾ ഉപയോഗിക്കുന്ന ഓപ്‌ഷനുകൾ ഇതിലേക്ക് ചേർത്താൽ, സാധ്യമായ പ്ലാനുകളുടെ എണ്ണം 210,000 ആയി ഉയരും. ഇത് വളരെ ലളിതമായ ഒരു ചോദ്യമാണെന്ന് ഞങ്ങൾ സൂചിപ്പിച്ചോ?
2. കരയുക, ഉപേക്ഷിക്കുക. വളരെ പ്രലോഭിപ്പിക്കുന്നതും എന്നാൽ ഉൽപ്പാദനക്ഷമമല്ലാത്തതും നിങ്ങൾക്ക് പണം ആവശ്യമാണ്.
3. നിരവധി പ്ലാനുകൾ പരീക്ഷിച്ച് വിലകുറഞ്ഞ ഒന്ന് തിരഞ്ഞെടുക്കുക. സാധ്യമായ എല്ലാ ഓപ്‌ഷനുകളുടെയും വില കണക്കാക്കുന്നത് അസാധ്യമായതിനാൽ, നിങ്ങൾക്ക് ഒരു ഏകപക്ഷീയമായ ടെസ്റ്റ് സെറ്റ് ഡാറ്റ എടുത്ത് എല്ലാത്തരം പ്ലാനുകളും അവയുടെ ചെലവ് കണക്കാക്കാനും മികച്ചത് തിരഞ്ഞെടുക്കാനും കഴിയും.
4. സാധ്യമായ പ്ലാനുകളുടെ എണ്ണം കുറയ്ക്കാൻ മികച്ച നിയമങ്ങൾ പ്രയോഗിക്കുക.
   രണ്ട് തരത്തിലുള്ള നിയമങ്ങളുണ്ട്:
   1. "ലോജിക്കൽ" ആയവ, അതിന്റെ സഹായത്തോടെ നിങ്ങൾക്ക് ഉപയോഗശൂന്യമായ ഓപ്ഷനുകൾ ഇല്ലാതാക്കാം. എന്നാൽ അവ എല്ലായ്പ്പോഴും ബാധകമല്ല. ഉദാഹരണത്തിന്, "നെസ്റ്റഡ് ലൂപ്പുകൾ ഉപയോഗിച്ച് ചേരുമ്പോൾ, ആന്തരിക ഡിപൻഡൻസി ഡാറ്റയുടെ ഏറ്റവും ചെറിയ സെറ്റ് ആയിരിക്കണം."
   2. സാധ്യമായ പ്ലാനുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന് നിങ്ങൾ ഏറ്റവും ലാഭകരമായ പരിഹാരത്തിനായി നോക്കേണ്ടതില്ല, കൂടുതൽ കർശനമായ നിയമങ്ങൾ പ്രയോഗിക്കുക. പറയുക, "ആശ്രിതത്വം ചെറുതാണെങ്കിൽ, നെസ്റ്റഡ് ലൂപ്പ് ജോയിനുകൾ ഉപയോഗിക്കുക, എന്നാൽ ഒരിക്കലും ജോയിൻ ചെയ്യുകയോ ഹാഷ് ജോയിൻ ചെയ്യുകയോ ചെയ്യരുത്."

അത്തരമൊരു ലളിതമായ ഉദാഹരണം പോലും നമുക്ക് ഒരു വലിയ ചോയിസ് നൽകുന്നു. യഥാർത്ഥ അന്വേഷണങ്ങളിൽ മറ്റ് റിലേഷണൽ ഓപ്പറേറ്റർമാർ ഉണ്ടായിരിക്കാം: ഔട്ടർ ജോയിൻ, ക്രോസ് ജോയിൻ, ഗ്രൂപ്പ് ബൈ, ഓർഡർ ബൈ, പ്രൊജക്ഷൻ, യൂണിയൻ, ഇന്റർസെക്റ്റ്, ഡിസ്റ്റിംഗ്, മുതലായവ. അതായത്, സാധ്യമായ എക്സിക്യൂഷൻ പ്ലാനുകളുടെ എണ്ണം ഇതിലും വലുതായിരിക്കും.

അപ്പോൾ എങ്ങനെയാണ് ഡാറ്റാബേസ് തിരഞ്ഞെടുക്കുന്നത്?

4.4.5. ഡൈനാമിക് പ്രോഗ്രാമിംഗ്, അത്യാഗ്രഹ അൽഗോരിതം, ഹ്യൂറിസ്റ്റിക്സ്

ഒരു റിലേഷണൽ ഡാറ്റാബേസ് മുകളിൽ സൂചിപ്പിച്ച വ്യത്യസ്ത സമീപനങ്ങൾ ഉപയോഗിക്കുന്നു. പരിമിതമായ സമയത്തിനുള്ളിൽ അനുയോജ്യമായ പരിഹാരം കണ്ടെത്തുക എന്നതാണ് ഒപ്റ്റിമൈസറുടെ ചുമതല. മിക്ക കേസുകളിലും, ഒപ്റ്റിമൈസർ മികച്ച പരിഹാരത്തിനായി തിരയുന്നില്ല, മറിച്ച് ഒരു നല്ല പരിഹാരമാണ്.

ചെറിയ അഭ്യർത്ഥനകൾക്ക് ബ്രൂട്ട് ഫോഴ്‌സ് അനുയോജ്യമാകും. കൂടാതെ അനാവശ്യമായ കണക്കുകൂട്ടൽ ഇല്ലാതാക്കാനുള്ള വഴികളിലൂടെ, മിതമായ വലിപ്പമുള്ള ചോദ്യങ്ങൾക്ക് പോലും ബ്രൂട്ട് ഫോഴ്‌സ് ഉപയോഗിക്കാം. ഇതിനെ ഡൈനാമിക് പ്രോഗ്രാമിംഗ് എന്ന് വിളിക്കുന്നു.

പല നിർവ്വഹണ പദ്ധതികളും വളരെ സാമ്യമുള്ളതാണ് എന്നതാണ് ഇതിന്റെ സാരം.

ഈ ചിത്രീകരണത്തിൽ, നാല് പ്ലാനുകളും സബ്ട്രീ A JOIN B ഉപയോഗിക്കുന്നു. ഓരോ പ്ലാനിനും അതിന്റെ ചെലവ് കണക്കാക്കുന്നതിന് പകരം, നമുക്ക് അത് ഒരു തവണ മാത്രം കണക്കാക്കാം, തുടർന്ന് ആവശ്യമുള്ളിടത്തോളം കാലം ആ ഡാറ്റ ഉപയോഗിക്കാം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഓർമ്മപ്പെടുത്തൽ ഉപയോഗിച്ച് ഞങ്ങൾ ഓവർലാപ്പ് പ്രശ്നം പരിഹരിക്കുന്നു, അതായത്, അനാവശ്യ കണക്കുകൂട്ടലുകൾ ഞങ്ങൾ ഒഴിവാക്കുന്നു.

ഈ സമീപനത്തിന് നന്ദി, സമയ സങ്കീർണ്ണതയ്ക്ക് പകരം (2*N)!/(N+1)! നമുക്ക് "മാത്രം" 3 N ലഭിക്കുന്നു. നാല് ജോയിനുകളുള്ള മുൻ ഉദാഹരണത്തിൽ, കേസുകളുടെ എണ്ണം 336 ൽ നിന്ന് 81 ആയി കുറയ്ക്കുക എന്നാണ് ഇതിനർത്ഥം. നമ്മൾ 8 ജോയിനുകളുള്ള ഒരു ചോദ്യം (ഒരു ചെറിയ ചോദ്യം) എടുക്കുകയാണെങ്കിൽ, സങ്കീർണ്ണത കുറയ്ക്കൽ 57,657,600 ൽ നിന്ന് 6,561 ആയി മാറും.

ഡൈനാമിക് പ്രോഗ്രാമിംഗ് അല്ലെങ്കിൽ അൽഗോരിതം നിങ്ങൾക്ക് ഇതിനകം പരിചിതമാണെങ്കിൽ, നിങ്ങൾക്ക് ഈ അൽഗോരിതം ഉപയോഗിച്ച് കളിക്കാം:

നടപടിക്രമം findbestplan(S) (bestplan[S].cost infinite) റിട്ടേൺ ബെസ്റ്റ്‌പ്ലാൻ[S] // അല്ലെങ്കിൽ bestplan[S] നേരത്തെ കണക്കാക്കിയിട്ടില്ലെങ്കിൽ, (S-ൽ 1 റിലേഷൻ മാത്രമേ ഉള്ളൂ) ബെസ്റ്റ്‌പ്ലാൻ[S] സജ്ജീകരിക്കുകയാണെങ്കിൽ അത് ഇപ്പോൾ കണക്കാക്കുക. പ്ലാനും ബെസ്റ്റ്‌പ്ലാനും[S].ചെലവ് എസ് ആക്‌സസ് ചെയ്യാനുള്ള മികച്ച മാർഗത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് P2= findbestplan(S - S1) A = P1, P2 എന്നിവയുടെ ഫലങ്ങളിൽ ചേരുന്നതിനുള്ള മികച്ച അൽഗോരിതം ചെലവ് = P1.cost + P2.cost + ചെലവാണെങ്കിൽ A യുടെ വില< 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]
വലിയ ചോദ്യങ്ങൾക്ക് ഡൈനാമിക് പ്രോഗ്രാമിംഗ് ഉപയോഗിക്കാം, എന്നാൽ സാധ്യമായ പ്ലാനുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന് അധിക നിയമങ്ങൾ (ഹ്യൂറിസ്റ്റിക്സ്) അവതരിപ്പിക്കേണ്ടതുണ്ട്:


അത്യാഗ്രഹ അൽഗോരിതങ്ങൾ

എന്നാൽ അഭ്യർത്ഥന വളരെ വലുതാണെങ്കിൽ, അല്ലെങ്കിൽ ഞങ്ങൾക്ക് വളരെ വേഗത്തിൽ ഉത്തരം ലഭിക്കണമെങ്കിൽ, മറ്റൊരു ക്ലാസ് അൽഗോരിതം ഉപയോഗിക്കുന്നു - അത്യാഗ്രഹ അൽഗോരിതങ്ങൾ.

ഈ സാഹചര്യത്തിൽ, ക്വറി എക്സിക്യൂഷൻ പ്ലാൻ ഒരു നിശ്ചിത നിയമം (ഹ്യൂറിസ്റ്റിക്സ്) ഉപയോഗിച്ച് ഘട്ടം ഘട്ടമായി നിർമ്മിക്കുന്നു. അതിന് നന്ദി, അത്യാഗ്രഹ അൽഗോരിതം ഓരോ ഘട്ടത്തിനും വെവ്വേറെ മികച്ച പരിഹാരത്തിനായി തിരയുന്നു. പ്ലാൻ ഒരു ജോയിൻ സ്റ്റേറ്റ്‌മെന്റിൽ ആരംഭിക്കുന്നു, തുടർന്ന് ഓരോ ഘട്ടത്തിലും റൂൾ അനുസരിച്ച് ഒരു പുതിയ ജോയിൻ ചേർക്കുന്നു.

ഒരു ലളിതമായ ഉദാഹരണം നോക്കാം. 5 ടേബിളുകളുടെ (എ, ബി, സി, ഡി, ഇ) 4 ജോയിനുകൾ ഉള്ള ഒരു ചോദ്യം നമുക്ക് എടുക്കാം. നമുക്ക് പ്രശ്നം കുറച്ച് ലളിതമാക്കാം കൂടാതെ നെസ്റ്റഡ് അൽഗോരിതങ്ങൾ ഉപയോഗിച്ച് സംയോജിപ്പിക്കുക എന്നതാണ് ഏക പോംവഴി എന്ന് സങ്കൽപ്പിക്കുക. "ചുരുങ്ങിയ ചെലവിൽ ജോയിൻ ചെയ്യുക" എന്ന നിയമം ഞങ്ങൾ ഉപയോഗിക്കും.

• ഞങ്ങൾ പട്ടികകളിലൊന്നിൽ നിന്ന് ആരംഭിക്കുന്നു, ഉദാഹരണത്തിന്, എ.
• ഓരോ യൂണിയന്റെയും ചെലവ് ഞങ്ങൾ A ഉപയോഗിച്ച് കണക്കാക്കുന്നു (അത് ബാഹ്യവും ആന്തരികവുമായ ആശ്രിതത്വമായിരിക്കും).
• ഒരു JOIN B ഞങ്ങൾക്ക് ഏറ്റവും വിലകുറഞ്ഞതായിരിക്കുമെന്ന് ഞങ്ങൾ കണ്ടെത്തി.
• അപ്പോൾ ഓരോ ജോയിനിന്റെയും ചെലവ് A JOIN B എന്ന ഫലം ഉപയോഗിച്ച് ഞങ്ങൾ കണക്കാക്കുന്നു (ഞങ്ങൾ ഇത് രണ്ട് റോളുകളായി പരിഗണിക്കുന്നു).
• ഏറ്റവും ലാഭകരമായ ഓപ്ഷൻ (A JOIN B) JOIN C ആയിരിക്കും എന്ന് ഞങ്ങൾ കണ്ടെത്തി.
• സാധ്യമായ ഓപ്ഷനുകൾ ഞങ്ങൾ വീണ്ടും വിലയിരുത്തുന്നു.
• അവസാനം നമുക്ക് ഇനിപ്പറയുന്ന അന്വേഷണ നിർവ്വഹണ പ്ലാൻ ലഭിക്കും: (((എ ജോയിൻ ബി) ജോയിൻ സി) ജോയിൻ ഡി) ജോയിൻ ഇ)/

ടേബിൾ ബി, തുടർന്ന് സി മുതലായവയിൽ ആരംഭിക്കുന്ന ഓപ്ഷനുകൾ വിലയിരുത്തുന്നതിന് ഇതേ അൽഗോരിതം പ്രയോഗിക്കാവുന്നതാണ്. തൽഫലമായി, ഞങ്ങൾക്ക് അഞ്ച് പ്ലാനുകൾ ലഭിക്കുന്നു, അതിൽ നിന്ന് ഞങ്ങൾ വിലകുറഞ്ഞത് തിരഞ്ഞെടുക്കുന്നു.

ഈ അൽഗോരിതം "അടുത്തുള്ള അയൽക്കാരൻ അൽഗോരിതം" എന്ന് വിളിക്കുന്നു.

ഞങ്ങൾ വിശദാംശങ്ങളിലേക്ക് പോകില്ല, എന്നാൽ N*log(N) എന്ന സോർട്ടിംഗ് സങ്കീർണ്ണതയുടെ നല്ല മോഡലിംഗ് ഉപയോഗിച്ച് ഈ പ്രശ്നം പരിഹരിക്കാൻ കഴിയും. ഡൈനാമിക് പ്രോഗ്രാമിംഗുള്ള പൂർണ്ണ പതിപ്പിന് O(3 N) ന് പകരം O(N*log(N)) ആണ് അൽഗോരിതത്തിന്റെ സമയ സങ്കീർണ്ണത. നിങ്ങൾക്ക് 20 ജോയിംഗുകളുള്ള ഒരു വലിയ ചോദ്യമുണ്ടെങ്കിൽ, അത് 26 ഉം 3,486,784,401 ഉം ആയിരിക്കും. വലിയ വ്യത്യാസം, അല്ലേ?

എന്നാൽ ഒരു ന്യൂനൻസ് ഉണ്ട്. രണ്ട് ടേബിളുകൾ ജോയിൻ ചെയ്യുന്നതിനുള്ള ഏറ്റവും നല്ല മാർഗം ഞങ്ങൾ കണ്ടെത്തിയാൽ, ഇനിപ്പറയുന്ന പട്ടികകളുമായി മുമ്പത്തെ ജോയിംഗുകളുടെ ഫലം ചേരുമ്പോൾ ഏറ്റവും കുറഞ്ഞ ചിലവ് ലഭിക്കുമെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു. എന്നിരുന്നാലും, A JOIN B എന്നത് ഏറ്റവും വിലകുറഞ്ഞ ഓപ്ഷനാണെങ്കിൽ പോലും, (A JOIN C) JOIN B-ക്ക് (A JOIN B) JOIN C എന്നതിനേക്കാൾ കുറഞ്ഞ ചിലവ് ഉണ്ടായിരിക്കാം.

അതിനാൽ, നിങ്ങൾക്ക് എക്കാലത്തെയും വിലകുറഞ്ഞ പ്ലാൻ കണ്ടെത്തണമെങ്കിൽ, വ്യത്യസ്ത നിയമങ്ങൾ ഉപയോഗിച്ച് അത്യാഗ്രഹമുള്ള അൽഗോരിതങ്ങൾ ആവർത്തിച്ച് പ്രവർത്തിപ്പിക്കാൻ ഞങ്ങൾക്ക് നിങ്ങളെ ഉപദേശിക്കാം.

മറ്റ് അൽഗോരിതങ്ങൾ

ഈ അൽഗരിതങ്ങൾ കൊണ്ട് നിങ്ങൾ ഇതിനകം മടുത്തുവെങ്കിൽ, നിങ്ങൾക്ക് ഈ അധ്യായം ഒഴിവാക്കാം. ബാക്കി മെറ്റീരിയൽ മാസ്റ്റർ ചെയ്യേണ്ട ആവശ്യമില്ല.

മികച്ച അന്വേഷണ നിർവ്വഹണ പദ്ധതി കണ്ടെത്തുന്നതിനുള്ള പ്രശ്നത്തിൽ പല ഗവേഷകരും പ്രവർത്തിക്കുന്നു. നിർദ്ദിഷ്ട പ്രശ്നങ്ങൾക്കും പാറ്റേണുകൾക്കും പരിഹാരം കണ്ടെത്താൻ അവർ പലപ്പോഴും ശ്രമിക്കുന്നു. ഉദാഹരണത്തിന്, നക്ഷത്ര ചേരലുകൾ, സമാന്തര അന്വേഷണ നിർവ്വഹണം മുതലായവ.

വലിയ ചോദ്യങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നതിനായി ഡൈനാമിക് പ്രോഗ്രാമിംഗ് മാറ്റിസ്ഥാപിക്കുന്നതിനുള്ള ഓപ്ഷനുകൾ തേടുന്നു. അതേ അത്യാഗ്രഹ അൽഗോരിതങ്ങൾ ഹ്യൂറിസ്റ്റിക് അൽഗരിതങ്ങളുടെ ഒരു ഉപവിഭാഗമാണ്. അവർ നിയമം അനുസരിച്ച് പ്രവർത്തിക്കുന്നു, ഒരു ഘട്ടത്തിന്റെ ഫലം ഓർമ്മിക്കുക, അടുത്ത ഘട്ടത്തിലേക്കുള്ള മികച്ച ഓപ്ഷൻ കണ്ടെത്താൻ അത് ഉപയോഗിക്കുക. മുമ്പത്തെ ഘട്ടത്തിൽ കണ്ടെത്തിയ പരിഹാരം എല്ലായ്പ്പോഴും ഉപയോഗിക്കാത്ത അൽഗോരിതങ്ങളെ ഹ്യൂറിസ്റ്റിക് എന്ന് വിളിക്കുന്നു.

ഒരു ഉദാഹരണം ജനിതക അൽഗോരിതം:

• ഓരോ പരിഹാരവും അഭ്യർത്ഥനയുടെ പൂർണ്ണമായ നിർവ്വഹണത്തിനുള്ള ഒരു പദ്ധതിയെ പ്രതിനിധീകരിക്കുന്നു.
• ഒരു പരിഹാരത്തിന് (പ്ലാൻ) പകരം, അൽഗോരിതം ഓരോ ഘട്ടത്തിലും X പരിഹാരങ്ങൾ സൃഷ്ടിക്കുന്നു.
• ആദ്യം, X പ്ലാനുകൾ സൃഷ്ടിക്കപ്പെടുന്നു, ഇത് ക്രമരഹിതമായി ചെയ്യുന്നു.
• ഇവയിൽ, ഒരു നിശ്ചിത മാനദണ്ഡം പാലിക്കുന്ന മൂല്യമുള്ള പ്ലാനുകൾ മാത്രമേ സംരക്ഷിക്കപ്പെടുകയുള്ളൂ.
• ഈ പ്ലാനുകൾ കൂട്ടിച്ചേർത്ത് X പുതിയ പ്ലാനുകൾ സൃഷ്ടിക്കുന്നു.
• ചില പുതിയ പ്ലാനുകൾ ക്രമരഹിതമായി പരിഷ്‌ക്കരിച്ചതാണ്.
• മുമ്പത്തെ മൂന്ന് ഘട്ടങ്ങൾ Y തവണ ആവർത്തിക്കുന്നു.
• അവസാന ചക്രത്തിന്റെ പദ്ധതികളിൽ നിന്ന് നമുക്ക് ഏറ്റവും മികച്ചത് ലഭിക്കും.

കൂടുതൽ സൈക്കിളുകൾ, വിലകുറഞ്ഞ പ്ലാൻ കണക്കാക്കാം. സ്വാഭാവിക തിരഞ്ഞെടുപ്പ്, സ്വഭാവസവിശേഷതകളുടെ ഏകീകരണം, അത്രമാത്രം.
വഴിയിൽ, ജനിതക അൽഗോരിതങ്ങൾ PostgreSQL-ലേക്ക് സംയോജിപ്പിച്ചിരിക്കുന്നു.

സിമുലേറ്റഡ് അനീലിംഗ്, ഇറ്ററേറ്റീവ് ഇംപ്രൂവ്‌മെന്റ്, ടു-ഫേസ് ഒപ്റ്റിമൈസേഷൻ തുടങ്ങിയ ഹ്യൂറിസ്റ്റിക് അൽഗോരിതങ്ങളും ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നു. എന്നാൽ അവ കോർപ്പറേറ്റ് സംവിധാനങ്ങളിൽ ഉപയോഗിക്കുന്നു എന്നത് ഒരു വസ്തുതയല്ല; ഒരുപക്ഷേ അവരുടെ വിധി ഗവേഷണ ഉൽപ്പന്നങ്ങളായിരിക്കാം.

4.4.6. യഥാർത്ഥ ഒപ്റ്റിമൈസറുകൾ

ഒരു ഓപ്ഷണൽ അധ്യായവും, നിങ്ങൾക്ക് അത് ഒഴിവാക്കാം.

നമുക്ക് സിദ്ധാന്തത്തിൽ നിന്ന് മാറി യഥാർത്ഥ ഉദാഹരണങ്ങൾ നോക്കാം. ഉദാഹരണത്തിന്, SQLite ഒപ്റ്റിമൈസർ എങ്ങനെ പ്രവർത്തിക്കുന്നു. അധിക നിയമങ്ങളുള്ള ഒരു അത്യാഗ്രഹ അൽഗോരിതം അടിസ്ഥാനമാക്കിയുള്ള ലളിതമായ ഒപ്റ്റിമൈസേഷൻ ഉപയോഗിക്കുന്ന ഒരു "കനംകുറഞ്ഞ" ഡാറ്റാബേസാണിത്:

• ക്രോസ് ജോയിൻ പ്രവർത്തനത്തിൽ SQLite ഒരിക്കലും പട്ടികകളുടെ ക്രമം മാറ്റില്ല.
• നെസ്റ്റഡ് ലൂപ്പുകൾ ഉപയോഗിക്കുന്ന യൂണിയൻ ഉപയോഗിക്കുന്നു.
• ബാഹ്യ ജോയിന്റുകൾ എല്ലായ്പ്പോഴും അവ നടപ്പിലാക്കിയ ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു.
• പതിപ്പ് 3.8.0 വരെ, ഏറ്റവും മികച്ച അന്വേഷണ നിർവ്വഹണ പ്ലാൻ കണ്ടെത്താൻ അത്യാഗ്രഹിയായ അടുത്തുള്ള അയൽക്കാരൻ അൽഗോരിതം ഉപയോഗിക്കുന്നു. പതിപ്പ് 3.8.0 മുതൽ, “N അടുത്തുള്ള അയൽക്കാർ” (N3, N അടുത്തുള്ള അയൽക്കാർ) ഉപയോഗിക്കുന്നു.

ഇതാ മറ്റൊരു ഉദാഹരണം. ഞങ്ങൾ IBM DB2 ഡോക്യുമെന്റേഷൻ വായിക്കുകയാണെങ്കിൽ, അതിന്റെ ഒപ്റ്റിമൈസർ 7 വ്യത്യസ്ത തലത്തിലുള്ള ഒപ്റ്റിമൈസേഷൻ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു:

• അത്യാഗ്രഹ അൽഗോരിതങ്ങൾ:
  • 0 - കുറഞ്ഞ ഒപ്റ്റിമൈസേഷൻ. ഇൻഡെക്സ് സ്കാനിംഗ്, നെസ്റ്റഡ് ലൂപ്പ് ജോയിൻസ് എന്നിവ ഉപയോഗിക്കുന്നു, കൂടാതെ ചില ചോദ്യങ്ങൾ വീണ്ടും എഴുതുന്നത് ഒഴിവാക്കുന്നു.
  • 1 - കുറഞ്ഞ ഒപ്റ്റിമൈസേഷൻ
  • 2 - പൂർണ്ണ ഒപ്റ്റിമൈസേഷൻ
• ഡൈനാമിക് പ്രോഗ്രാമിംഗ്:
  • 3 - ഇടത്തരം ഒപ്റ്റിമൈസേഷനും പരുക്കൻ ഏകദേശവും
  • 5 - പൂർണ്ണ ഒപ്റ്റിമൈസേഷൻ, എല്ലാ ഹ്യൂറിസ്റ്റിക് ടെക്നിക്കുകളും ഉപയോഗിക്കുന്നു
  • 7 - ഒരേ കാര്യം, പക്ഷേ ഹ്യൂറിസ്റ്റിക്സ് ഇല്ലാതെ
  • 9 - ചെലവാക്കിയ പ്രയത്നം പരിഗണിക്കാതെ ഏത് വിലയിലും പരമാവധി ഒപ്റ്റിമൈസേഷൻ. കാർട്ടീഷ്യൻ ഉൽപ്പന്നങ്ങൾ ഉൾപ്പെടെ സാധ്യമായ എല്ലാ സംയോജന രീതികളും വിലയിരുത്തപ്പെടുന്നു.

ഡിഫോൾട്ട് ലെവൽ 5 ആണ്. ഇതിൽ ഉൾപ്പെടുന്നു:

• ഫ്രീക്വൻസി ഡിസ്ട്രിബ്യൂഷനുകളും ക്വാണ്ടൈലുകളും ഉൾപ്പെടെ സാധ്യമായ എല്ലാ സ്ഥിതിവിവരക്കണക്കുകളുടെയും ശേഖരണം.
• വസ്തുനിഷ്ഠമായ ചോദ്യങ്ങൾക്കായി ഒരു ടേബിൾ റൂട്ട് സൃഷ്‌ടിക്കുന്നത് ഉൾപ്പെടെ, എല്ലാ ചോദ്യ റീറൈറ്റിംഗ് നിയമങ്ങളും പ്രയോഗിക്കുന്നു). തീവ്രമായ കണക്കുകൂട്ടലുകൾ ആവശ്യമുള്ളതും വളരെ പരിമിതമായ എണ്ണം കേസുകൾക്ക് ഉപയോഗിക്കുന്നതുമായ നിയമങ്ങളാണ് അപവാദം.
• ഡൈനാമിക് പ്രോഗ്രാമിംഗ് ഉപയോഗിച്ച് ജോയിൻ ഓപ്ഷനുകളിലൂടെ ആവർത്തിക്കുമ്പോൾ:
  • സംയുക്ത ആന്തരിക ആശ്രിതത്വത്തിന്റെ പരിമിതമായ ഉപയോഗമുണ്ട്.
  • ലുക്ക്അപ്പ് ടേബിളുകളുള്ള സ്റ്റാർ സർക്യൂട്ടുകൾക്ക്, കാർട്ടീഷ്യൻ ഉൽപ്പന്നങ്ങൾ പരിമിതമായ അളവിൽ ഉപയോഗിക്കുന്നു.
• ലിസ്റ്റ് പ്രീഫെച്ചിംഗ് (ഇതിൽ കൂടുതൽ താഴെ), സൂചികകളുടെ പ്രത്യേക ആൻഡിംഗ്, മെറ്റീരിയലൈസ്ഡ് അന്വേഷണങ്ങൾക്കുള്ള ടേബിൾ റൂട്ടിംഗ് എന്നിവയുൾപ്പെടെ വിപുലമായ ആക്സസ് രീതികൾ ഉൾക്കൊള്ളുന്നു.

തീർച്ചയായും, ഡെവലപ്പർമാർ അവരുടെ ഉൽപ്പന്നത്തിൽ ഉപയോഗിക്കുന്ന ഹ്യൂറിസ്റ്റിക്സിനെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ പങ്കിടുന്നില്ല, കാരണം ഒപ്റ്റിമൈസർ ഒരുപക്ഷേ ഡാറ്റാബേസിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗമാണ്. എന്നിരുന്നാലും, ഡിഫോൾട്ടായി, ചേരുന്ന ക്രമം നിർണ്ണയിക്കാൻ, ഹ്യൂറിസ്റ്റിക്സ് പരിമിതപ്പെടുത്തിയ ഡൈനാമിക് പ്രോഗ്രാമിംഗ് ഉപയോഗിക്കുന്നു.

മറ്റ് വ്യവസ്ഥകൾ (GROUP BY, DISTINCT മുതലായവ) ലളിതമായ നിയമങ്ങളാൽ പ്രോസസ്സ് ചെയ്യുന്നു.

4.4.7. പ്ലാൻ കാഷെ അന്വേഷിക്കുക

ഒരു പ്ലാൻ നിർമ്മിക്കുന്നതിന് സമയമെടുക്കുന്നതിനാൽ, മിക്ക ഡാറ്റാബേസുകളും പ്ലാൻ ഒരു ക്വറി പ്ലാൻ കാഷെയിൽ സംഭരിക്കുന്നു. സമാന ഘട്ടങ്ങളുടെ അനാവശ്യ കണക്കുകൂട്ടലുകൾ ഒഴിവാക്കാൻ ഇത് സഹായിക്കുന്നു. കാലഹരണപ്പെട്ട പ്ലാനുകൾ എപ്പോൾ അപ്‌ഡേറ്റ് ചെയ്യണമെന്ന് ഡാറ്റാബേസിന് കൃത്യമായി അറിയേണ്ടതുണ്ട്. ഇതിനായി, ഒരു നിശ്ചിത പരിധി സജ്ജീകരിച്ചിരിക്കുന്നു, സ്ഥിതിവിവരക്കണക്കുകളിലെ മാറ്റങ്ങൾ അതിനെ കവിയുന്നുവെങ്കിൽ, ഈ പട്ടികയുമായി ബന്ധപ്പെട്ട പ്ലാൻ കാഷെയിൽ നിന്ന് നീക്കം ചെയ്യപ്പെടും.

അഭ്യർത്ഥന നടത്തിപ്പുകാരൻ

ഈ ഘട്ടത്തിൽ, ഞങ്ങളുടെ പ്ലാൻ ഇതിനകം ഒപ്റ്റിമൈസ് ചെയ്തു. ഇത് എക്സിക്യൂട്ടബിൾ കോഡിലേക്ക് വീണ്ടും കംപൈൽ ചെയ്യുകയും ആവശ്യത്തിന് ഉറവിടങ്ങൾ ഉണ്ടെങ്കിൽ, എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു. പ്ലാനിൽ അടങ്ങിയിരിക്കുന്ന ഓപ്പറേറ്റർമാരെ (JOIN, SORT BY, മുതലായവ) തുടർച്ചയായി അല്ലെങ്കിൽ സമാന്തരമായി പ്രോസസ്സ് ചെയ്യാൻ കഴിയും; എക്സിക്യൂട്ടറാണ് തീരുമാനം എടുക്കുന്നത്. ഡാറ്റ സ്വീകരിക്കുന്നതിനും എഴുതുന്നതിനും ഇത് ഡാറ്റ മാനേജറുമായി സംവദിക്കുന്നു.

5. ഡാറ്റ മാനേജർ

അന്വേഷണ മാനേജർ ചോദ്യം നിർവ്വഹിക്കുന്നു, കൂടാതെ പട്ടികകളിൽ നിന്നും സൂചികകളിൽ നിന്നും ഡാറ്റ ആവശ്യമാണ്. ഇത് ഡാറ്റ മാനേജറിൽ നിന്ന് അവരെ അഭ്യർത്ഥിക്കുന്നു, എന്നാൽ രണ്ട് ബുദ്ധിമുട്ടുകൾ ഉണ്ട്:

• റിലേഷണൽ ഡാറ്റാബേസുകൾ ഒരു ഇടപാട് മാതൃക ഉപയോഗിക്കുന്നു. ഒരു നിശ്ചിത സമയത്ത് ആവശ്യമുള്ള ഡാറ്റ നേടുന്നത് അസാധ്യമാണ്, കാരണം ഈ സമയത്ത് അത് മറ്റൊരാൾക്ക് ഉപയോഗിക്കാനും പരിഷ്കരിക്കാനും കഴിയും.
• ഒരു ഡാറ്റാബേസിലെ ഏറ്റവും മന്ദഗതിയിലുള്ള പ്രവർത്തനമാണ് ഡാറ്റ വീണ്ടെടുക്കൽ. അതിനാൽ, സമയബന്ധിതമായി മെമ്മറി ബഫർ പൂരിപ്പിക്കുന്നതിന് ഡാറ്റ മാനേജർക്ക് അതിന്റെ പ്രവർത്തനം പ്രവചിക്കാൻ കഴിയേണ്ടതുണ്ട്.

5.1 കാഷെ മാനേജർ

ഒന്നിലധികം തവണ പറഞ്ഞതുപോലെ, ഡാറ്റാബേസിലെ തടസ്സം ഡിസ്ക് സബ്സിസ്റ്റമാണ്. അതിനാൽ, പ്രകടനം മെച്ചപ്പെടുത്താൻ ഒരു കാഷെ മാനേജർ ഉപയോഗിക്കുന്നു.

ഫയൽ സിസ്റ്റത്തിൽ നിന്ന് നേരിട്ട് ഡാറ്റ സ്വീകരിക്കുന്നതിന് പകരം, അന്വേഷണ റണ്ണർ അതിനായി കാഷെ മാനേജറിലേക്ക് പോകുന്നു. ഇത് മെമ്മറിയിൽ അടങ്ങിയിരിക്കുന്ന ഒരു ബഫർ പൂൾ ഉപയോഗിക്കുന്നു, ഇത് ഡാറ്റാബേസ് പ്രകടനത്തെ സമൂലമായി വർദ്ധിപ്പിക്കും. ഇതിൽ ഒരു നമ്പർ ഇടുന്നത് ബുദ്ധിമുട്ടാണ്, കാരണം നിങ്ങൾക്ക് ആവശ്യമുള്ളതിനെ ആശ്രയിച്ചിരിക്കുന്നു:

• ക്രമാനുഗതമായ ആക്സസ് (പൂർണ്ണ സ്കാൻ) അല്ലെങ്കിൽ ക്രമരഹിതമായ (വരി ഐഡി വഴിയുള്ള ആക്സസ്).
• വായിക്കുക അല്ലെങ്കിൽ എഴുതുക.

ഡിസ്ക് സിസ്റ്റത്തിൽ ഉപയോഗിക്കുന്ന ഡ്രൈവുകളുടെ തരത്തിനും വലിയ പ്രാധാന്യമുണ്ട്: വ്യത്യസ്ത സ്പിൻഡിൽ വേഗതയുള്ള "ഹാർഡ് ഡ്രൈവുകൾ", എസ്എസ്ഡികൾ, വ്യത്യസ്ത കോൺഫിഗറേഷനുകളിൽ റെയ്ഡിന്റെ സാന്നിധ്യം. എന്നാൽ മെമ്മറി ഉപയോഗം ഡിസ്ക് ഉപയോഗത്തേക്കാൾ 100-100,000 മടങ്ങ് വേഗതയുള്ളതാണെന്ന് നമുക്ക് പറയാം.

എന്നിരുന്നാലും, ഇവിടെ നാം മറ്റൊരു പ്രശ്നം അഭിമുഖീകരിക്കുന്നു. ക്വറി എക്‌സിക്യൂട്ടറിന് ആവശ്യമായ ഡാറ്റ ലഭിക്കുന്നതിന് മുമ്പ് കാഷെ മാനേജർ ഡാറ്റ മെമ്മറിയിൽ ഇടേണ്ടതുണ്ട്. അല്ലെങ്കിൽ, സ്ലോ ഡിസ്കിൽ നിന്ന് അവ ലഭിക്കുന്നതുവരെ അവൻ കാത്തിരിക്കേണ്ടിവരും.

5.1.1. മുൻകരുതൽ

മുഴുവൻ പ്ലാനും, ഡിസ്കിലുള്ള ഡാറ്റയും, സ്ഥിതിവിവരക്കണക്കുകളും അറിയാവുന്നതിനാൽ, അന്വേഷണ നടത്തിപ്പുകാരന് എന്ത് ഡാറ്റ ആവശ്യമാണെന്ന് അറിയാം.

എക്സിക്യൂട്ടർ ഡാറ്റയുടെ ആദ്യ ഭാഗം പ്രോസസ്സ് ചെയ്യുമ്പോൾ, അടുത്ത ഭാഗം പ്രീലോഡ് ചെയ്യാൻ അത് കാഷെ മാനേജറോട് ആവശ്യപ്പെടുന്നു. ഇത് പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങുമ്പോൾ, മൂന്നാമത്തേത് ലോഡ് ചെയ്യാൻ ഡിസിയോട് ആവശ്യപ്പെടുകയും കാഷെയിൽ നിന്ന് ആദ്യ ഭാഗം ഇല്ലാതാക്കാൻ കഴിയുമെന്ന് സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നു.

കാഷെ മാനേജർ ഈ ഡാറ്റ ഒരു ബഫർ പൂളിൽ സംഭരിക്കുന്നു. ബഫറിൽ അവ ഇപ്പോഴും ആവശ്യമുണ്ടോ എന്നറിയാൻ ഇത് അവർക്ക് സേവന വിവരങ്ങളും (ട്രിഗർ, ലാച്ച്) ചേർക്കുന്നു.

ചിലപ്പോൾ പ്രകടനം നടത്തുന്നയാൾക്ക് തനിക്ക് എന്ത് ഡാറ്റ ആവശ്യമാണെന്ന് അറിയില്ല, അല്ലെങ്കിൽ ചില ഡാറ്റാബേസുകൾക്ക് അത്തരം പ്രവർത്തനക്ഷമതയില്ല. തുടർന്ന് ഊഹക്കച്ചവട പ്രീഫെച്ചിംഗ് ഉപയോഗിക്കുന്നു (ഉദാഹരണത്തിന്, എക്സിക്യൂട്ടർ ഡാറ്റ 1, 3, 5 അഭ്യർത്ഥിച്ചാൽ, ഭാവിയിൽ അവൻ ഒരുപക്ഷേ 7, 9, 11 അഭ്യർത്ഥിക്കും) അല്ലെങ്കിൽ തുടർച്ചയായ പ്രീഫെച്ചിംഗ് (ഈ സാഹചര്യത്തിൽ, DC അടുത്തത് ലോഡ് ചെയ്യുന്നു ഡിസ്ക് ഒരു കഷണം ഡാറ്റ ഓർഡർ ചെയ്യുക.

ലഭ്യമായ മെമ്മറിയുടെ അളവിൽ ബഫർ പരിമിതപ്പെടുത്തിയിട്ടുണ്ടെന്ന് നാം മറക്കരുത്. അതായത്, ചില ഡാറ്റ ലോഡുചെയ്യുന്നതിന്, മറ്റുള്ളവ ഇടയ്ക്കിടെ ഇല്ലാതാക്കേണ്ടതുണ്ട്. കാഷെ പൂരിപ്പിക്കുന്നതും മായ്‌ക്കുന്നതും ഡിസ്ക് സബ്സിസ്റ്റത്തിന്റെയും നെറ്റ്‌വർക്ക് ഉറവിടങ്ങളുടെയും ഒരു ഭാഗം ഉപയോഗിക്കുന്നു. നിങ്ങൾക്ക് പതിവായി പ്രവർത്തിക്കുന്ന ഒരു അന്വേഷണമുണ്ടെങ്കിൽ, അത് ഉപയോഗിക്കുന്ന ഡാറ്റ ഓരോ തവണയും ലോഡുചെയ്ത് വൃത്തിയാക്കുന്നത് വിപരീതഫലമായിരിക്കും. ഈ പ്രശ്നം പരിഹരിക്കാൻ, ആധുനിക ഡാറ്റാബേസുകൾ ഒരു ബഫർ മാറ്റിസ്ഥാപിക്കൽ തന്ത്രം ഉപയോഗിക്കുന്നു.

5.1.2. ബഫർ മാറ്റിസ്ഥാപിക്കൽ തന്ത്രങ്ങൾ

മിക്ക ഡാറ്റാബേസുകളും (കുറഞ്ഞത് SQL സെർവർ, MySQL, Oracle, DB2) ഇതിനായി LRU (ഏറ്റവും കുറച്ച് അടുത്തിടെ ഉപയോഗിച്ചത്) അൽഗോരിതം ഉപയോഗിക്കുന്നു. അടുത്തിടെ ഉപയോഗിച്ച കാഷെയിൽ ഡാറ്റ നിലനിർത്തുന്നതിനാണ് ഇത് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതായത് അത് വീണ്ടും ആവശ്യമായി വരാനുള്ള ഉയർന്ന സാധ്യതയുണ്ട്.

അൽഗോരിതം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസിലാക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, ബഫറിലെ ഡാറ്റ ട്രിഗറുകൾ (ലാച്ച്) തടഞ്ഞിട്ടില്ലെന്നും അതിനാൽ ഇല്ലാതാക്കാൻ കഴിയുമെന്നും ഞങ്ങൾ അനുമാനിക്കും. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ബഫറിന് മൂന്ന് ഡാറ്റ കഷണങ്ങൾ സംഭരിക്കാൻ കഴിയും:

1. കാഷെ മാനേജർ ഡാറ്റ 1 ഉപയോഗിക്കുകയും ഒരു ശൂന്യമായ ബഫറിൽ ഇടുകയും ചെയ്യുന്നു.
2. ഇത് ഡാറ്റ 4 ഉപയോഗിക്കുകയും ബഫറിലേക്കും അയയ്ക്കുകയും ചെയ്യുന്നു.
3. ഡാറ്റ 3 ലും ഇതുതന്നെയാണ് ചെയ്യുന്നത്.
4. അടുത്തതായി, ഡാറ്റ 9 എടുക്കുന്നു. എന്നാൽ ബഫർ ഇതിനകം നിറഞ്ഞിരിക്കുന്നു. അതിനാൽ, ഏറ്റവും കൂടുതൽ കാലം ഉപയോഗിക്കാത്തതിനാൽ ഡാറ്റ 1 അതിൽ നിന്ന് നീക്കംചെയ്യുന്നു. ഇതിനുശേഷം, ഡാറ്റ 9 ബഫറിൽ സ്ഥാപിച്ചിരിക്കുന്നു.
5. കാഷെ മാനേജർ ഡാറ്റ 4 വീണ്ടും ഉപയോഗിക്കുന്നു. ഇത് ഇതിനകം തന്നെ ബഫറിലാണ്, അതിനാൽ ഇത് അവസാനം ഉപയോഗിച്ചതായി അടയാളപ്പെടുത്തിയിരിക്കുന്നു.
6. ഡാറ്റ 1-ന് വീണ്ടും ആവശ്യക്കാരേറുന്നു. ബഫറിൽ സ്ഥാപിക്കാൻ, ഏറ്റവും കൂടുതൽ കാലം ഉപയോഗിക്കാത്തതിനാൽ അതിൽ നിന്ന് ഡാറ്റ 3 ഇല്ലാതാക്കി.

ഇതൊരു നല്ല അൽഗോരിതം ആണ്, എന്നാൽ ഇതിന് ചില പരിമിതികളുണ്ട്. നമ്മൾ ഒരു വലിയ ടേബിളിന്റെ പൂർണ്ണ സ്കാൻ ചെയ്യുകയാണെങ്കിലോ? പട്ടിക/സൂചിക വലുപ്പം ബഫർ വലുപ്പത്തേക്കാൾ കൂടുതലാണെങ്കിൽ എന്ത് സംഭവിക്കും? ഈ സാഹചര്യത്തിൽ, അൽഗോരിതം അതിന്റെ എല്ലാ ഉള്ളടക്കങ്ങളും കാഷെയിൽ നിന്ന് നീക്കം ചെയ്യും, അതിനാൽ പൂർണ്ണ സ്കാൻ ഡാറ്റ ഒരു തവണ മാത്രമേ ഉപയോഗിക്കൂ.

അൽഗോരിതം മെച്ചപ്പെടുത്തലുകൾ

ഇത് സംഭവിക്കുന്നത് തടയാൻ, ചില ഡാറ്റാബേസുകൾ പ്രത്യേക നിയമങ്ങൾ ഉപയോഗിക്കുന്നു. ഒറാക്കിൾ ഡോക്യുമെന്റേഷൻ അനുസരിച്ച്:

“വളരെ വലിയ ടേബിളുകൾക്ക്, ഡയറക്ട് ആക്‌സസ് സാധാരണയായി ഉപയോഗിക്കുന്നു, അതായത് കാഷെ ബഫർ ഓവർഫ്ലോകൾ ഒഴിവാക്കാൻ ഡാറ്റയുടെ ബ്ലോക്കുകൾ നേരിട്ട് വായിക്കുന്നു. ഇടത്തരം വലിപ്പമുള്ള പട്ടികകൾക്ക്, നേരിട്ടുള്ള ആക്‌സസ്സും കാഷെ റീഡുകളും ഉപയോഗിക്കാം. സിസ്റ്റം കാഷെ ഉപയോഗിക്കാൻ തീരുമാനിക്കുകയാണെങ്കിൽ, ബഫർ ഫ്ലഷിംഗ് തടയുന്നതിനായി ഡാറ്റാബേസ് LRU ലിസ്റ്റിന്റെ അവസാനം ഡാറ്റ ബ്ലോക്കുകൾ സ്ഥാപിക്കുന്നു."

എൽആർയു-യുടെ മെച്ചപ്പെട്ട പതിപ്പായ എൽആർയു-കെയും ഉപയോഗിക്കുന്നു. SQL സെർവർ K = 2 ഉപയോഗിച്ച് LRU-K ഉപയോഗിക്കുന്നു. ഈ അൽഗോരിതം സ്ഥിതിഗതികൾ വിലയിരുത്തുമ്പോൾ, മുൻകാല പ്രവർത്തനങ്ങളെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ കണക്കിലെടുക്കുന്നു, മാത്രമല്ല അവസാനം ഉപയോഗിച്ച ഡാറ്റ മാത്രം ഓർക്കുന്നു എന്നതാണ്. പേരിലെ കെ എന്ന അക്ഷരം അർത്ഥമാക്കുന്നത്, കഴിഞ്ഞ കെ തവണ ഉപയോഗിച്ച ഡാറ്റ അൽഗോരിതം കണക്കിലെടുക്കുന്നു എന്നാണ്. അവർക്ക് ഒരു നിശ്ചിത ഭാരം നിശ്ചയിച്ചിരിക്കുന്നു. പുതിയ ഡാറ്റ കാഷെയിലേക്ക് ലോഡ് ചെയ്യുമ്പോൾ, പഴയതും എന്നാൽ പതിവായി ഉപയോഗിക്കുന്നതുമായ ഡാറ്റ ഇല്ലാതാക്കില്ല, കാരണം അതിന്റെ ഭാരം കൂടുതലാണ്. തീർച്ചയായും, ഡാറ്റ മേലിൽ ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, അത് ഇപ്പോഴും ഇല്ലാതാക്കപ്പെടും. കൂടുതൽ കാലം ഡാറ്റ ക്ലെയിം ചെയ്യപ്പെടാതെ തുടരുന്നു, കാലക്രമേണ അതിന്റെ ഭാരം കുറയുന്നു.

ഭാരം കണക്കാക്കുന്നത് വളരെ ചെലവേറിയതാണ്, അതിനാൽ SQL സെർവർ LRU-K 2 ന് തുല്യമായ കെ ഉപയോഗിച്ച് ഉപയോഗിക്കുന്നു. നിങ്ങൾക്ക് അവനെ നന്നായി അറിയാൻ കഴിയും നന്ദി.

മറ്റ് അൽഗോരിതങ്ങൾ

തീർച്ചയായും, LRU-K മാത്രമല്ല പരിഹാരം. 2Q, CLOCK എന്നിവയും ഉണ്ട് (രണ്ടും LRU-K ന് സമാനമാണ്), MRU (ഏറ്റവും അടുത്തിടെ ഉപയോഗിച്ചത്, ഇത് LRU ലോജിക് ഉപയോഗിക്കുന്നതും എന്നാൽ മറ്റൊരു നിയമം ബാധകമാണ്, LRFU (ഏറ്റവും അടുത്തിടെ ഉപയോഗിക്കുന്നതും പതിവായി ഉപയോഗിക്കുന്നതും) മുതലായവ. ചില ഡാറ്റാബേസുകളിൽ നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം, എന്താണ് അൽഗോരിതം ഉപയോഗിക്കും.

5.1.3. ബഫർ എഴുതുക

ഞങ്ങൾ റീഡ് ബഫറിനെക്കുറിച്ച് മാത്രമാണ് സംസാരിച്ചത്, പക്ഷേ ഡാറ്റാബേസുകൾ റൈറ്റ് ബഫറുകളും ഉപയോഗിക്കുന്നു, അത് ഡാറ്റ ശേഖരിക്കുകയും തുടർച്ചയായി എഴുതുന്നതിനുപകരം ഭാഗങ്ങളായി ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യുകയും ചെയ്യുന്നു. ഇത് I/O പ്രവർത്തനങ്ങൾ സംരക്ഷിക്കുന്നു.
ബഫർ സ്റ്റോർ എന്ന് ഓർക്കുക പേജുകൾ(ഡാറ്റയുടെ അവിഭാജ്യ യൂണിറ്റുകൾ), പട്ടികകളിൽ നിന്നുള്ള വരികൾക്ക് പകരം. ബഫർ പൂളിലെ ഒരു പേജ് പരിഷ്കരിച്ചെങ്കിലും ഡിസ്കിൽ എഴുതിയില്ലെങ്കിൽ അത് വൃത്തികെട്ടതാണെന്ന് പറയപ്പെടുന്നു. വൃത്തികെട്ട പേജുകളുടെ എഴുത്ത് സമയം തിരഞ്ഞെടുക്കാൻ ഉപയോഗിക്കുന്ന നിരവധി വ്യത്യസ്ത അൽഗോരിതങ്ങൾ ഉണ്ട്. എന്നാൽ ഇടപാടുകൾ എന്ന ആശയവുമായി ഇതിന് വളരെയധികം ബന്ധമുണ്ട്.

5.2 ഇടപാട് മാനേജർ

ഓരോ അഭ്യർത്ഥനയും അതിന്റേതായ ഇടപാട് ഉപയോഗിച്ച് നടപ്പിലാക്കുന്നുവെന്ന് ഉറപ്പാക്കുക എന്നതാണ് അവന്റെ ഉത്തരവാദിത്തം. എന്നാൽ ഡിസ്പാച്ചറിനെക്കുറിച്ച് സംസാരിക്കുന്നതിന് മുമ്പ്, ACID ഇടപാടുകളുടെ ആശയം വ്യക്തമാക്കാം.

5.2.1. "ആസിഡിൽ" (ആർക്കെങ്കിലും മനസ്സിലാകുന്നില്ലെങ്കിൽ വാക്കുകൾ കളിക്കുക)

ഒരു ACID ഇടപാട് (ആറ്റോമിസിറ്റി, ഐസൊലേഷൻ, ഡ്യൂറബിലിറ്റി, കൺസിസ്റ്റൻസി) എന്നത് ഒരു പ്രാഥമിക പ്രവർത്തനമാണ്, 4 വ്യവസ്ഥകൾ പാലിക്കുന്ന ജോലിയുടെ ഒരു യൂണിറ്റ്:

• ആറ്റോമിസിറ്റി.ഒരു ഇടപാടിനേക്കാൾ "ചെറിയ" ഒന്നുമില്ല, ചെറിയ പ്രവർത്തനവുമില്ല. ഇടപാട് 10 മണിക്കൂർ നീണ്ടുനിന്നാലും. ഒരു ഇടപാട് പരാജയപ്പെടുകയാണെങ്കിൽ, സിസ്റ്റം "മുമ്പുള്ള" അവസ്ഥയിലേക്ക് മടങ്ങുന്നു, അതായത്, ഇടപാട് പിൻവലിക്കപ്പെടും.
• ഐസൊലേഷൻ. A, B എന്നീ രണ്ട് ഇടപാടുകൾ ഒരേ സമയം നിർവ്വഹിച്ചാൽ, അവയുടെ ഫലം അവയിലൊന്ന് നടപ്പിലാക്കുന്നതിന് മുമ്പോ, സമയത്തോ, ശേഷമോ പൂർത്തിയാക്കിയിട്ടുണ്ടോ എന്നതിനെ ആശ്രയിക്കരുത്.
• ഈട്.ഒരു ഇടപാട് നടത്തുമ്പോൾ, അതായത്, വിജയകരമായി പൂർത്തിയാകുമ്പോൾ, സാധ്യമായ സംഭവങ്ങൾ (പിശകുകൾ, ക്രാഷുകൾ) പരിഗണിക്കാതെ, അത് ഉപയോഗിച്ച ഡാറ്റ ഡാറ്റാബേസിൽ നിലനിൽക്കും.
• സ്ഥിരത.ഡാറ്റാബേസിൽ സാധുവായ ഡാറ്റ മാത്രമേ (റിലേഷണൽ, ഫങ്ഷണൽ കണക്ഷനുകളുടെ വീക്ഷണകോണിൽ നിന്ന്) രേഖപ്പെടുത്തിയിട്ടുള്ളൂ. സ്ഥിരത ആറ്റോമിസിറ്റിയെയും ഒറ്റപ്പെടലിനെയും ആശ്രയിച്ചിരിക്കുന്നു.

ഏതൊരു ഇടപാടിന്റെയും നിർവ്വഹണ വേളയിൽ, ഡാറ്റ വായിക്കാനും സൃഷ്‌ടിക്കാനും അപ്‌ഡേറ്റ് ചെയ്യാനും ഇല്ലാതാക്കാനും നിങ്ങൾക്ക് വിവിധ SQL ചോദ്യങ്ങൾ എക്‌സിക്യൂട്ട് ചെയ്യാൻ കഴിയും. രണ്ട് ഇടപാടുകൾ ഒരേ ഡാറ്റ ഉപയോഗിക്കുമ്പോൾ പ്രശ്നങ്ങൾ ആരംഭിക്കുന്നു. A അക്കൗണ്ടിൽ നിന്ന് B അക്കൗണ്ടിലേക്ക് പണം ട്രാൻസ്ഫർ ചെയ്യുന്നതാണ് ഒരു മികച്ച ഉദാഹരണം. നമുക്ക് രണ്ട് ഇടപാടുകൾ ഉണ്ടെന്ന് പറയാം:

• T1 അക്കൗണ്ടിൽ നിന്ന് $100 എടുത്ത് B അക്കൗണ്ടിലേക്ക് അയയ്ക്കുന്നു.
• T2 അക്കൗണ്ടിൽ നിന്ന് $50 എടുക്കുകയും അത് B അക്കൗണ്ടിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു.

ACID ഗുണങ്ങളുടെ വീക്ഷണകോണിൽ നിന്ന് ഈ സാഹചര്യം നോക്കാം:

• ആറ്റോമിസിറ്റി T1 (സെർവർ ക്രാഷ്, നെറ്റ്‌വർക്ക് പരാജയം) സമയത്ത് എന്ത് ഇവന്റ് സംഭവിച്ചാലും, A-യിൽ നിന്ന് $100 ഡെബിറ്റ് ചെയ്യപ്പെടും, പക്ഷേ B-യിലേക്ക് വരില്ല (അല്ലെങ്കിൽ അവർ "പൊരുത്തമില്ലാത്ത അവസ്ഥ"യെക്കുറിച്ച് സംസാരിക്കുന്നു) എന്ന് ഉറപ്പാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
• ഐസൊലേഷൻ T1 ഉം T2 ഉം ഒരേസമയം നടത്തിയാലും, അതിന്റെ ഫലമായി A-യിൽ നിന്ന് $100 ഡെബിറ്റ് ചെയ്യപ്പെടുകയും അതേ തുക B-യിലേക്ക് പോകുകയും ചെയ്യും. മറ്റെല്ലാ സാഹചര്യങ്ങളിലും, അവർ വീണ്ടും ഒരു പൊരുത്തമില്ലാത്ത അവസ്ഥയെക്കുറിച്ച് സംസാരിക്കുന്നു.
• വിശ്വാസ്യത T1 ചെയ്തതിന് ശേഷം ഡാറ്റാബേസ് ക്രാഷായാൽ T1 അപ്രത്യക്ഷമാകുമെന്ന് വിഷമിക്കേണ്ടതില്ല.
• സ്ഥിരതസിസ്റ്റത്തിൽ പണം സൃഷ്ടിക്കപ്പെടുകയോ നശിപ്പിക്കപ്പെടുകയോ ചെയ്യുന്നതിനുള്ള സാധ്യത തടയുന്നു.

നിങ്ങൾ താഴെ വായിക്കേണ്ടതില്ല, ബാക്കിയുള്ള കാര്യങ്ങൾ മനസ്സിലാക്കുന്നതിന് ഇത് ഇനി പ്രധാനമല്ല.

പല ഡാറ്റാബേസുകളും സ്ഥിരസ്ഥിതിയായി പൂർണ്ണമായ ഒറ്റപ്പെടൽ നൽകുന്നില്ല, കാരണം ഇത് ഒരു വലിയ പ്രകടനത്തിന് ഓവർഹെഡ് ചുമത്തുന്നു. SQL 4 ഐസൊലേഷൻ ലെവലുകൾ ഉപയോഗിക്കുന്നു:

• സീരിയലൈസ് ചെയ്യാവുന്ന ഇടപാടുകൾ.ഒറ്റപ്പെടലിന്റെ ഏറ്റവും ഉയർന്ന നില. SQLite-ൽ സ്ഥിരസ്ഥിതി. ഓരോ ഇടപാടും അതിന്റേതായ, പൂർണ്ണമായും ഒറ്റപ്പെട്ട അന്തരീക്ഷത്തിലാണ് നടപ്പിലാക്കുന്നത്.
• ആവർത്തിച്ചുള്ള വായന. MySQL-ൽ സ്ഥിരസ്ഥിതി. ഓരോ ഇടപാടിനും അതിന്റേതായ അന്തരീക്ഷമുണ്ട്, ഒരു സാഹചര്യം ഒഴികെ: ഇടപാട് ആണെങ്കിൽ പുതിയ ഡാറ്റ ചേർക്കുന്നുവിജയകരമായി പൂർത്തിയാക്കിയാൽ, അവ ഇപ്പോഴും പുരോഗമിക്കുന്ന മറ്റ് ഇടപാടുകൾക്ക് ദൃശ്യമാകും. എന്നാൽ ഇടപാട് എങ്കിൽ ഡാറ്റ പരിഷ്കരിക്കുന്നുവിജയകരമായി പൂർത്തിയാക്കുകയും, ഇപ്പോഴും പുരോഗമിക്കുന്ന ഇടപാടുകൾക്ക് ഈ മാറ്റങ്ങൾ ദൃശ്യമാകില്ല. അതായത്, പുതിയ ഡാറ്റയ്ക്ക് ഒറ്റപ്പെടലിന്റെ തത്വം ലംഘിക്കപ്പെടുന്നു.

  ഉദാഹരണത്തിന്, ഇടപാട് എ എക്സിക്യൂട്ട് ചെയ്യുന്നു

  TABLE_X-ൽ നിന്ന് എണ്ണം(1) തിരഞ്ഞെടുക്കുക
  തുടർന്ന് ഇടപാട് ബി ടേബിൾ X ചേർക്കുകയും പുതിയ ഡാറ്റ നൽകുകയും ചെയ്യുന്നു. ഈ ഇടപാടിന് ശേഷം A വീണ്ടും കൗണ്ട്(1) നടത്തുകയാണെങ്കിൽ, ഫലം വ്യത്യസ്തമായിരിക്കും.

  ഇതിനെ ഫാന്റം റീഡിംഗ് എന്ന് വിളിക്കുന്നു.

• പ്രതിബദ്ധതയുള്ള ഡാറ്റ വായിക്കുക. Oracle, PostgreSQL, SQL സെർവർ എന്നിവയിൽ സ്ഥിരസ്ഥിതിയായി ഉപയോഗിക്കുന്നു. ഇത് ആവർത്തിച്ചുള്ള വായനയ്ക്ക് സമാനമാണ്, എന്നാൽ ഒറ്റപ്പെടലിന്റെ അധിക ലംഘനം. ഇടപാട് എ ഡാറ്റ വായിക്കുന്നു എന്ന് പറയാം; ഈ പ്രവർത്തനങ്ങൾ നടത്തുന്ന ഇടപാട് ബി വഴി അവ പരിഷ്കരിക്കുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുന്നു. A ഈ ഡാറ്റ വീണ്ടും വായിക്കുകയാണെങ്കിൽ, B വരുത്തിയ മാറ്റങ്ങൾ (അല്ലെങ്കിൽ ഇല്ലാതാക്കിയ വസ്തുത) അവൾ കാണും.

  ഇതിനെ നോൺ റിപ്പീറ്റബിൾ റീഡ് എന്ന് വിളിക്കുന്നു.

• പ്രതിബദ്ധതയില്ലാത്ത ഡാറ്റ വായിക്കുക.ഒറ്റപ്പെടലിന്റെ ഏറ്റവും കുറഞ്ഞ നില. പ്രതിജ്ഞാബദ്ധമായ ഡാറ്റയുടെ വായനയിൽ ഒരു പുതിയ ഒറ്റപ്പെടൽ ലംഘനം ചേർത്തു. ഇടപാട് എ ഡാറ്റ വായിക്കുന്നു എന്ന് പറയാം; പിന്നീട് അവ ബി ഇടപാട് വഴി പരിഷ്ക്കരിക്കുന്നു (മാറ്റങ്ങൾ വരുത്തിയിട്ടില്ല, ബി ഇപ്പോഴും നടപ്പിലാക്കുന്നു). എ ഡാറ്റ വീണ്ടും വായിക്കുകയാണെങ്കിൽ, വരുത്തിയ മാറ്റങ്ങൾ അവൻ കാണും. B മടക്കിയാൽ, വീണ്ടും വായിക്കുമ്പോൾ, ഒന്നും സംഭവിക്കാത്തതുപോലെ, A മാറ്റങ്ങളൊന്നും കാണില്ല.

  ഇതിനെ വൃത്തികെട്ട വായന എന്ന് വിളിക്കുന്നു.

മിക്ക ഡാറ്റാബേസുകളും അവരുടേതായ ഒറ്റപ്പെടലിന്റെ തലങ്ങൾ ചേർക്കുന്നു (ഉദാഹരണത്തിന്, PostgreSQL, Oracle, SQL സെർവർ പോലെയുള്ള സ്നാപ്പ്ഷോട്ടുകളെ അടിസ്ഥാനമാക്കി). കൂടാതെ, പല ഡാറ്റാബേസുകളും മുകളിൽ വിവരിച്ച നാല് തലങ്ങളും നടപ്പിലാക്കുന്നില്ല, പ്രത്യേകിച്ച് കമ്മിറ്റഡ് ഡാറ്റ വായിക്കുന്നു.

കണക്ഷൻ സ്ഥാപിച്ച ഉടൻ തന്നെ ഉപയോക്താവിനോ ഡവലപ്പർക്കോ ഡിഫോൾട്ട് ഐസൊലേഷൻ ലെവൽ അസാധുവാക്കാനാകും. നിങ്ങൾ ചെയ്യേണ്ടത് വളരെ ലളിതമായ ഒരു കോഡ് ചേർക്കുകയാണ്.

5.2.2. കൺകറൻസി നിയന്ത്രണം

ഒരേ ഡാറ്റയിൽ (ചേർക്കുക, അപ്‌ഡേറ്റ് ചെയ്യുക, ഇല്ലാതാക്കുക) റൈറ്റ് ഓപ്പറേഷനുകൾ നടത്താനുള്ള കഴിവാണ് നമുക്ക് ഒറ്റപ്പെടലും സ്ഥിരതയും ആറ്റോമിസിറ്റിയും ആവശ്യമുള്ള പ്രധാന കാര്യം.

എല്ലാ ഇടപാടുകളും ഡാറ്റ മാത്രം വായിക്കുകയാണെങ്കിൽ, മറ്റ് ഇടപാടുകളെ ബാധിക്കാതെ അവയ്ക്ക് ഒരേസമയം പ്രവർത്തിക്കാനാകും.
കുറഞ്ഞത് ഒരു ഇടപാടെങ്കിലും മറ്റ് ഇടപാടുകൾ വായിച്ച ഡാറ്റ മാറ്റുകയാണെങ്കിൽ, ഈ മാറ്റങ്ങൾ അവരിൽ നിന്ന് മറയ്ക്കാൻ ഡാറ്റാബേസിന് ഒരു വഴി കണ്ടെത്തേണ്ടതുണ്ട്. മാറ്റിയ ഡാറ്റ കാണാത്ത മറ്റ് ഇടപാടുകൾ വരുത്തിയ മാറ്റങ്ങൾ ഇല്ലാതാക്കില്ലെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്.

ഇതിനെ കൺകറൻസി കൺട്രോൾ എന്ന് വിളിക്കുന്നു.

ഇടപാടുകൾ ഓരോന്നായി നടത്തുക എന്നതാണ് ഏറ്റവും എളുപ്പമുള്ള മാർഗം. എന്നാൽ ഈ സമീപനം സാധാരണയായി കാര്യക്ഷമമല്ല (ഒരു പ്രോസസറിന്റെ ഒരു കോർ മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ), കൂടാതെ സ്കെയിൽ ചെയ്യാനുള്ള കഴിവും നഷ്ടപ്പെടും.

പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള ഏറ്റവും അനുയോജ്യമായ മാർഗ്ഗം ഇതുപോലെ കാണപ്പെടുന്നു (ഓരോ തവണയും ഒരു ഇടപാട് സൃഷ്ടിക്കുമ്പോഴോ റദ്ദാക്കുമ്പോഴോ):

• ഓരോ ഇടപാടിന്റെയും എല്ലാ പ്രവർത്തനങ്ങളും നിരീക്ഷിക്കുക.
• ഒരേ ഡാറ്റ വായിക്കുന്നത്/മാറ്റുന്നത് കാരണം രണ്ടോ അതിലധികമോ ഇടപാടുകൾ വൈരുദ്ധ്യമുണ്ടെങ്കിൽ, കാരണങ്ങളുടെ എണ്ണം കുറയ്ക്കുന്നതിന് കക്ഷികൾക്കുള്ളിലെ പ്രവർത്തന ക്രമം മാറ്റുക.
• ഇടപാടുകളുടെ വൈരുദ്ധ്യമുള്ള ഭാഗങ്ങൾ ഒരു നിർദ്ദിഷ്ട ക്രമത്തിൽ നടപ്പിലാക്കുക. ഈ സമയത്ത് പരസ്പരവിരുദ്ധമല്ലാത്ത ഇടപാടുകൾ സമാന്തരമായി നടപ്പിലാക്കുന്നു.
• ഇടപാടുകൾ റദ്ദാക്കിയേക്കാമെന്ന കാര്യം ശ്രദ്ധിക്കുക.

ഞങ്ങൾ പ്രശ്നത്തെ കൂടുതൽ ഔപചാരികമായി സമീപിക്കുകയാണെങ്കിൽ, ഇത് പൊരുത്തക്കേടുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നതിന്റെ ഒരു പ്രശ്നമാണ്. ഇത് പരിഹരിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, ഒപ്റ്റിമൈസേഷന് വലിയ പ്രോസസ്സർ ഉറവിടങ്ങൾ ആവശ്യമാണ്. എന്റർപ്രൈസ് ഡാറ്റാബേസിന് ഓരോ പുതിയ ഇടപാടുകൾക്കും മികച്ച ഷെഡ്യൂളിനായി മണിക്കൂറുകൾ ചെലവഴിക്കാൻ കഴിയില്ല. അതിനാൽ, കുറച്ച് സങ്കീർണ്ണമായ സമീപനങ്ങളാണ് ഉപയോഗിക്കുന്നത്, അതിൽ കൂടുതൽ സമയം വൈരുദ്ധ്യങ്ങൾക്കായി ചെലവഴിക്കുന്നു.

5.2.3. ലോക്ക് മാനേജർ

മുകളിൽ വിവരിച്ച പ്രശ്നം പരിഹരിക്കാൻ, പല ഡാറ്റാബേസുകളും ലോക്കുകൾ കൂടാതെ/അല്ലെങ്കിൽ ഡാറ്റ പതിപ്പിംഗ് ഉപയോഗിക്കുന്നു.
ഒരു ഇടപാടിന് കുറച്ച് ഡാറ്റ ആവശ്യമുണ്ടെങ്കിൽ, അത് തടയുന്നു. മറ്റൊരു ഇടപാടിനും അവ ആവശ്യമാണെങ്കിൽ, ആദ്യ ഇടപാട് ലോക്ക് റിലീസ് ചെയ്യുന്നത് വരെ കാത്തിരിക്കേണ്ടി വരും.

ഇതിനെ എക്സ്ക്ലൂസീവ് ലോക്ക് എന്ന് വിളിക്കുന്നു.

എന്നാൽ ഇടപാടുകൾക്ക് ഡാറ്റ വായിക്കാൻ മാത്രം ആവശ്യമുള്ള സന്ദർഭങ്ങളിൽ എക്സ്ക്ലൂസീവ് ലോക്കുകൾ ഉപയോഗിക്കുന്നത് വളരെ പാഴായതാണ്. ഡാറ്റ റീഡിംഗിൽ ഇടപെടുന്നത് എന്തുകൊണ്ട്? അത്തരം സന്ദർഭങ്ങളിൽ, പങ്കിട്ട ലോക്കുകൾ ഉപയോഗിക്കുന്നു. ഒരു ഇടപാടിന് ഡാറ്റ വായിക്കണമെങ്കിൽ, അത് അതിൽ ഒരു പങ്കിട്ട ലോക്ക് പ്രയോഗിക്കുകയും അത് വായിക്കുകയും ചെയ്യുന്നു. മറ്റ് ഇടപാടുകൾ ലോക്കുകൾ പങ്കിടുന്നതിൽ നിന്നും ഡാറ്റ വായിക്കുന്നതിൽ നിന്നും ഇത് തടയുന്നില്ല. അവരിൽ ഒരാൾക്ക് ഡാറ്റ മാറ്റണമെങ്കിൽ, എല്ലാ ജോയിന്റ് ലോക്കുകളും റിലീസ് ചെയ്യുന്നതുവരെ അവൾ കാത്തിരിക്കേണ്ടിവരും. അപ്പോൾ മാത്രമേ അവൾക്ക് ഒരു പ്രത്യേക ലോക്ക് പ്രയോഗിക്കാൻ കഴിയൂ. ഈ ഡാറ്റ വായിക്കുന്നതിന് മറ്റെല്ലാ ഇടപാടുകളും അത് പിൻവലിക്കുന്നതുവരെ കാത്തിരിക്കേണ്ടിവരും.

ലോക്കുകൾ പ്രയോഗിക്കുകയും റിലീസ് ചെയ്യുകയും ചെയ്യുന്ന ഒരു പ്രക്രിയയാണ് ലോക്ക് മാനേജർ. അവ ഒരു ഹാഷ് ടേബിളിൽ സംഭരിച്ചിരിക്കുന്നു (കീകൾ ലോക്ക് ചെയ്തിരിക്കുന്ന ഡാറ്റയാണ്). ഏത് ഇടപാടുകളാണ് ലോക്കുകൾ പ്രയോഗിച്ചതെന്നോ അവ റിലീസ് ചെയ്യാൻ കാത്തിരിക്കുന്നതിനോ ഉള്ള എല്ലാ ഡാറ്റയും മാനേജർക്ക് അറിയാം.

ഡെഡ്‌ലോക്ക്

ലോക്കുകൾ ഉപയോഗിക്കുന്നത് രണ്ട് ഇടപാടുകൾ ലോക്കുകൾ റിലീസ് ചെയ്യുന്നതിനായി അനിശ്ചിതമായി കാത്തിരിക്കുന്ന ഒരു സാഹചര്യത്തിലേക്ക് നയിച്ചേക്കാം:

ഇവിടെ, ഇടപാട് എ ഡാറ്റ 1 പ്രത്യേകമായി ലോക്ക് ചെയ്യുകയും ഡാറ്റ 2 റിലീസ് ചെയ്യുന്നതിനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു. അതേ സമയം, ഇടപാട് ബി ഡാറ്റ 2 പ്രത്യേകമായി ലോക്ക് ചെയ്യുകയും ഡാറ്റ 1 റിലീസിനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു.

ഒരു ഡെഡ്‌ലോക്കിൽ, ഏത് ഇടപാടാണ് റദ്ദാക്കേണ്ടതെന്ന് ഡിസ്പാച്ചർ തിരഞ്ഞെടുക്കുന്നു (റോൾ ബാക്ക്). തീരുമാനം എടുക്കുന്നത് അത്ര എളുപ്പമല്ല:

• ഡാറ്റയുടെ അവസാന സെറ്റ് പരിഷ്കരിച്ച ഇടപാട് ഇല്ലാതാക്കുന്നത് നല്ലതാണോ (അതിനാൽ റോൾബാക്ക് ഏറ്റവും വേദനാജനകമായിരിക്കും)?
• മറ്റ് ഇടപാടുകളുടെ ഉപയോക്താക്കൾ കൂടുതൽ സമയം കാത്തിരിക്കുന്നതിനാൽ ഏറ്റവും പ്രായം കുറഞ്ഞ ഇടപാട് ഇല്ലാതാക്കുന്നത് നല്ലതാണോ?
• പൂർത്തിയാകാൻ കുറച്ച് സമയമെടുക്കുന്ന ഒരു ഇടപാട് ഇല്ലാതാക്കുന്നത് നല്ലതാണോ?
• റോൾബാക്ക് മറ്റ് എത്ര ഇടപാടുകളെ ബാധിക്കും?

എന്നാൽ ഒരു തീരുമാനം എടുക്കുന്നതിന് മുമ്പ്, ഡെഡ്‌ലോക്ക് യഥാർത്ഥത്തിൽ സംഭവിച്ചിട്ടുണ്ടോ എന്ന് ഡിസ്പാച്ചർ പരിശോധിക്കണം.

മുകളിലുള്ള ചിത്രത്തിലെന്നപോലെ ഒരു ഡയഗ്രം രൂപത്തിൽ ഒരു ഹാഷ് ടേബിൾ നമുക്ക് സങ്കൽപ്പിക്കാം. ഡയഗ്രാമിൽ ഒരു ചാക്രിക ബന്ധം ഉണ്ടെങ്കിൽ, ഡെഡ്‌ലോക്ക് സ്ഥിരീകരിച്ചു. എന്നാൽ സൈക്കിളുകൾക്കായി പരിശോധിക്കുന്നത് വളരെ ചെലവേറിയതിനാൽ (എല്ലാത്തിനുമുപരി, എല്ലാ ലോക്കുകളും കാണിക്കുന്ന ഡയഗ്രം വളരെ വലുതായിരിക്കും), ലളിതമായ ഒരു സമീപനം പലപ്പോഴും ഉപയോഗിക്കുന്നു: സമയപരിധികൾ ഉപയോഗിച്ച്. ഒരു നിശ്ചിത സമയത്തിനുള്ളിൽ ലോക്ക് റിലീസ് ചെയ്തില്ലെങ്കിൽ, ഇടപാട് ഒരു ഡെഡ്‌ലോക്ക് അവസ്ഥയിലേക്ക് പ്രവേശിച്ചു.

ഒരു ലോക്ക് പ്രയോഗിക്കുന്നതിന് മുമ്പ്, ഡിസ്പാച്ചർക്ക് അത് ഒരു തടസ്സത്തിന് കാരണമാകുമോ എന്ന് പരിശോധിക്കാനും കഴിയും. എന്നാൽ ഇതിന് വ്യക്തമായ ഉത്തരം നൽകാൻ, നിങ്ങൾ കണക്കുകൂട്ടലുകൾക്കായി പണം ചെലവഴിക്കേണ്ടിവരും. അതിനാൽ, അത്തരം പ്രീ-ചെക്കുകൾ പലപ്പോഴും അടിസ്ഥാന നിയമങ്ങളുടെ ഒരു കൂട്ടമായി അവതരിപ്പിക്കപ്പെടുന്നു.

രണ്ട്-ഘട്ട തടയൽ

സമ്പൂർണ്ണ ഐസൊലേഷൻ നേടാനുള്ള എളുപ്പവഴി, തുടക്കത്തിൽ ഒരു ലോക്ക് പ്രയോഗിക്കുകയും ഇടപാടിന്റെ അവസാനം റിലീസ് ചെയ്യുകയും ചെയ്യുക എന്നതാണ്. ഇതിനർത്ഥം, ഒരു ഇടപാട് ആരംഭിക്കുന്നതിന് മുമ്പ് എല്ലാ ലോക്കുകളും റിലീസ് ചെയ്യുന്നതുവരെ കാത്തിരിക്കണം, കൂടാതെ അത് പ്രയോഗിച്ച ലോക്കുകൾ പൂർത്തിയാകുമ്പോൾ മാത്രമേ റിലീസ് ചെയ്യുകയുള്ളൂ. ഈ സമീപനം ഉപയോഗിക്കാൻ കഴിയും, എന്നാൽ പിന്നീട് എല്ലാ ലോക്കുകളും റിലീസ് ചെയ്യുന്നതിനായി കാത്തിരിക്കുന്നത് ധാരാളം സമയം പാഴാക്കുന്നു.

DB2, SQL സെർവർ എന്നിവ രണ്ട്-ഘട്ട ലോക്കിംഗ് പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു, ഇത് ഒരു ഇടപാടിനെ രണ്ട് ഘട്ടങ്ങളായി വിഭജിക്കുന്നു:

• വളരുന്ന ഘട്ടം, ഒരു ഇടപാടിന് ലോക്കുകൾ മാത്രമേ പ്രയോഗിക്കാൻ കഴിയൂ, പക്ഷേ അവ റിലീസ് ചെയ്യാൻ കഴിയില്ല.
• ചുരുങ്ങുന്ന ഘട്ടം, ഒരു ഇടപാടിന് ലോക്കുകൾ മാത്രമേ റിലീസ് ചെയ്യാൻ കഴിയൂ (ഇതിനകം പ്രോസസ്സ് ചെയ്‌തതും വീണ്ടും പ്രോസസ്സ് ചെയ്യാത്തതുമായ ഡാറ്റയിൽ), എന്നാൽ പുതിയവ പ്രയോഗിക്കാൻ കഴിയില്ല.

രണ്ട്-ഘട്ട ലോക്കിംഗിന്റെ അഭാവത്തിൽ സംഭവിക്കുന്ന ഒരു സാധാരണ വൈരുദ്ധ്യം ഇതാണ്:

ഇടപാടിന് മുമ്പ് A, X = 1, Y = 1. ഇത് ഡാറ്റ Y = 1 പ്രോസസ്സ് ചെയ്യുന്നു, ഇത് ഇടപാട് A ആരംഭിച്ചതിന് ശേഷം ഇടപാട് B വഴി മാറ്റി. ഒറ്റപ്പെടലിന്റെ തത്വം കാരണം, ഇടപാട് A Y = 2 പ്രോസസ്സ് ചെയ്യണം.

ഈ രണ്ട് ലളിതമായ നിയമങ്ങൾ ഉപയോഗിച്ച് നേടിയ ലക്ഷ്യങ്ങൾ:

• മറ്റ് ഇടപാടുകൾക്കുള്ള കാത്തിരിപ്പ് സമയം കുറയ്ക്കാൻ ഇനി ആവശ്യമില്ലാത്ത ലോക്കുകൾ റിലീസ് ചെയ്യുക.
• മുമ്പ് നടന്ന ഒരു ഇടപാട് വഴി പരിഷ്കരിച്ച ഡാറ്റ ഇടപാടിന് ലഭിക്കുന്ന കേസുകൾ തടയുക. അത്തരം ഡാറ്റ അഭ്യർത്ഥിച്ച ഡാറ്റയുമായി പൊരുത്തപ്പെടുന്നില്ല.

ഇടപാട് ഡാറ്റ പരിഷ്ക്കരിക്കുകയും അതിൽ നിന്ന് ലോക്ക് നീക്കം ചെയ്യുകയും തുടർന്ന് റദ്ദാക്കുകയും ചെയ്ത സാഹചര്യം ഒഴികെ, ഈ പ്രോട്ടോക്കോൾ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, മറ്റൊരു ഇടപാടിന് ഡാറ്റ വായിക്കാനും മാറ്റാനും കഴിയും, അത് പിന്നീട് റോൾബാക്ക് ചെയ്യും. ഈ സാഹചര്യം ഒഴിവാക്കാൻ, ഇടപാട് പൂർത്തിയാകുമ്പോൾ എല്ലാ എക്സ്ക്ലൂസീവ് ലോക്കുകളും റിലീസ് ചെയ്യണം.

തീർച്ചയായും, യഥാർത്ഥ ഡാറ്റാബേസുകൾ കൂടുതൽ സങ്കീർണ്ണമായ സിസ്റ്റങ്ങൾ, കൂടുതൽ തരം ലോക്കുകൾ, കൂടുതൽ ഗ്രാനുലാരിറ്റി (വരികൾ, പേജുകൾ, പാർട്ടീഷനുകൾ, പട്ടികകൾ, ടേബിൾസ്പേസുകൾ എന്നിവയിലെ ലോക്കുകൾ) ഉപയോഗിക്കുന്നു, എന്നാൽ സാരാംശം ഒന്നുതന്നെയാണ്.

ഡാറ്റ പതിപ്പ്

ഇടപാട് വൈരുദ്ധ്യ പ്രശ്നം പരിഹരിക്കാനുള്ള മറ്റൊരു മാർഗ്ഗം ഡാറ്റ പതിപ്പ് ഉപയോഗിക്കുക എന്നതാണ്.

• എല്ലാ ഇടപാടുകൾക്കും ഒരേ സമയം ഒരേ ഡാറ്റ പരിഷ്കരിക്കാനാകും.
• ഓരോ ഇടപാടും ഡാറ്റയുടെ സ്വന്തം പകർപ്പ് (പതിപ്പ്) ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്.
• രണ്ട് ഇടപാടുകൾ ഒരേ ഡാറ്റ പരിഷ്‌ക്കരിക്കുകയാണെങ്കിൽ, പരിഷ്‌ക്കരണങ്ങളിൽ ഒന്ന് മാത്രമേ സ്വീകരിക്കുകയുള്ളൂ, മറ്റൊന്ന് നിരസിക്കപ്പെടും, അത് നടത്തിയ ഇടപാട് പിൻവലിക്കപ്പെടും (ഒരുപക്ഷേ പുനരാരംഭിച്ചേക്കാം).

ഉൽപ്പാദനക്ഷമത വർദ്ധിപ്പിക്കാൻ ഇത് അനുവദിക്കുന്നു കാരണം:

• വായന ഇടപാടുകൾ എഴുത്ത് ഇടപാടുകളെ തടയില്ല, തിരിച്ചും.
• ക്ലങ്കി ലോക്ക് മാനേജർക്ക് യാതൊരു സ്വാധീനവുമില്ല.

പൊതുവേ, രണ്ട് ഇടപാടുകൾ ഒരേ ഡാറ്റ എഴുതുന്നില്ലെങ്കിൽ, ലോക്കുകളേക്കാൾ എന്തും മികച്ചതായിരിക്കും. മാത്രമല്ല, ഇത് ഡിസ്ക് സ്പേസ് ഒരു വലിയ പാഴാക്കാൻ ഇടയാക്കും.

രണ്ട് സമീപനങ്ങൾക്കും - ലോക്കിംഗും പതിപ്പിംഗും - ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്, അവ ഉപയോഗിക്കുന്ന സാഹചര്യത്തെ ആശ്രയിച്ചിരിക്കുന്നു (കൂടുതൽ വായനകൾ അല്ലെങ്കിൽ കൂടുതൽ എഴുത്തുകൾ). PostgreSQL-ൽ മൾട്ടിവേർഷൻ കൺകറൻസി കൺട്രോൾ നടപ്പിലാക്കുന്നതിനെക്കുറിച്ചുള്ള ഒരു നല്ല അവതരണം നിങ്ങൾക്ക് പഠിക്കാം.

ചില ഡാറ്റാബേസുകൾ (DB2 പതിപ്പ് 9.7-ന് മുമ്പുള്ള, SQL സെർവർ) ലോക്കുകൾ മാത്രം ഉപയോഗിക്കുന്നു. PostgreSQL, MySQL, Oracle എന്നിവ പോലെയുള്ളവ സംയോജിത സമീപനങ്ങൾ ഉപയോഗിക്കുന്നു.

കുറിപ്പ്: പതിപ്പ് സൂചികകളിൽ രസകരമായ സ്വാധീനം ചെലുത്തുന്നു. ചിലപ്പോൾ ഒരു അദ്വിതീയ സൂചികയിൽ തനിപ്പകർപ്പുകൾ ഉണ്ട്, സൂചികയിൽ പട്ടികയിലെ വരികളേക്കാൾ കൂടുതൽ റെക്കോർഡുകൾ അടങ്ങിയിരിക്കാം.

ഡാറ്റയുടെ ഒരു ഭാഗം ഒരു ഐസൊലേഷൻ തലത്തിൽ വായിക്കുകയും അത് വർദ്ധിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ലോക്കുകളുടെ എണ്ണം വർദ്ധിക്കുന്നു, അതായത് ഇടപാടുകൾക്കായി കൂടുതൽ സമയം നഷ്ടപ്പെടും. അതിനാൽ, മിക്ക ഡാറ്റാബേസുകളും ഡിഫോൾട്ടായി പരമാവധി ഐസൊലേഷൻ ലെവൽ ഉപയോഗിക്കുന്നില്ല.

എല്ലായ്പ്പോഴും എന്നപോലെ, കൂടുതൽ വിവരങ്ങൾക്ക് ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുക: MySQL, PostgreSQL, Oracle.

5.2.4. ലോഗ് മാനേജർ

ഞങ്ങൾക്ക് ഇതിനകം അറിയാവുന്നതുപോലെ, പ്രകടനം വർദ്ധിപ്പിക്കുന്നതിന്, ഡാറ്റാബേസ് ഡാറ്റയുടെ ഒരു ഭാഗം ബഫർ മെമ്മറിയിൽ സംഭരിക്കുന്നു. എന്നാൽ ഇടപാട് നടത്തുമ്പോൾ സെർവർ തകരാറിലായാൽ മെമ്മറിയിലെ ഡാറ്റ നഷ്ടപ്പെടും. ഇത് ഇടപാടിന്റെ വിശ്വാസ്യതയുടെ തത്വത്തെ ലംഘിക്കുന്നു.

തീർച്ചയായും, നിങ്ങൾക്ക് എല്ലാം ഡിസ്കിലേക്ക് എഴുതാൻ കഴിയും, പക്ഷേ അത് തകരാറിലായാൽ നിങ്ങൾക്ക് എഴുതപ്പെടാത്ത ഡാറ്റ അവശേഷിക്കും, ഇത് ആറ്റോമിസിറ്റി തത്വത്തിന്റെ ലംഘനമാണ്.

ഇടപാട് എഴുതിയ എല്ലാ മാറ്റങ്ങളും പിൻവലിക്കുകയോ പൂർത്തിയാക്കുകയോ ചെയ്യണം.

ഇത് രണ്ട് തരത്തിലാണ് ചെയ്യുന്നത്:

• ഷാഡോ കോപ്പികൾ/പേജുകൾ.ഓരോ ഇടപാടും ഡാറ്റാബേസിന്റെ (അല്ലെങ്കിൽ അതിന്റെ ഭാഗം) സ്വന്തം പകർപ്പ് സൃഷ്ടിക്കുകയും ഈ പകർപ്പിനൊപ്പം പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. ഒരു പിശക് സംഭവിച്ചാൽ, പകർപ്പ് ഇല്ലാതാക്കപ്പെടും. എല്ലാം ശരിയായി നടന്നാൽ, ഫയൽ സിസ്റ്റം തലത്തിൽ ഒരു ട്രിക്ക് ഉപയോഗിച്ച് ഡാറ്റാബേസ് തൽക്ഷണം പകർപ്പിൽ നിന്നുള്ള ഡാറ്റയിലേക്ക് മാറുന്നു, തുടർന്ന് "പഴയ" ഡാറ്റ ഇല്ലാതാക്കുന്നു.
• ഇടപാട് ലോഗ്.ഇത് ഒരു പ്രത്യേക സ്റ്റോറേജ് സൗകര്യമാണ്. ഓരോ ഡിസ്കിലും എഴുതുന്നതിന് മുമ്പ്, ഡാറ്റാബേസ് ഇടപാട് ലോഗിലേക്ക് വിവരങ്ങൾ എഴുതുന്നു. അതിനാൽ പരാജയപ്പെടുകയാണെങ്കിൽ, തീർപ്പാക്കാത്ത ഇടപാട് എങ്ങനെ ഇല്ലാതാക്കാമെന്നോ പൂർത്തിയാക്കാമെന്നോ ഡാറ്റാബേസിന് അറിയാം.

വാൾ

നിരവധി ഇടപാടുകളുള്ള വലിയ ഡാറ്റാബേസുകളിൽ, ഷാഡോ പകർപ്പുകൾ/പേജുകൾ അവിശ്വസനീയമാംവിധം വലിയ അളവിൽ ഡിസ്ക് സ്പേസ് എടുക്കുന്നു. അതിനാൽ, ആധുനിക ഡാറ്റാബേസുകൾ ഒരു ഇടപാട് ലോഗ് ഉപയോഗിക്കുന്നു. ഇത് സുരക്ഷിതമല്ലാത്ത സ്റ്റോറേജിൽ സ്ഥാപിക്കണം.

മിക്ക ഉൽപ്പന്നങ്ങളും (പ്രത്യേകിച്ച്, Oracle, SQL സെർവർ, DB2, PostgreSQL, MySQL, SQLite) ഇടപാട് ലോഗുകൾ ഉപയോഗിച്ച് WAL (റൈറ്റ്-എഹെഡ് ലോഗിംഗ്) പ്രോട്ടോക്കോൾ വഴി പ്രവർത്തിക്കുന്നു. ഈ പ്രോട്ടോക്കോളിൽ മൂന്ന് നിയമങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

1. ഡാറ്റാബേസിലെ ഓരോ പരിഷ്ക്കരണവും ഒരു ലോഗ് എൻട്രിയോടൊപ്പമുണ്ടായിരിക്കണം, കൂടാതെ ഡാറ്റ ഡിസ്കിൽ എഴുതുന്നതിന് മുമ്പ് അത് ഉണ്ടാക്കിയിരിക്കണം.
2. ലോഗിലെ എൻട്രികൾ പ്രസക്തമായ ഇവന്റുകളുടെ ക്രമത്തിന് അനുസൃതമായി ക്രമീകരിക്കണം.
3. ഒരു ഇടപാട് നടത്തുമ്പോൾ, ഇടപാട് വിജയകരമായി പൂർത്തിയാകുന്നതിന് മുമ്പ് അതിന്റെ ഒരു റെക്കോർഡ് ലോഗിൽ എഴുതണം.

ഈ നിയമങ്ങൾ നടപ്പിലാക്കുന്നത് ലോഗ് മാനേജർ നിരീക്ഷിക്കുന്നു. കാഷെ മാനേജറിനും ഡാറ്റ ആക്സസ് മാനേജറിനും ഇടയിലാണ് ഇത് യുക്തിസഹമായി സ്ഥിതിചെയ്യുന്നത്. ഡിസ്കിൽ എഴുതുന്നത് വരെ ഇടപാടുകൾ നടത്തുന്ന എല്ലാ പ്രവർത്തനങ്ങളും ലോഗ് മാനേജർ ലോഗ് ചെയ്യുന്നു. ശരിയാണെന്ന് തോന്നുന്നു?

തെറ്റ്! ഈ ലേഖനത്തിൽ നമ്മൾ അനുഭവിച്ച എല്ലാത്തിനും ശേഷം, ഡാറ്റാബേസുമായി ബന്ധപ്പെട്ട എല്ലാം "ഡാറ്റാബേസ് ഇഫക്റ്റിന്റെ" ശാപത്തിന് വിധേയമാണെന്ന് ഓർമ്മിക്കേണ്ട സമയമാണിത്. ഗുരുതരമായി, മികച്ച പ്രകടനം നിലനിർത്തിക്കൊണ്ടുതന്നെ ലോഗിലേക്ക് എഴുതാൻ നിങ്ങൾ ഒരു വഴി കണ്ടെത്തേണ്ടതുണ്ട് എന്നതാണ് പ്രശ്നം. എല്ലാത്തിനുമുപരി, ഇടപാട് ലോഗ് മന്ദഗതിയിലാണെങ്കിൽ, അത് മറ്റെല്ലാ പ്രക്രിയകളെയും മന്ദഗതിയിലാക്കുന്നു.

ഏരീസ്

1992-ൽ, IBM-ലെ ഗവേഷകർ WAL-ന്റെ ഒരു വിപുലീകൃത പതിപ്പ് സൃഷ്ടിച്ചു, അതിനെ അവർ ARIES എന്ന് വിളിച്ചു. ഒരു രൂപത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ, മിക്ക ആധുനിക ഡാറ്റാബേസുകളും ARIES ഉപയോഗിക്കുന്നു. നിങ്ങൾക്ക് ഈ പ്രോട്ടോക്കോൾ കൂടുതൽ ആഴത്തിൽ പഠിക്കണമെങ്കിൽ, നിങ്ങൾക്ക് അനുബന്ധ ജോലി പഠിക്കാം.

അതിനാൽ, ARIES എന്നതിന്റെ അർത്ഥം എവേണ്ടിയുള്ള അൽഗോരിതങ്ങൾ ആർ ecovery ഒപ്പം ഐസോലേഷൻ ഇചൂഷണം ചെയ്യുന്നു എസ്മാന്റിക്സ്. ഈ സാങ്കേതികവിദ്യയ്ക്ക് രണ്ട് ജോലികൾ ഉണ്ട്:

1. ലോഗുകൾ എഴുതുമ്പോൾ നല്ല പ്രകടനം നൽകുക.
2. വേഗതയേറിയതും വിശ്വസനീയവുമായ വീണ്ടെടുക്കൽ ഉറപ്പാക്കുക.

ഒരു ഡാറ്റാബേസിന് ഒരു ഇടപാട് പിൻവലിക്കേണ്ടിവരുന്നതിന് നിരവധി കാരണങ്ങളുണ്ട്:

1. ഉപയോക്താവ് അത് റദ്ദാക്കി.
2. സെർവർ അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് പിശക്.
3. ഇടപാട് ഡാറ്റാബേസിന്റെ സമഗ്രത ലംഘിച്ചു. ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു നിരയിലേക്ക് UNIQUE വ്യവസ്ഥ പ്രയോഗിച്ചു, ഇടപാട് ഒരു ഡ്യൂപ്ലിക്കേറ്റ് ചേർത്തു.
4. തടസ്സങ്ങളുടെ സാന്നിധ്യം.

എന്നാൽ ചിലപ്പോൾ ഡാറ്റാബേസിന് ഒരു ഇടപാട് പുനഃസ്ഥാപിക്കാനും കഴിയും, ഉദാഹരണത്തിന്, ഒരു നെറ്റ്‌വർക്ക് പിശക് സംഭവിക്കുമ്പോൾ.

ഇത് എങ്ങനെ സാധിക്കും? ഇതിന് ഉത്തരം നൽകാൻ, ലോഗിൽ എന്ത് വിവരങ്ങളാണ് സംഭരിച്ചിരിക്കുന്നതെന്ന് നിങ്ങൾ ആദ്യം മനസ്സിലാക്കേണ്ടതുണ്ട്.

രേഖകൾ
ഒരു ഇടപാടിന്റെ നിർവ്വഹണ സമയത്ത് ഓരോ പ്രവർത്തനവും (ചേർക്കുന്നു/ഇല്ലാതാക്കുന്നു/മാറ്റുന്നത്) ലോഗിൽ ഒരു എൻട്രി പ്രത്യക്ഷപ്പെടുന്നതിലേക്ക് നയിക്കുന്നു. എൻട്രിയിൽ അടങ്ങിയിരിക്കുന്നു:

• LSN (ലോഗ് സീക്വൻസ് നമ്പർ). ഇത് ഒരു അദ്വിതീയ സംഖ്യയാണ്, അതിന്റെ അർത്ഥം കാലക്രമത്തിൽ നിർണ്ണയിക്കപ്പെടുന്നു. അതായത്, ഓപ്പറേഷൻ B-യ്‌ക്ക് മുമ്പാണ് ഓപ്പറേഷൻ A സംഭവിച്ചതെങ്കിൽ, A-യുടെ LSN B-യ്‌ക്കുള്ള LSN-നേക്കാൾ കുറവായിരിക്കും. വാസ്തവത്തിൽ, ഒരു LSN സൃഷ്‌ടിക്കുന്ന രീതി കൂടുതൽ സങ്കീർണ്ണമാണ്, കാരണം ഇത് ലോഗ് സംഭരിക്കുന്ന രീതിയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.
• TransID.പ്രവർത്തനം നടത്തിയ ഇടപാടിന്റെ ഐഡി.
• പേജ് ഐഡി. മാറിയ ഡാറ്റ സ്ഥിതിചെയ്യുന്ന ഡിസ്കിലെ സ്ഥാനം.
• PrevLSN. ഇതേ ഇടപാട് സൃഷ്‌ടിച്ച മുൻ ലോഗ് എൻട്രിയിലേക്കുള്ള ലിങ്ക്.
• പഴയപടിയാക്കുക. ഒരു ഓപ്പറേഷൻ പിൻവലിക്കാനുള്ള ഒരു രീതി.

  ഉദാഹരണത്തിന്, ഒരു അപ്‌ഡേറ്റ് ഓപ്പറേഷൻ നടത്തിയിട്ടുണ്ടെങ്കിൽ, മാറിയ മൂലകത്തിന്റെ (ഫിസിക്കൽ UNDO) മുമ്പത്തെ മൂല്യം/സ്ഥിതി അല്ലെങ്കിൽ മുമ്പത്തെ അവസ്ഥയിലേക്ക് (ലോജിക്കൽ UNDO) മടങ്ങാൻ നിങ്ങളെ അനുവദിക്കുന്ന റിവേഴ്‌സ് ഓപ്പറേഷൻ UNDO-യിൽ എഴുതിയിരിക്കുന്നു. ARIES യുക്തിസഹമായവ മാത്രം ഉപയോഗിക്കുന്നു; ശാരീരികമായവയുമായി പ്രവർത്തിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

• വീണ്ടും ചെയ്യുക. പ്രവർത്തനം ആവർത്തിക്കുന്ന രീതി.

കൂടാതെ, ഡിസ്കിലെ ഓരോ പേജിലും (ഡാറ്റ സംഭരിക്കുന്നതിന്, ലോഗുകൾ അല്ല) അവിടെ അടങ്ങിയിരിക്കുന്ന ഡാറ്റ പരിഷ്കരിച്ച അവസാന പ്രവർത്തനത്തിന്റെ LSN അടങ്ങിയിരിക്കുന്നു.

നമുക്കറിയാവുന്നിടത്തോളം, UNDO PostgreSQL-ൽ മാത്രം ഉപയോഗിക്കുന്നില്ല. പകരം, ഡാറ്റയുടെ പഴയ പതിപ്പുകൾ വൃത്തിയാക്കാൻ ഒരു ഗാർബേജ് കളക്ടർ ഉപയോഗിക്കുന്നു. ഈ DBMS-ൽ ഡാറ്റ പതിപ്പ് നടപ്പിലാക്കിയതാണ് ഇതിന് കാരണം.

ഒരു ലോഗ് എൻട്രിയുടെ കോമ്പോസിഷൻ നിങ്ങൾക്ക് സങ്കൽപ്പിക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, വ്യക്തിയുടെ സെറ്റ് പ്രായം = 18; എന്നതിൽ നിന്ന് അപ്‌ഡേറ്റ് ചെയ്യുക; ഇടപാട് നമ്പർ 18-ൽ ഇത് നടപ്പിലാക്കട്ടെ:

ഓരോ ലോഗിനും ഒരു അദ്വിതീയ LSN ഉണ്ട്. ലിങ്ക് ചെയ്‌ത ലോഗുകൾ ഒരേ ഇടപാടിനെ പരാമർശിക്കുന്നു, അവ കാലക്രമത്തിൽ ലിങ്ക് ചെയ്‌തിരിക്കുന്നു (ലിസ്റ്റിലെ അവസാന ലോഗ് അവസാന പ്രവർത്തനത്തെ സൂചിപ്പിക്കുന്നു).

ലോഗ് ബഫർ
ലോഗിംഗ് ഒരു സിസ്റ്റം തടസ്സമാകുന്നത് തടയാൻ, ഒരു ലോഗ് ബഫർ ഉപയോഗിക്കുന്നു.

ക്വറി റണ്ണർ പരിഷ്കരിച്ച ഡാറ്റ അഭ്യർത്ഥിക്കുമ്പോൾ:

1. കാഷെ മാനേജർ അവയെ ഒരു ബഫറിൽ സംഭരിക്കുന്നു.
2. ലോഗ് മാനേജർ അതിന്റെ സ്വന്തം ബഫറിൽ അനുബന്ധ ലോഗ് സംഭരിക്കുന്നു.
3. പ്രവർത്തനം പൂർത്തിയായിട്ടുണ്ടോ എന്നും അതനുസരിച്ച്, മാറ്റിയ ഡാറ്റ അഭ്യർത്ഥിക്കാനാകുമോ എന്നും അന്വേഷണ എക്സിക്യൂട്ടർ നിർണ്ണയിക്കുന്നു.
4. ലോഗ് മാനേജർ ആവശ്യമായ വിവരങ്ങൾ ഇടപാട് ലോഗിൽ സംഭരിക്കുന്നു. ഈ എൻട്രി ഉണ്ടാക്കുന്ന നിമിഷം അൽഗോരിതം നിർണ്ണയിക്കുന്നു.
5. കാഷെ മാനേജർ ഡിസ്കിലേക്ക് മാറ്റങ്ങൾ എഴുതുന്നു. റെക്കോർഡിംഗിന്റെ നിമിഷവും അൽഗോരിതം സജ്ജീകരിച്ചിരിക്കുന്നു.

ഒരു ഇടപാട് നടക്കുമ്പോൾ, 1 മുതൽ 5 വരെയുള്ള എല്ലാ ഘട്ടങ്ങളും പൂർത്തിയായി എന്നാണ് ഇതിനർത്ഥം. ഇടപാട് ലോഗിലേക്ക് എഴുതുന്നത് വേഗത്തിലാണ്, കാരണം അത് "ഇടപാട് ലോഗിലേക്ക് എവിടെയോ ലോഗ് ചേർക്കുന്നത്" പ്രതിനിധീകരിക്കുന്നു. അതേ സമയം, ഡിസ്കിലേക്ക് ഡാറ്റ എഴുതുന്നത് കൂടുതൽ സങ്കീർണ്ണമായ ഒരു നടപടിക്രമമാണ്, ഡാറ്റ പിന്നീട് വേഗത്തിൽ വായിക്കേണ്ടതുണ്ട്.

സ്റ്റീൽ, ഫോഴ്‌സ് നയങ്ങൾ

പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിന്, പ്രതിജ്ഞാബദ്ധതയ്ക്ക് ശേഷം ഘട്ടം നമ്പർ 5 ചെയ്യണം, കാരണം പരാജയപ്പെട്ടാൽ REDO ഉപയോഗിച്ച് ഇടപാട് പുനഃസ്ഥാപിക്കാൻ ഇപ്പോഴും സാധ്യമാണ്. ഇതിനെ NO-FORCE നയം എന്ന് വിളിക്കുന്നു.

എന്നാൽ വീണ്ടെടുക്കൽ സമയത്ത് ലോഡ് കുറയ്ക്കാൻ ഡാറ്റാബേസിന് ഫോഴ്‌സ് നയം തിരഞ്ഞെടുക്കാനും കഴിയും. അപ്പോൾ കമ്മിറ്റിന് മുമ്പ് സ്റ്റെപ്പ് നമ്പർ 5 എക്സിക്യൂട്ട് ചെയ്യുന്നു.

ഡാറ്റാബേസ് ഡിസ്കിലേക്ക് ഡാറ്റ വർദ്ധിപ്പിച്ച് എഴുതണോ (സ്റ്റീൽ പോളിസി) അല്ലെങ്കിൽ, ബഫർ മാനേജർ ഒരു പ്രതിബദ്ധതയ്ക്കായി കാത്തിരിക്കണമെങ്കിൽ, അതെല്ലാം ഒറ്റയടിക്ക് എഴുതുക (നോ-സ്റ്റീൽ). തിരഞ്ഞെടുക്കൽ നിങ്ങൾക്ക് ആവശ്യമുള്ളതിനെ ആശ്രയിച്ചിരിക്കുന്നു: നീണ്ട വീണ്ടെടുക്കൽ അല്ലെങ്കിൽ വേഗത്തിലുള്ള വീണ്ടെടുക്കൽ ഉപയോഗിച്ച് വേഗത്തിലുള്ള റെക്കോർഡിംഗ്?

സൂചിപ്പിച്ച നയങ്ങൾ വീണ്ടെടുക്കൽ പ്രക്രിയയെ എങ്ങനെ ബാധിക്കുന്നു:

• STEAL/NO-FORCE എന്നതിന് UNDO, REDO എന്നിവ ആവശ്യമാണ്. പ്രകടനം ഏറ്റവും ഉയർന്നതാണ്, എന്നാൽ ലോഗുകളുടെയും വീണ്ടെടുക്കൽ പ്രക്രിയകളുടെയും (ARES പോലുള്ളവ) ഘടന കൂടുതൽ സങ്കീർണ്ണമാണ്. മിക്ക ഡാറ്റാബേസുകളും ഈ നയങ്ങളുടെ സംയോജനമാണ് ഉപയോഗിക്കുന്നത്.
• STEAL/FORCE-ന് നിങ്ങൾ UNDO മാത്രം മതി.
• NO-STEAL/NO-FORCE-ന് - വീണ്ടും മാത്രം.
• നോ-സ്റ്റീൽ/ഫോഴ്‌സിനായി നിങ്ങൾക്ക് ഒന്നും ആവശ്യമില്ല. ഈ കേസിലെ പ്രകടനം ഏറ്റവും താഴ്ന്നതാണ്, കൂടാതെ ഒരു വലിയ മെമ്മറി ആവശ്യമാണ്.

വീണ്ടെടുക്കൽ

അപ്പോൾ നമ്മുടെ അത്ഭുതകരമായ ലോഗുകൾ എങ്ങനെ ഉപയോഗിക്കാം? ഒരു പുതിയ ജീവനക്കാരൻ ഡാറ്റാബേസ് നശിപ്പിച്ചുവെന്ന് നമുക്ക് അനുമാനിക്കാം (റൂൾ ​​#1: ഇത് എല്ലായ്പ്പോഴും പുതിയയാളുടെ തെറ്റാണ്!). നിങ്ങൾ അത് പുനരാരംഭിക്കുകയും വീണ്ടെടുക്കൽ പ്രക്രിയ ആരംഭിക്കുകയും ചെയ്യുന്നു.
ARIES മൂന്ന് ഘട്ടങ്ങളിലായി പുനഃസ്ഥാപിക്കുന്നു:

1. വിശകലനം. ഡാറ്റാബേസ് വീഴ്ചയുടെ സമയത്ത് സംഭവിച്ച സംഭവങ്ങളുടെ കാലഗണന പുനഃസ്ഥാപിക്കുന്നതിന് മുഴുവൻ ഇടപാട് ലോഗും വായിക്കുന്നു. ഏത് ഇടപാടാണ് പിൻവലിക്കേണ്ടതെന്ന് നിർണ്ണയിക്കാൻ ഇത് സഹായിക്കുന്നു. കമ്മിറ്റ് ഓർഡർ ഇല്ലാത്ത എല്ലാ ഇടപാടുകളും പിൻവലിക്കപ്പെടും. പരാജയസമയത്ത് ഡിസ്കിലേക്ക് എന്ത് ഡാറ്റ എഴുതണമെന്ന് സിസ്റ്റം തീരുമാനിക്കുന്നു.
2. ആവർത്തിച്ച്. ക്രാഷിനു മുമ്പുള്ള അവസ്ഥയിലേക്ക് ഡാറ്റാബേസ് അപ്ഡേറ്റ് ചെയ്യാൻ REDO ഉപയോഗിക്കുന്നു. അതിന്റെ രേഖകൾ കാലക്രമത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നു. ഓരോ ലോഗിനും, മാറ്റേണ്ട ഡാറ്റ അടങ്ങിയ ഡിസ്കിലെ പേജിന്റെ LSN റീഡ് ചെയ്യുന്നു.

   LSN(pages_on_disk)>=LSN(entries_in_log) ആണെങ്കിൽ, പരാജയത്തിന് മുമ്പ് ഡാറ്റ ഡിസ്കിലേക്ക് എഴുതിയിരുന്നു. എന്നാൽ ലോഗിൽ എഴുതിയതിന് ശേഷവും പരാജയത്തിന് മുമ്പും നടത്തിയ ഒരു ഓപ്പറേഷൻ വഴി മൂല്യം തിരുത്തിയെഴുതപ്പെട്ടു. അതിനാൽ ഒന്നും ചെയ്തിട്ടില്ല, ശരിക്കും.

   LSN (pages_on_disk) ആണെങ്കിൽ

   വീണ്ടെടുക്കൽ പ്രക്രിയ ലളിതമാക്കുന്നതിനാൽ പിൻവലിക്കപ്പെടുന്ന ഇടപാടുകൾക്ക് പോലും റീപ്ലേ നടത്തപ്പെടുന്നു. എന്നാൽ ആധുനിക ഡാറ്റാബേസുകൾ ഒരുപക്ഷേ ഇത് ചെയ്യില്ല.

3. റദ്ദാക്കുക.ഈ ഘട്ടത്തിൽ, പരാജയസമയത്ത് പൂർത്തിയാകാത്ത എല്ലാ ഇടപാടുകളും പിൻവലിക്കുന്നു. ഓരോ ഇടപാടിന്റെയും ഏറ്റവും പുതിയ ലോഗുകളിൽ നിന്നാണ് ഈ പ്രക്രിയ ആരംഭിക്കുന്നത് കൂടാതെ PrevLSN ഉപയോഗിച്ച് UNDO-കൾ വിപരീത കാലക്രമത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നു.

വീണ്ടെടുക്കൽ പ്രക്രിയയിൽ, വീണ്ടെടുക്കൽ സമയത്ത് നടത്തിയ പ്രവർത്തനങ്ങളെക്കുറിച്ച് ഇടപാട് ലോഗ് അറിഞ്ഞിരിക്കണം. ഡിസ്കിലേക്ക് സംരക്ഷിച്ച ഡാറ്റ ഇടപാട് ലോഗിൽ രേഖപ്പെടുത്തിയിരിക്കുന്നതുമായി സമന്വയിപ്പിക്കുന്നതിന് ഇത് ആവശ്യമാണ്. റോൾ ബാക്ക് ചെയ്ത ഇടപാട് രേഖകൾ ഇല്ലാതാക്കാൻ സാധിക്കും, എന്നാൽ ഇത് ചെയ്യാൻ വളരെ ബുദ്ധിമുട്ടാണ്. പകരം, റോൾഡ് ബാക്ക് ഇടപാടുകളുടെ എൻട്രികളെ യുക്തിപരമായി അസാധുവാക്കുന്ന ഇടപാട് ലോഗിൽ നഷ്ടപരിഹാരം നൽകുന്ന എൻട്രികൾ ARIES ചെയ്യുന്നു.

ഇടപാട് "മാനുവലായി" അല്ലെങ്കിൽ ഒരു ലോക്ക് മാനേജർ റദ്ദാക്കിയാൽ, അല്ലെങ്കിൽ ഒരു നെറ്റ്‌വർക്ക് പരാജയം കാരണം, വിശകലന ഘട്ടം ആവശ്യമില്ല. എല്ലാത്തിനുമുപരി, REDO, UNDO എന്നിവയ്ക്കുള്ള വിവരങ്ങൾ മെമ്മറിയിൽ സ്ഥിതിചെയ്യുന്ന രണ്ട് പട്ടികകളിൽ അടങ്ങിയിരിക്കുന്നു:

• ഇടപാട് പട്ടികയിൽ (നിലവിലെ എല്ലാ ഇടപാടുകളുടെയും അവസ്ഥകൾ ഇവിടെ സംഭരിച്ചിരിക്കുന്നു).
• വൃത്തികെട്ട പേജുകളുടെ പട്ടിക (ഡിസ്കിലേക്ക് എന്ത് ഡാറ്റയാണ് എഴുതേണ്ടത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നു).

ഒരു പുതിയ ഇടപാട് ദൃശ്യമാകുന്ന ഉടൻ, ഈ പട്ടികകൾ കാഷെ മാനേജറും ഇടപാട് മാനേജരും അപ്‌ഡേറ്റ് ചെയ്യുന്നു. കൂടാതെ ടേബിളുകൾ മെമ്മറിയിൽ സൂക്ഷിച്ചിരിക്കുന്നതിനാൽ, ഡാറ്റാബേസ് ക്രാഷായാൽ അവ അപ്രത്യക്ഷമാകും.

ഇടപാട് ലോഗിൽ നിന്നുള്ള വിവരങ്ങൾ ഉപയോഗിച്ച് രണ്ട് പട്ടികകളും പുനഃസ്ഥാപിക്കുന്നതിന് വിശകലന ഘട്ടം ആവശ്യമാണ്. ഈ ഘട്ടം വേഗത്തിലാക്കാൻ, ARIES ചെക്ക്‌പോസ്റ്റുകൾ ഉപയോഗിക്കുന്നു. രണ്ട് പട്ടികകളിലെയും ഉള്ളടക്കങ്ങളും എഴുതുന്ന സമയത്ത് ഏറ്റവും പുതിയ LSN-ഉം ഇടയ്ക്കിടെ ഡിസ്കിൽ എഴുതുന്നു. അതിനാൽ വീണ്ടെടുക്കൽ സമയത്ത്, ഈ LSN-നെ പിന്തുടരുന്ന ലോഗുകൾ മാത്രമേ വിശകലനം ചെയ്യുകയുള്ളൂ.

6. ഉപസംഹാരം

ഡാറ്റാബേസുകളെക്കുറിച്ചുള്ള ഒരു അധിക അവലോകനം എന്ന നിലയിൽ, ഒരു ഡാറ്റാബേസ് സിസ്റ്റത്തിന്റെ ആർക്കിടെക്ചർ എന്ന ലേഖനം ഞങ്ങൾക്ക് ശുപാർശ ചെയ്യാം. സാമാന്യം വ്യക്തമായ ഭാഷയിൽ എഴുതിയ വിഷയത്തെക്കുറിച്ചുള്ള നല്ലൊരു ആമുഖമാണിത്.

മുകളിലുള്ള എല്ലാ മെറ്റീരിയലുകളും നിങ്ങൾ ശ്രദ്ധാപൂർവ്വം വായിച്ചാൽ, ഡാറ്റാബേസുകളുടെ കഴിവുകൾ എത്ര മികച്ചതാണെന്ന് നിങ്ങൾക്ക് ഒരു ആശയം ലഭിച്ചേക്കാം. എന്നിരുന്നാലും, ഈ ലേഖനം മറ്റ് പ്രധാന പ്രശ്നങ്ങളെ അഭിസംബോധന ചെയ്യുന്നില്ല:

• ക്ലസ്റ്റേർഡ് ഡാറ്റാബേസുകളും ആഗോള ഇടപാടുകളും എങ്ങനെ കൈകാര്യം ചെയ്യാം.
• ഡാറ്റാബേസ് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ ഒരു സ്നാപ്പ്ഷോട്ട് എങ്ങനെ ലഭിക്കും.
• ഡാറ്റ എങ്ങനെ കാര്യക്ഷമമായി സംഭരിക്കുകയും കംപ്രസ് ചെയ്യുകയും ചെയ്യാം.
• മെമ്മറി എങ്ങനെ കൈകാര്യം ചെയ്യാം.

അതിനാൽ ഒരു ബഗ്ഗി NoSQL ഉം ഒരു സോളിഡ് റിലേഷണൽ ഡാറ്റാബേസും തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് രണ്ടുതവണ ചിന്തിക്കുക. എന്നെ തെറ്റിദ്ധരിക്കരുത്, ചില NoSQL ഡാറ്റാബേസുകൾ വളരെ മികച്ചതാണ്. എന്നാൽ അവ ഇപ്പോഴും പൂർണതയിൽ നിന്ന് വളരെ അകലെയാണ്, ചില ആപ്ലിക്കേഷനുകളുമായി ബന്ധപ്പെട്ട നിർദ്ദിഷ്ട പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ മാത്രമേ സഹായിക്കൂ.

അതിനാൽ, ഡാറ്റാബേസുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ആരെങ്കിലും നിങ്ങളോട് ചോദിച്ചാൽ, ഉപേക്ഷിച്ച് പോകുന്നതിന് പകരം നിങ്ങൾക്ക് ഉത്തരം നൽകാം:

ടാഗുകൾ: ടാഗുകൾ ചേർക്കുക