ERP ഡാറ്റാബേസുകളുടെ ഡീനോർമലൈസേഷനും സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ അതിന്റെ സ്വാധീനവും: ടോർട്ടുഗയിൽ ഒരു ഭക്ഷണശാല തുറക്കുന്നു

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

എല്ലാവരേയും എങ്ങനെ സന്തോഷിപ്പിക്കാം? അത്തരമൊരു സംവിധാനം രൂപകല്പന ചെയ്യുന്നതിനും പരിപാലിക്കുന്നതിനും ഭ്രാന്തനാകുന്നത് നിങ്ങൾക്ക് എങ്ങനെ ഒഴിവാക്കാനാകും? സാധാരണ കടൽക്കൊള്ളക്കാരും നാവികരും മാത്രമല്ല ഭക്ഷണശാലയിലേക്ക് വരാൻ തുടങ്ങിയാൽ എന്തുചെയ്യും?

എല്ലാം വെട്ടിനു കീഴിലാണ്. എന്നാൽ നമുക്ക് ക്രമത്തിൽ പോകാം.

1. പരിമിതികളും അനുമാനങ്ങളും

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

ഗണിത പദങ്ങളെ പരാമർശിക്കാതെ, സാധാരണ രൂപങ്ങളുടെ അവബോധജന്യവും പ്രായോഗികമായി ബാധകവുമായ നിർവചനങ്ങൾ പോസ്റ്റ് ഉപയോഗിക്കുന്നു. യഥാർത്ഥ ബിസിനസ്സ് പ്രക്രിയകളുടെ (ബിപി) പരിശോധനയ്ക്കും വ്യാവസായിക സോഫ്റ്റ്വെയറിന്റെ രൂപകൽപ്പനയ്ക്കും അവ പ്രയോഗിക്കാൻ കഴിയുന്ന രൂപത്തിൽ.

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

മിക്ക വായനക്കാർക്കും ദൈനംദിന തലത്തിൽ മനസ്സിലാക്കാവുന്ന ഒരു ഉദാഹരണം ഉപയോഗിച്ചാണ് സാധാരണ രൂപങ്ങളുടെ വിശദീകരണം നൽകിയിരിക്കുന്നത്. എന്നിരുന്നാലും, ഒരു വിഷ്വൽ ചിത്രീകരണമെന്ന നിലയിൽ, 4-5 ഖണ്ഡികകളിൽ, മനഃപൂർവ്വം "സാങ്കൽപ്പിക" ചുമതല ബോധപൂർവ്വം ഉപയോഗിച്ചു. നിങ്ങൾ ഇത് ചെയ്യാതെ, ചില പാഠപുസ്തക ഉദാഹരണങ്ങൾ എടുക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, പോയിന്റ് 2-ൽ നിന്നുള്ള അതേ ഓർഡർ സ്റ്റോറേജ് മോഡൽ, പ്രക്രിയയുടെ നിർദ്ദിഷ്ട വിഘടനത്തിൽ നിന്ന് ഒരു മോഡലിലേക്ക് വായനക്കാരന്റെ ശ്രദ്ധ മാറുന്ന ഒരു സാഹചര്യത്തിൽ നിങ്ങൾ സ്വയം കണ്ടെത്താം. IS-ൽ ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള പ്രോസസുകളും മോഡലുകളും എങ്ങനെ നിർമ്മിക്കണം എന്നതിനെക്കുറിച്ചുള്ള വ്യക്തിഗത അനുഭവത്തിലേക്കും ധാരണയിലേക്കും. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, രണ്ട് യോഗ്യതയുള്ള ഐടി അനലിസ്റ്റുകളെ എടുക്കുക, ഒരാൾ യാത്രക്കാരെ കൊണ്ടുപോകുന്ന ലോജിസ്റ്റിഷ്യൻമാർക്ക് സേവനങ്ങൾ നൽകട്ടെ, മറ്റൊന്ന് മൈക്രോചിപ്പുകൾ നിർമ്മിക്കുന്നതിനുള്ള യന്ത്രങ്ങൾ കൊണ്ടുപോകുന്ന ലോജിസ്റ്റിഷ്യൻമാർക്ക്. ഒരു റെയിൽവേ യാത്രയെക്കുറിച്ചുള്ള വിവരങ്ങൾ സംഭരിക്കുന്നതിന് ഒരു ഡാറ്റാ മോഡൽ സൃഷ്ടിക്കാൻ, ഓട്ടോമേറ്റഡ് ബിപിയെക്കുറിച്ച് മുൻകൂട്ടി ചർച്ച ചെയ്യാതെ അവരോട് ആവശ്യപ്പെടുക.

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

2. സാധാരണ രൂപങ്ങൾ

ഡാറ്റാബേസിന്റെ ആദ്യ സാധാരണ രൂപം എല്ലാ ആട്രിബ്യൂട്ടുകളുടെയും ആറ്റോമിസിറ്റി ആവശ്യമാണ്.
പ്രത്യേകിച്ചും, ഒബ്‌ജക്‌റ്റ് A, c=f(a,b) എന്നിങ്ങനെ നോൺ-കീ ആട്രിബ്യൂട്ടുകളുണ്ടെങ്കിൽ, A വിവരിക്കുന്ന ഒബ്‌ജക്‌റ്റിൽ നിങ്ങൾ c ആട്രിബ്യൂട്ട് മൂല്യം സംഭരിക്കുന്നുവെങ്കിൽ, ആദ്യത്തെ സാധാരണ രൂപം ഡാറ്റാബേസിൽ ലംഘിക്കപ്പെടുന്നു. . ഉദാഹരണത്തിന്, ഓർഡർ സ്‌പെസിഫിക്കേഷൻ ഒരു അളവ് സൂചിപ്പിക്കുന്നുവെങ്കിൽ, അതിന്റെ അളവിന്റെ യൂണിറ്റുകൾ ഉൽപ്പന്നത്തിന്റെ തരത്തെ ആശ്രയിച്ചിരിക്കുന്നു: ഒരു സാഹചര്യത്തിൽ അത് കഷണങ്ങളാകാം, മറ്റൊരു ലിറ്ററിൽ, കഷണങ്ങൾ അടങ്ങുന്ന മൂന്നാമത്തെ പാക്കേജുകളിൽ (Good_count_WR-ന് മുകളിലുള്ള മോഡലിൽ) , അപ്പോൾ ആട്രിബ്യൂട്ടുകളുടെ ആറ്റോമിസിറ്റി ഡാറ്റാബേസിൽ ലംഘിക്കപ്പെടുന്നു. ഈ സാഹചര്യത്തിൽ, ഓർഡർ സ്പെസിഫിക്കേഷന്റെ ടേബിൾ ക്ലസ്റ്റർ എന്തായിരിക്കണമെന്ന് പറയുന്നതിന്, IS-ലെ വർക്ക് പ്രോസസിന്റെ ഒരു ടാർഗെറ്റുചെയ്‌ത വിവരണം നിങ്ങൾക്ക് ആവശ്യമാണ്, കൂടാതെ പ്രക്രിയകൾ വ്യത്യസ്തമാകാമെന്നതിനാൽ, നിരവധി "ശരിയായ" പതിപ്പുകൾ ഉണ്ടാകാം.

ഡാറ്റാബേസിന്റെ രണ്ടാമത്തെ സാധാരണ രൂപം IS-ലെ വർക്ക് പ്രോസസുമായി ബന്ധപ്പെട്ട ഓരോ സ്ഥാപനത്തിനും ആദ്യ ഫോമും അതിന്റേതായ പട്ടികയും പാലിക്കേണ്ടതുണ്ട്. ഒരു ടേബിളിൽ c=f1(a), d=f2(b) എന്നീ ആശ്രിതത്വങ്ങളുണ്ടെങ്കിൽ c=f3(b) ആശ്രിതത്വം ഇല്ലെങ്കിൽ, പട്ടികയിൽ രണ്ടാമത്തെ സാധാരണ രൂപം ലംഘിക്കപ്പെടും. മുകളിലുള്ള ഉദാഹരണത്തിൽ, ഓർഡർ പട്ടികയിലെ ഓർഡറും വിലാസവും തമ്മിൽ യാതൊരു ആശ്രിതത്വവുമില്ല. തെരുവിന്റെയോ നഗരത്തിന്റെയോ പേര് മാറ്റുക, ഓർഡറിന്റെ അവശ്യ ആട്രിബ്യൂട്ടുകളിൽ നിങ്ങൾക്ക് യാതൊരു സ്വാധീനവും ഉണ്ടാകില്ല.

മൂന്നാമത്തെ സാധാരണ ഫോം ഡാറ്റാബേസ് രണ്ടാമത്തെ സാധാരണ രൂപവും വ്യത്യസ്ത എന്റിറ്റികളുടെ ആട്രിബ്യൂട്ടുകൾ തമ്മിലുള്ള പ്രവർത്തനപരമായ ആശ്രിതത്വങ്ങളുടെ അഭാവവും പാലിക്കേണ്ടതുണ്ട്. ഈ നിയമം ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്താം: "കണക്കെടുക്കാൻ കഴിയുന്നതെല്ലാം കണക്കാക്കണം." മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, A, B എന്നീ രണ്ട് ഒബ്‌ജക്‌റ്റുകൾ ഉണ്ടെങ്കിൽ, ഒബ്‌ജക്‌റ്റ് A യുടെ ആട്രിബ്യൂട്ടുകൾ സംഭരിക്കുന്ന പട്ടികയിൽ, C ആട്രിബ്യൂട്ട് പ്രകടമാവുകയും, ഒബ്‌ജക്റ്റ് B ആട്രിബ്യൂട്ട് b ഉണ്ടാവുകയും ചെയ്യുന്നു, അതായത് c=f4(b) നിലവിലുണ്ടെങ്കിൽ, മൂന്നാമത്തെ സാധാരണ രൂപം ലംഘിക്കപ്പെടുന്നു. ചുവടെയുള്ള ഉദാഹരണത്തിൽ, ഓർഡർ റെക്കോർഡിലെ കഷണങ്ങളുടെ അളവ് (Total_count_WR) മൂന്നാം സാധാരണ ഫോം ലംഘിക്കുന്നതായി വ്യക്തമായി അവകാശപ്പെടുന്നു

3. നോർമലൈസേഷൻ പ്രയോഗിക്കുന്നതിനുള്ള എന്റെ സമീപനം

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

2. താഴെപ്പറയുന്ന ചില അല്ലെങ്കിൽ എല്ലാ വ്യവസ്ഥകളും പാലിക്കുകയാണെങ്കിൽ, ERP സംവിധാനങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള യഥാർത്ഥ പ്രയോഗത്തിൽ കർശനമായ അർത്ഥത്തിൽ മൂന്നാമത്തെ സാധാരണ രൂപം കൈവരിക്കുന്നത് പ്രായോഗികമായിരിക്കില്ല:

• യാന്ത്രിക പ്രക്രിയകൾ അപൂർവ്വമായി മാറ്റത്തിന് വിധേയമാണ്,
• ഗവേഷണത്തിനും വികസനത്തിനുമുള്ള സമയപരിധി കർശനമാണ്,
• ഡാറ്റാ സമഗ്രതയ്ക്കുള്ള ആവശ്യകതകൾ താരതമ്യേന കുറവാണ് (വ്യാവസായിക സോഫ്‌റ്റ്‌വെയറിലെ സാധ്യതയുള്ള പിശകുകൾ സോഫ്റ്റ്‌വെയർ ഉപഭോക്താവിന് പണമോ ക്ലയന്റുകളോ നഷ്ടപ്പെടുന്നതിലേക്ക് നയിക്കില്ല)
• അതുപോലെ തന്നെ.

വിവരിച്ച വ്യവസ്ഥകളിൽ, ചില വസ്തുക്കളുടെയും അവയുടെ ആട്രിബ്യൂട്ടുകളുടെയും ജീവിത ചക്രം തിരിച്ചറിയുന്നതിനും വിവരിക്കുന്നതിനുമുള്ള ചെലവുകൾ സാമ്പത്തിക കാര്യക്ഷമതയുടെ വീക്ഷണകോണിൽ നിന്ന് ന്യായീകരിക്കപ്പെടണമെന്നില്ല.

3. ഇതിനകം സൃഷ്‌ടിച്ച IS-ൽ ഡാറ്റാ മോഡലിന്റെ ഡീനോർമലൈസേഷന്റെ ഏതെങ്കിലും അനന്തരഫലങ്ങൾ കോഡിന്റെയും പരിശോധനയുടെയും സമഗ്രമായ പ്രാഥമിക പഠനത്തിലൂടെ ലഘൂകരിക്കാനാകും.

4. ഡീനോർമലൈസേഷൻ എന്നത് തൊഴിൽ ചെലവുകൾ ഡാറ്റാ സ്രോതസ്സുകൾ ഗവേഷണം ചെയ്യുന്ന ഘട്ടത്തിൽ നിന്നും ഒരു ബിസിനസ് പ്രോസസ് രൂപകൽപന ചെയ്യുന്ന ഘട്ടത്തിൽ നിന്നും വികസന ഘട്ടത്തിലേക്ക്, നടപ്പാക്കൽ കാലയളവ് മുതൽ സിസ്റ്റം വികസന കാലഘട്ടം വരെ കൈമാറുന്നതിനുള്ള ഒരു മാർഗമാണ്.

5. ഇനിപ്പറയുന്നവയാണെങ്കിൽ ഒരു ഡാറ്റാബേസിന്റെ മൂന്നാമത്തെ സാധാരണ രൂപത്തിനായി പരിശ്രമിക്കുന്നത് ഉചിതമാണ്:

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

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

4 ചിത്രീകരണത്തിനുള്ള പ്രശ്നം

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

ഭക്ഷണശാല ഇൻഫർമേഷൻ സിസ്റ്റം കോംപ്ലക്സിൽ ഇനിപ്പറയുന്ന സോഫ്റ്റ്വെയർ അടങ്ങിയിരിക്കുന്നു:

• സ്വഭാവ സവിശേഷതകളെ അടിസ്ഥാനമാക്കി അതിന്റെ വിഭാഗത്തെ തിരിച്ചറിയുന്ന ഒരു ക്ലയന്റിനെക്കുറിച്ചുള്ള ഒരു മുൻകൂർ മുന്നറിയിപ്പ് സംവിധാനം
• റോബോട്ട് ഹോസ്റ്റസുകൾക്കും റോബോട്ട് ബാർട്ടൻഡർമാർക്കുമുള്ള നിയന്ത്രണ സംവിധാനം
• വെയർഹൗസും ഡെലിവറി മാനേജ്‌മെന്റ് സംവിധാനവും വിൽപ്പന പോയിന്റിലേക്ക്
• സപ്ലയർ റിലേഷൻഷിപ്പ് മാനേജ്മെന്റ് സിസ്റ്റം (SURP)

പ്രക്രിയ:

മുൻകൂർ മുന്നറിയിപ്പ് സംവിധാനം കപ്പൽ വിടുന്ന ആളുകളെ തിരിച്ചറിയുന്നു. ഒരു വ്യക്തി വൃത്തിയായി ഷേവ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, അവൾ അവനെ ഒരു നാവികനായി തിരിച്ചറിയുന്നു; ഒരാൾ താടിയുള്ളതായി കണ്ടെത്തിയാൽ, അയാൾ ഒരു കടൽക്കൊള്ളക്കാരനാണെന്ന് തിരിച്ചറിയുന്നു.

ഭക്ഷണശാലയിൽ പ്രവേശിക്കുമ്പോൾ, അതിഥി തന്റെ വിഭാഗത്തിന് അനുസൃതമായി റോബോട്ട് ഹോസ്റ്റസിൽ നിന്ന് ഒരു ആശംസ കേൾക്കുന്നു, ഉദാഹരണത്തിന്: "ഹോ-ഹോ-ഹോ, പ്രിയ കടൽക്കൊള്ളക്കാരേ, ടേബിളിലേക്ക് പോകൂ ..."

അതിഥി നിർദ്ദിഷ്ട പട്ടികയിലേക്ക് പോകുന്നു, അവിടെ റോബോട്ട് ബാർട്ടൻഡർ ഇതിനകം തന്നെ വിഭാഗത്തിന് അനുസൃതമായി അവനുവേണ്ടി സാധനങ്ങൾ തയ്യാറാക്കിയിട്ടുണ്ട്. ഡെലിവറിയുടെ അടുത്ത ഭാഗം വർദ്ധിപ്പിക്കണമെന്ന് റോബോട്ട് ബാർട്ടൻഡർ വെയർഹൗസ് സിസ്റ്റത്തിലേക്ക് വിവരങ്ങൾ കൈമാറുന്നു; സംഭരണത്തിലെ ശേഷിക്കുന്ന ബാലൻസുകളെ അടിസ്ഥാനമാക്കി വെയർഹൗസ് IS, മാനേജ്മെന്റ് സിസ്റ്റത്തിൽ ഒരു വാങ്ങൽ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു.

മുൻകൂർ മുന്നറിയിപ്പ് സംവിധാനം നിങ്ങളുടെ ആന്തരിക ഐടി വികസിപ്പിച്ചിരിക്കാമെങ്കിലും, ബാർ റോബോട്ട് മാനേജ്മെന്റ് പ്രോഗ്രാം നിങ്ങളുടെ ബിസിനസ്സിനായി പ്രത്യേകമായി ഒരു ബാഹ്യ കോൺട്രാക്ടർ സൃഷ്ടിച്ചതാകാം. വെയർഹൗസുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള സംവിധാനങ്ങളും വിതരണക്കാരുമായുള്ള ബന്ധങ്ങളും വിപണിയിൽ നിന്ന് ഇഷ്ടാനുസൃതമാക്കിയ പാക്കേജുചെയ്ത പരിഹാരങ്ങളാണ്.

5. ഡീനോർമലൈസേഷന്റെ ഉദാഹരണങ്ങളും സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ അതിന്റെ സ്വാധീനവും

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

ക്ലയന്റ് തരങ്ങളുടെ ഒരു ഡയറക്ടറി രണ്ട് മൂല്യങ്ങളോടെ ദൃശ്യമാകുന്നു: 1 - കടൽക്കൊള്ളക്കാർ, 2 - നാവികർ, കമ്പനിയുടെ മുഴുവൻ വിവര സർക്യൂട്ടിനും പൊതുവായി.

ക്ലയന്റ് നോട്ടിഫിക്കേഷൻ സിസ്റ്റം, അംഗീകൃത ക്ലയന്റിന്റെ ഐഡന്റിഫയർ (ഐഡി) ആയി ഇമേജ് പ്രോസസ്സിംഗിന്റെ ഫലം ഉടനടി സംഭരിക്കുന്നു: നാവികൻ അല്ലെങ്കിൽ കടൽക്കൊള്ളക്കാരൻ.

അംഗീകൃത ഒബ്ജക്റ്റ് ഐഡി
ക്ലയന്റ് വിഭാഗം

100500
കടൽക്കൊള്ളക്കാർ

100501
കടൽക്കൊള്ളക്കാർ

100502
നാവികൻ

അത് ഒരിക്കൽ കൂടി ശ്രദ്ധിക്കാം

1. നമ്മുടെ നാവികർ യഥാർത്ഥത്തിൽ ഷേവ് ചെയ്തവരാണ്
2. നമ്മുടെ കടൽക്കൊള്ളക്കാർ യഥാർത്ഥത്തിൽ താടിയുള്ളവരാണ്

ഈ കേസിൽ എന്ത് പ്രശ്നങ്ങൾ ഇല്ലാതാക്കേണ്ടതുണ്ട്, അങ്ങനെ ഞങ്ങളുടെ ഘടന മൂന്നാമത്തെ സാധാരണ രൂപത്തിനായി പരിശ്രമിക്കുന്നു:

• ആട്രിബ്യൂട്ട് ആറ്റോമിസിറ്റി ലംഘനം - ക്ലയന്റ് വിഭാഗം
• വിശകലനം ചെയ്ത വസ്തുതയും നിഗമനവും ഒരു പട്ടികയിൽ കലർത്തുന്നു
• വ്യത്യസ്ത എന്റിറ്റികളുടെ ആട്രിബ്യൂട്ടുകൾ തമ്മിലുള്ള സ്ഥിരമായ പ്രവർത്തന ബന്ധം.

സാധാരണ രൂപത്തിൽ, നമുക്ക് രണ്ട് പട്ടികകൾ ലഭിക്കും:

• സ്ഥാപിത സവിശേഷതകളുടെ ഒരു കൂട്ടം രൂപത്തിലാണ് തിരിച്ചറിയൽ ഫലം,

അംഗീകൃത ഒബ്ജക്റ്റ് ഐഡി
മുഖരോമങ്ങൾ

100500
ആ

100501
ആ

100502
ഇല്ല

• സ്ഥാപിത സ്വഭാവസവിശേഷതകൾ വ്യാഖ്യാനിക്കുന്നതിനായി IS-ൽ ഉൾച്ചേർത്ത യുക്തിയുടെ ഒരു പ്രയോഗമായി ക്ലയന്റ് തരം നിർണ്ണയിക്കുന്നതിന്റെ ഫലം

അംഗീകൃത ഒബ്ജക്റ്റ് ഐഡി
തിരിച്ചറിയൽ ഐഡി
ക്ലയന്റ് വിഭാഗം

100500
100001
കടൽക്കൊള്ളക്കാർ

100501
100002
കടൽക്കൊള്ളക്കാർ

100502
100003
നാവികൻ

ഒരു നോർമലൈസ്ഡ് ഡാറ്റ സ്റ്റോറേജ് ഓർഗനൈസേഷന് ഒരു ഐപി കോംപ്ലക്‌സിന്റെ വികസനം എങ്ങനെ സുഗമമാക്കാനാകും? നിങ്ങൾക്ക് പെട്ടെന്ന് പുതിയ ക്ലയന്റുകളെ ലഭിച്ചുവെന്ന് പറയാം. താടിയില്ലാത്ത ജാപ്പനീസ് കടൽക്കൊള്ളക്കാർ ആയിരിക്കട്ടെ, പക്ഷേ അവർ തോളിൽ ഒരു തത്തയുമായി നടക്കുന്നു, കൂടാതെ പരിസ്ഥിതിവാദി കടൽക്കൊള്ളക്കാരും, ഇടത് നെഞ്ചിലെ ഗ്രെറ്റയുടെ നീല പ്രൊഫൈലിൽ നിങ്ങൾക്ക് അവരെ എളുപ്പത്തിൽ തിരിച്ചറിയാൻ കഴിയും.

പരിസ്ഥിതി കടൽക്കൊള്ളക്കാർക്ക്, സ്വാഭാവികമായും, അസ്ഥി ചീപ്പുകൾ ഉപയോഗിക്കാനും റീസൈക്കിൾ ചെയ്ത കടൽ പ്ലാസ്റ്റിക്കിൽ നിന്ന് നിർമ്മിച്ച അനലോഗ് ആവശ്യപ്പെടാനും കഴിയില്ല.

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

ഒരു രൂപത്തിൽ അത് അന്വേഷിക്കുന്നു സാധാരണ നിലയിലാക്കാൻ, പ്രവർത്തന ഡാറ്റയും രണ്ട് ഡയറക്ടറികളും ഉള്ള രണ്ട് ടേബിളുകൾ ഞങ്ങൾക്ക് ലഭിക്കും:

• സ്ഥാപിത സവിശേഷതകളുടെ ഒരു കൂട്ടം രൂപത്തിലാണ് തിരിച്ചറിയൽ ഫലം,

അംഗീകൃത ഒബ്ജക്റ്റ് ഐഡി
ഇടതു നെഞ്ചിൽ ഗ്രെറ്റ
തോളിൽ പക്ഷി
മുഖരോമങ്ങൾ

100510
1
1
1

100511
0
0
1

100512

1
0

• ക്ലയന്റ് തരം നിർണ്ണയിക്കുന്നതിന്റെ ഫലം (ഡയറക്‌ടറികളിൽ നിന്നുള്ള വിവരണങ്ങൾ പ്രദർശിപ്പിക്കുന്ന ഒരു ഇഷ്‌ടാനുസൃത കാഴ്ചയായിരിക്കട്ടെ)

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

മുകളിലുള്ള ഉദാഹരണത്തിൽ, മൂന്ന് സാധാരണ രൂപങ്ങളും ലംഘിക്കപ്പെടുന്നു, അവ വെവ്വേറെ ലംഘിക്കാൻ ശ്രമിക്കാം.

ആദ്യ സാധാരണ രൂപത്തിന്റെ ലംഘനം:

നിങ്ങളുടെ ഭക്ഷണശാലയുടേതായ ഒരു 1.5-ടൺ ഗസൽ ഉപയോഗിച്ച് പിക്ക്-അപ്പ് വഴി വിതരണക്കാരുടെ വെയർഹൗസുകളിൽ നിന്ന് സാധനങ്ങൾ നിങ്ങളുടെ വെയർഹൗസിലേക്ക് ഡെലിവർ ചെയ്യുന്നുവെന്ന് പറയാം. വിതരണക്കാരുടെ വിറ്റുവരവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ നിങ്ങളുടെ ഓർഡറുകളുടെ വലുപ്പം വളരെ ചെറുതാണ്, ഉൽപ്പാദനത്തിനായി കാത്തുനിൽക്കാതെ അവ എല്ലായ്പ്പോഴും ഒറ്റയടിക്ക് പൂർത്തിയാക്കും. അത്തരമൊരു ബിസിനസ്സ് പ്രക്രിയയുള്ള പ്രത്യേക പട്ടികകൾ നിങ്ങൾക്ക് ആവശ്യമുണ്ടോ: വാഹനങ്ങൾ, വാഹനങ്ങളുടെ തരങ്ങൾ, പോയ വിതരണക്കാർക്കുള്ള നിങ്ങളുടെ ഓർഡറുകളിൽ പ്ലാനും വസ്തുതയും വേർതിരിക്കേണ്ടത് ആവശ്യമാണോ?

ഒരു പ്രോഗ്രാം വികസിപ്പിക്കുന്നതിന് ചുവടെയുള്ള മോഡൽ നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ പ്രോഗ്രാമർമാർക്ക് എത്ര "അധിക" കണക്ഷനുകൾ എഴുതേണ്ടിവരുമെന്ന് സങ്കൽപ്പിക്കുക.

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

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

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

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

സെക്ഷൻ 2, സെക്ഷൻ 5 എന്നിവയിലെ ഓർഡർ സ്‌പെസിഫിക്കേഷനിൽ (T_ORDER_SPEC) ഓർഡർ ചെയ്‌ത അളവ് ആദ്യ സാധാരണ ഫോമിന്റെ ആവശ്യകത നിറവേറ്റുകയോ അല്ലാതിരിക്കുകയോ ചെയ്‌തേക്കാമെന്ന് ശ്രദ്ധയുള്ള ഒരു വായനക്കാരൻ ശ്രദ്ധിച്ചിരിക്കാം. ചരക്കുകളുടെ തിരഞ്ഞെടുത്ത ശേഖരം കണക്കിലെടുക്കുമ്പോൾ, അടിസ്ഥാനപരമായി വ്യത്യസ്ത അളവെടുപ്പ് യൂണിറ്റുകൾ ഒരേ ഫീൽഡിൽ വീഴുമോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

രണ്ടാമത്തെ സാധാരണ രൂപത്തിന്റെ ലംഘനം:

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

മൂന്നാമത്തെ സാധാരണ രൂപത്തിന്റെ ലംഘനം:

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

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

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

പ്രസിദ്ധീകരണത്തിന്റെ തയ്യാറെടുപ്പിനിടെ വിലപ്പെട്ട ഫീഡ്‌ബാക്ക് നൽകിയതിന് പ്രമുഖ ഡെവലപ്പർ എവ്ജെനി യരുഖിന് എന്റെ നന്ദി അറിയിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

സാഹിത്യം

https://habr.com/en/post/254773/
കനോലി തോമസ്, ബെഗ് കരോലിൻ. ഡാറ്റാബേസ്. രൂപകൽപ്പന, നടപ്പിലാക്കൽ, പിന്തുണ. സിദ്ധാന്തവും പ്രയോഗവും

അവലംബം: www.habr.com