നേട്ടങ്ങൾ:
- ആശയപരവും യുക്തിപരവും ഭൗതികവുമായ ഡാറ്റാ മോഡലുകളും നോർമലൈസേഷൻ ആശയങ്ങളും വിശദീകരിക്കാനും ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിൻ്റെ പിന്തുണയോടെ എൻ്റിറ്റി-റിലേഷൻഷിപ്പ് ഡ്രാഫ്റ്റുകൾ നിർമ്മിക്കാനുമുള്ള കഴിവ്
- ഘടനാപരമായ നിർദ്ദേശങ്ങൾ ഉപയോഗിച്ച് ഡാറ്റാ നിഘണ്ടു, ബിസിനസ്സ് റൂൾ, ടേബിൾ ബന്ധങ്ങൾ എന്നിവ ഡ്രാഫ്റ്റ് ചെയ്യാനും അവ യഥാർത്ഥ സിസ്റ്റത്തിനെതിരെ സ്ഥിരീകരിക്കാനുമുള്ള കഴിവ്
- സമഗ്രത, ഏകത്വം, ബിസിനസ് റൂൾ പാലിക്കൽ എന്നിവയിൽ AI- ജനറേറ്റഡ് സ്കീമ നിർദ്ദേശങ്ങൾ വിമർശനാത്മകമായി വിലയിരുത്താനുള്ള കഴിവ്.
ഒരു വിവര സംവിധാനം അടിസ്ഥാനപരമായി ഡാറ്റയെ ക്രമപ്പെടുത്തുന്ന ഒരു ഘടനയാണ്. ഒരു ബിസിനസ്സിൻ്റെ വസ്തുതകളും (ഉപഭോക്താവ്, ഓർഡർ, ഉൽപ്പന്നം, ഇൻവോയ്സ്) അവയുടെ പരസ്പര ബന്ധവും ഘടനാപരമായ രീതിയിൽ രൂപകൽപ്പന ചെയ്യുന്ന ചുമതലയാണ് ഡാറ്റാ മോഡലിംഗ്. കൃത്യമായ റിപ്പോർട്ടിംഗ്, വേഗത്തിലുള്ള അന്വേഷണങ്ങൾ, സ്ഥിരതയുള്ള ഡാറ്റ എന്നിവയുടെ അടിത്തറയാണ് നല്ല ഡാറ്റ മോഡൽ; ഒരു മോശം മാതൃകയാണ് വർഷങ്ങളോളം പൊരുത്തക്കേടുകളുടെയും ആവർത്തിച്ചുള്ള തിരുത്തൽ പ്രവർത്തനങ്ങളുടെയും ഉറവിടം. മിക്കപ്പോഴും, MIS പ്രൊഫഷണലുകൾ ആദ്യം മുതൽ മോഡൽ കോഡ് ചെയ്യുന്നില്ല, എന്നാൽ മോഡൽ ബിസിനസ്സ് നിയമങ്ങൾ പാലിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുകയും ബിസിനസ് യൂണിറ്റിനും ഐടിക്കും ഇടയിൽ മോഡൽ വിവർത്തനം ചെയ്യുകയും ചെയ്യുന്നു.
അമൂർത്തീകരണത്തിൻ്റെ മൂന്ന് തലങ്ങളിലാണ് ഡാറ്റ മോഡലിംഗ് മുന്നോട്ട് പോകുന്നത്. ആശയപരമായ മാതൃക (ഇംഗ്ലീഷ് ആശയം) ഏറ്റവും ഉയർന്ന തലമാണ്: ഏത് പ്രധാന എൻ്റിറ്റികൾ നിലവിലുണ്ട്, അവ എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു? "ഉപഭോക്താവ് ഒരു ഓർഡർ നൽകുന്നു, ഓർഡറിൽ ഉൽപ്പന്നം ഉൾപ്പെടുന്നു." സാങ്കേതിക വിശദാംശങ്ങളൊന്നുമില്ല. ലോജിക്കൽ മോഡൽ ഓരോ എൻ്റിറ്റിയുടെയും ആട്രിബ്യൂട്ടുകൾ (ഫീൽഡുകൾ), കീകൾ, ബന്ധ തരങ്ങൾ എന്നിവ നിർവചിക്കുന്നു; എന്നാൽ ഇത് ഇപ്പോഴും ഒരു നിർദ്ദിഷ്ട ഡാറ്റാബേസ് ഉൽപ്പന്നവുമായി ബന്ധിപ്പിച്ചിട്ടില്ല. ഫിസിക്കൽ മോഡൽ (ഇംഗ്ലീഷ് ഫിസിക്കൽ) എന്നത് ഒരു നിർദ്ദിഷ്ട ഡാറ്റാബേസിലെ (ഉദാ. SQL സെർവർ, PostgreSQL) പട്ടികകൾ, ഡാറ്റ തരങ്ങൾ, സൂചികകൾ എന്നിവയുടെ മൂർത്തമായ പതിപ്പാണ്. ഈ മൂന്ന് തലങ്ങളും ഒരേ ആശയത്തിൻ്റെ കൂടുതൽ വിശദമായ പതിപ്പുകളാണ്.
എൻ്റിറ്റി-ബന്ധവും കീകളും
ഡാറ്റാ മോഡലിൻ്റെ അടിസ്ഥാന ഭാഷ എൻ്റിറ്റി-റിലേഷൻഷിപ്പ് (ER) മോഡലാണ്. എൻ്റിറ്റിയെ ഒരു പട്ടികയായി കണക്കാക്കാം: ഉപഭോക്താവ്, ഓർഡർ. ആട്രിബ്യൂട്ട് പട്ടികയുടെ നിരയാണ്: പേര്, ഇമെയിൽ, തുക. എൻ്റിറ്റികളെ എങ്ങനെ ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്നതാണ് ബന്ധം: ഒരു ഉപഭോക്താവിന് നിരവധി ഓർഡറുകൾ ഉണ്ടാകാം (ഒന്ന് മുതൽ നിരവധി ബന്ധം).
രണ്ട് നിർണായക പ്രധാന ആശയങ്ങളുണ്ട്. ഒരു പട്ടികയിലെ ഓരോ വരിയും അദ്വിതീയമായി തിരിച്ചറിയുന്ന ഫീൽഡാണ് പ്രാഥമിക കീ; ഉദാഹരണത്തിന് CustomerID. ഒരു ടേബിളിലെ മറ്റൊരു ടേബിളിൻ്റെ പ്രാഥമിക കീയിലേക്ക് വിരൽ ചൂണ്ടുന്ന ഒരു ഫീൽഡാണ് ഫോറിൻ കീ; The CustomerID in the order table connects which customer's order it is. ഈ കണക്ഷനുകൾ റഫറൻഷ്യൽ സമഗ്രത ഉറപ്പാക്കുന്നു: നിലവിലില്ലാത്ത ഒരു ഉപഭോക്താവിനായി ഒരു ഓർഡർ നൽകാനാവില്ല.
നുറുങ്ങ്: AI ഒരു ER ഡ്രാഫ്റ്റ് സൃഷ്ടിക്കുമ്പോൾ, ഓരോ ടേബിളിനും പ്രാഥമിക കീയും ഓരോ ബന്ധത്തിനും വിദേശ കീയും വ്യക്തമായി അഭ്യർത്ഥിക്കുന്നത് എളുപ്പമാക്കുന്നു. എന്നാൽ യഥാർത്ഥ ബിസിനസ്സ് നിയമത്തിന് എതിരായി മോഡൽ നിർദ്ദേശിച്ച ഓരോ വിദേശ കീയും പരിശോധിച്ചുറപ്പിക്കുക: ചിലപ്പോൾ "ഒന്ന് മുതൽ പലത് വരെ" എന്ന് നിങ്ങൾ കരുതുന്ന ബന്ധം യഥാർത്ഥത്തിൽ "പലതും പലതും" ആയിരിക്കും.
നോർമലൈസേഷൻ: ആവർത്തനത്തെ തടയുന്നു
Normalization is the process of reducing redundancy and preserving integrity by dividing data into logical tables. ഒരേ വിവരങ്ങൾ ഒരിടത്ത് സൂക്ഷിക്കുക എന്നതാണ് ലക്ഷ്യം. ഉദാഹരണത്തിന്, ഓരോ ഓർഡർ ലൈനിലും ഉപഭോക്തൃ വിലാസം വീണ്ടും വീണ്ടും ടൈപ്പുചെയ്യുന്നതിനുപകരം, നിങ്ങൾ വിലാസം ഉപഭോക്തൃ പട്ടികയിൽ ഒരിക്കൽ സൂക്ഷിക്കുകയും ഓർഡറിൽ നിന്നുള്ള ഒരു വിദേശ കീയുമായി ലിങ്ക് ചെയ്യുകയും ചെയ്യുന്നു. ഈ രീതിയിൽ, വിലാസം മാറുമ്പോൾ, നിങ്ങൾ അത് ഒരിടത്ത് അപ്ഡേറ്റ് ചെയ്യുക; അല്ലെങ്കിൽ, നൂറുകണക്കിന് ഓർഡറുകൾക്ക് വ്യത്യസ്ത വിലാസങ്ങളുണ്ടാകും. ഇതിനെ അപ്ഡേറ്റ് അനോമലി എന്ന് വിളിക്കുന്നു.
നോർമലൈസേഷൻ്റെ വിപരീതമാണ് ഡീനോർമലൈസേഷൻ: റിപ്പോർട്ടിംഗ് വേഗതയ്ക്കായി മനഃപൂർവ്വം ചില ആവർത്തനങ്ങൾ അനുവദിക്കുക. ബിസിനസ്സ് സിസ്റ്റങ്ങളിൽ (ഓപ്പറേഷണൽ ഡാറ്റാബേസ്), നോർമലൈസേഷനാണ് സാധാരണയായി മുൻഗണന നൽകുന്നത്, റിപ്പോർട്ടിംഗ് സിസ്റ്റങ്ങളിൽ (ഡാറ്റ വെയർഹൗസ്), ഡീനോർമലൈസേഷനാണ് പലപ്പോഴും മുൻഗണന നൽകുന്നത്. അതിനാൽ "സാധാരണവൽക്കരണം എല്ലായ്പ്പോഴും നല്ലതല്ല"; ഉദ്ദേശ്യമനുസരിച്ചാണ് തീരുമാനം.
ഡാറ്റ നിഘണ്ടു: പൊതു ഭാഷ
ഓരോ ഫീൽഡും എന്താണ് അർത്ഥമാക്കുന്നത്, അതിൻ്റെ തരം, നിയന്ത്രണങ്ങൾ, ബിസിനസ് റൂൾ എന്നിവ നിർവചിക്കുന്ന ഒരു രേഖയാണ് ഡാറ്റാ നിഘണ്ടു. "സ്റ്റാറ്റസ്" ഫീൽഡ് എന്താണ് അർത്ഥമാക്കുന്നത്? ഇതിന് എന്ത് മൂല്യങ്ങൾ എടുക്കാം (തീർച്ചപ്പെടുത്താത്തത്, അംഗീകരിച്ചത്, റദ്ദാക്കിയത്)? അത് നിർബന്ധമാണോ? ഈ രേഖയില്ലാതെ, ഒരേ ഫീൽഡ് വ്യത്യസ്ത ടീമുകൾ വ്യത്യസ്തമായി വ്യാഖ്യാനിക്കുകയും റിപ്പോർട്ട് വളച്ചൊടിക്കുകയും ചെയ്യും. ഡാറ്റാ നിഘണ്ടു ഓർഗനൈസേഷൻ്റെ ഭാഷാ പദമാണ്, കൂടാതെ MIS പ്രൊഫഷണലിൻ്റെ ഏറ്റവും മൂല്യവത്തായ ഡെലിവറബിളുകളിൽ ഒന്നാണ്. നിലവിലുള്ള പട്ടിക ഘടനയിൽ നിന്ന് പ്രാരംഭ ഡാറ്റ നിഘണ്ടു ഡ്രാഫ്റ്റ് വേഗത്തിൽ എക്സ്ട്രാക്റ്റുചെയ്യാൻ AI-ന് കഴിയും; എന്നാൽ ആ ഡാറ്റ ഉപയോഗിക്കുന്ന യൂണിറ്റ് മാത്രമേ ഓരോ ഫീൽഡിൻ്റെയും യഥാർത്ഥ ബിസിനസ്സ് അർത്ഥം പരിശോധിക്കൂ.
മൂന്ന് മിനി കേസുകൾ: അക്കങ്ങൾ പ്രകാരം
കേസ് 1 - ആവർത്തനത്തിൻ്റെ വില. ഒരു വിതരണ കമ്പനിയിൽ, ഉപഭോക്തൃ വിലാസം ഓർഡറിലും ഇൻവോയ്സ് ടേബിളിലും വെവ്വേറെ സൂക്ഷിച്ചിരിക്കുന്നു. ഒരു ഉപഭോക്താവ് മാറിയപ്പോൾ, വിലാസം ഒരു പട്ടികയിൽ മാത്രം അപ്ഡേറ്റ് ചെയ്തു; 1,400 ഇൻവോയ്സുകൾ പഴയ വിലാസത്തിൽ പോയി തിരികെ നൽകി. വിലാസം ഒരു പട്ടികയിൽ നോർമലൈസ് ചെയ്താൽ, ഒരൊറ്റ അപ്ഡേറ്റ് മതിയാകും. പരിഹാര പദ്ധതിക്ക് 2 ആഴ്ചയാണ് ചെലവ്.
കേസ് 2 - തെറ്റായ തരത്തിലുള്ള ബന്ധം. ഒരു വിദ്യാഭ്യാസ സ്ഥാപനത്തിലെ ഒരു MIS വിദഗ്ദ്ധൻ, AI ജനറേറ്റഡ് മോഡലിൽ "വിദ്യാർത്ഥി ഒരു ക്ലാസ്സിൽ പെട്ടതാണ്" എന്ന (ഒന്ന് മുതൽ നിരവധി വരെ) ബന്ധം അംഗീകരിച്ചു. എന്നിരുന്നാലും, വിദ്യാർത്ഥികൾക്ക് ഒന്നിലധികം ഐച്ഛിക ക്ലാസുകളിൽ ചേരാൻ കഴിയും; ബന്ധം യഥാർത്ഥത്തിൽ പലതും പലതും ആയിരുന്നു, ഒരു ഇൻ്റർമീഡിയറ്റ് ടേബിൾ (റെക്കോർഡ്) ആവശ്യമാണ്. ഒരു വിദ്യാർത്ഥി രണ്ടാം ക്ലാസിൽ ചേരാത്തതാണ് വയലിൽ തെറ്റ് വെളിപ്പെട്ടത്. AI യുടെ നിർദ്ദേശം സ്ഥിരീകരിച്ചിരുന്നെങ്കിൽ, അത് തുടക്കത്തിൽ തന്നെ പിടിക്കപ്പെടുമായിരുന്നു.
കേസ് 3 - ഡാറ്റ നിഘണ്ടുവിൻറെ മൂല്യം. ഒരു ഇൻഷുറൻസ് കമ്പനിയിലെ "policy_status" ഫീൽഡ് 5 വ്യത്യസ്ത ടീമുകൾ വ്യത്യസ്തമായി വ്യാഖ്യാനിച്ചതായി നിർണ്ണയിച്ചു, അതിനാൽ ഒരേ KPI റിപ്പോർട്ടുകളിൽ 3 വ്യത്യസ്ത ഫലങ്ങൾ നൽകി. AI-അധിഷ്ഠിത ഡാറ്റാ നിഘണ്ടു തയ്യാറാക്കുകയും ബിസിനസ് യൂണിറ്റുമായി ഏകീകൃത കരാർ നേടുകയും ചെയ്തുകൊണ്ട്, റിപ്പോർട്ടിലെ പൊരുത്തക്കേട് ഇല്ലാതാക്കുകയും പ്രതിമാസ അനുരഞ്ജന മീറ്റിംഗ് സമയം 60% കുറയ്ക്കുകയും ചെയ്തു.
ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്
ദുർബലമായ പ്രോംപ്റ്റ്:
ഒരു ഇ-കൊമേഴ്സ് ഡാറ്റാബേസ് രൂപകൽപ്പന ചെയ്യുക.
ശക്തമായ നിർദ്ദേശം:
നിങ്ങളുടെ റോൾ: നിങ്ങൾ പരിചയസമ്പന്നനായ ഒരു ഡാറ്റാ മോഡലറാണ്. ഇനിപ്പറയുന്ന ബിസിനസ്സ് നിയമങ്ങൾക്കനുസൃതമായി ഒരു ലോജിക്കൽ ഡാറ്റ മോഡൽ ഡ്രാഫ്റ്റ് ചെയ്യുക. നിയമങ്ങൾ:- ഓരോ എൻ്റിറ്റിക്കും: ഫീൽഡുകൾ, പ്രാഥമിക കീ, ആവശ്യമായ ഫീൽഡുകൾ.- ഓരോ ബന്ധത്തിനും: ടൈപ്പ് (ഒന്നിൽ നിന്ന് പലതും / പലതും പലതും) കൂടാതെ വിദേശ കീയും.- പലതോ പലതോ ആയ സാധാരണ ബന്ധങ്ങളിൽ ഇൻ്റർമീഡിയറ്റ് പട്ടിക നിർദ്ദേശിക്കുക;- നിങ്ങൾ മനഃപൂർവ്വം ഡീനോർമലൈസേഷൻ ശുപാർശ ചെയ്യുകയാണെങ്കിൽ, യുക്തി എഴുതുക.- നിങ്ങൾക്ക് ഉറപ്പില്ലാത്ത ഏതെങ്കിലും ബിസിനസ്സ് റൂൾ ലേബൽ ചെയ്യുക [സ്ഥിരീകരണം ആവശ്യമാണ്]. ബിസിനസ്സ് നിയമങ്ങൾ:- ഉപഭോക്താവിന് ഒന്നിലധികം ഓർഡറുകൾ നൽകാം.- ഒരു ഓർഡറിൽ ഒന്നിലധികം ഉൽപ്പന്നങ്ങൾ അടങ്ങിയിരിക്കുന്നു; ഒരു ഉൽപ്പന്നം നിരവധി ഓർഡറുകളിൽ സംഭവിക്കുന്നു.- ഉൽപ്പന്നങ്ങൾക്ക് വിഭാഗങ്ങളുണ്ട്.[മറ്റ് നിയമങ്ങൾ...]
ശക്തമായ പ്രോംപ്റ്റ് മോഡൽ ലെവൽ (ലോജിക്കൽ), കീ, റിലേഷൻഷിപ്പ് നിയമങ്ങൾ, നോർമലൈസേഷൻ ടാർഗെറ്റ്, സ്ഥിരീകരണം ആവശ്യമായ പോയിൻ്റുകൾ എന്നിവ വ്യക്തമാക്കുന്നു.
പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ
1) ഡാറ്റാ നിഘണ്ടു ഡ്രാഫ്റ്റ്:
പട്ടികയുടെ നിർവചനത്തിൽ നിന്ന് ഒരു ഡാറ്റ നിഘണ്ടു രൂപരേഖ പിന്തുടരുന്നു. ഓരോ ഫീൽഡിനും: പേര്, തരം, ഇത് നിർബന്ധമാണോ, സാധ്യമായ മൂല്യങ്ങൾ, ബിസിനസ് അർത്ഥം (ലേബൽ[പ്രവചനം] ഒരു പ്രവചനമാണെങ്കിൽ). പട്ടിക: [DDL അല്ലെങ്കിൽ ഫീൽഡ് ലിസ്റ്റ്]
2) നോർമലൈസേഷൻ അവലോകനം:
ചുവടെയുള്ള പട്ടിക ഘടനയിൽ തനിപ്പകർപ്പ് ഡാറ്റ, അപ്ഡേറ്റ് അപാകത, നോർമലൈസേഷനുള്ള അവസരങ്ങൾ എന്നിവയ്ക്ക് എന്തെങ്കിലും അപകടസാധ്യതയുണ്ടോ? ഓരോ കണ്ടെത്തലിനും, ഏത് സാധാരണ രൂപമാണ് അത് ലംഘിക്കുന്നതെന്നും നിങ്ങളുടെ നിർദ്ദേശവും എഴുതുക. ഘടന: [ടെക്സ്റ്റ്]
3) ബിസിനസ് റൂളിൽ നിന്നുള്ള ER ഡ്രാഫ്റ്റ്:
ഇനിപ്പറയുന്ന ബിസിനസ്സ് നിയമങ്ങൾ എൻ്റിറ്റികളിലേക്കും ആട്രിബ്യൂട്ടുകളിലേക്കും ബന്ധങ്ങളിലേക്കും വിവർത്തനം ചെയ്യുക. ഓരോ ബന്ധത്തിൻ്റെയും തരം വ്യക്തമാക്കുക (1-1, 1-N, N-N) കൂടാതെ N-N ആണെങ്കിൽ, ഒരു ഇൻ്റർമീഡിയറ്റ് പട്ടിക നിർദ്ദേശിക്കുക. അവ്യക്തമായ നിയമങ്ങൾ അടയാളപ്പെടുത്തുക. നിയമങ്ങൾ: [ടെക്സ്റ്റ്]
4) ബന്ധത്തിൻ്റെ തരം സ്ഥിരീകരണ ചോദ്യങ്ങൾ:
ചുവടെയുള്ള ഡാറ്റാ മോഡലിലെ ഓരോ ബന്ധത്തിനും, "അതെ/ഇല്ല" എന്ന ബിസിനസ്സ് ചോദ്യം സൃഷ്ടിക്കുക, അത് അതിൻ്റെ തരത്തിൻ്റെ കൃത്യത പരിശോധിക്കും (ഉദാ. "ഒരു വിദ്യാർത്ഥിയെ ഒരേ സമയം ഒന്നിലധികം ക്ലാസുകളിൽ ചേർക്കാമോ?"). മോഡൽ: [ടെക്സ്റ്റ്]
താരതമ്യ ചാർട്ട്: മോഡൽ ലെവലുകൾ
സവിശേഷത
ആശയപരമായ
ലോജിക്കൽ
ശാരീരികമായ
വിശദാംശങ്ങൾ
കുറഞ്ഞത്
ഇടത്തരം
ഏറ്റവും
താക്കോൽ/ബന്ധം
പ്രധാന ആസ്തികൾ
കീകൾ നിർവചിച്ചു
സൂചിക/തരം ഉൾപ്പെടെ
ഡാറ്റാബേസിനെ ആശ്രയിച്ചിരിക്കുന്നു
ഇല്ല
ഇല്ല
അതെ
ടാർഗെറ്റ് പ്രേക്ഷകർ
ബിസിനസ് യൂണിറ്റ്
അനലിസ്റ്റ്
ഡെവലപ്പർ/DBA
AI യുടെ സംഭാവന
ഡ്രാഫ്റ്റ്
ശക്തമായ ഡ്രാഫ്റ്റ്
ഡ്രാഫ്റ്റ്, DBA സ്ഥിരീകരണം
സാധാരണ തെറ്റുകൾ
- ഒന്നിൽ നിന്ന് പലതിലേക്ക് ഒരു പല ബന്ധത്തെക്കുറിച്ച് ചിന്തിക്കുന്നു. ഇതാണ് ഏറ്റവും സാധാരണമായ മോഡലിംഗ് പിശക്; ഇൻ്റർമീഡിയറ്റ് പട്ടിക മറന്നുപോയാൽ, സിസ്റ്റത്തിന് യഥാർത്ഥ അവസ്ഥ നിലനിർത്താൻ കഴിയില്ല.
- എല്ലാം ഒരു മേശയിലാക്കി. "ലാളിത്യം" നിമിത്തം എല്ലാ ഫീൽഡുകളും ഒരു പട്ടികയിൽ ശേഖരിക്കുന്നത് തനിപ്പകർപ്പും അപ്ഡേറ്റ് അപാകതകളും സൃഷ്ടിക്കുന്നു.
- ഒരു ഡാറ്റ നിഘണ്ടു എഴുതുന്നില്ല. ഫീൽഡുകളുടെ അർത്ഥം മനസ്സിൽ നിലനിൽക്കുമ്പോൾ ഒരേ കെപിഐ വ്യത്യസ്ത ഫലങ്ങൾ നൽകുന്നു.
- ഡാറ്റ തരങ്ങളെയും നിയന്ത്രണങ്ങളെയും കുറിച്ചുള്ള AI യുടെ ശുപാർശയെ അന്ധമായി വിശ്വസിക്കുന്നു. മോഡൽ ഒരു "വലിയ" ഏരിയ നിർദ്ദേശിച്ചേക്കാം; ബിസിനസ്സ് റൂൾ യഥാർത്ഥ പരിധികൾ നിർണ്ണയിക്കുന്നു (ഉദാ. TR ID 11 അക്കങ്ങൾ).
- സമ്പൂർണ്ണ നോർമലൈസേഷൻ. റിപ്പോർട്ടിംഗ് ലെയറിലെ അമിതമായ നോർമലൈസേഷൻ അന്വേഷണത്തെ മന്ദഗതിയിലാക്കുന്നു; സന്ദർഭത്തിനനുസരിച്ച് ഉദ്ദേശ്യം വ്യത്യാസപ്പെടുന്നു.
മുന്നറിയിപ്പ്: ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് മനോഹരമായി കാണപ്പെടുന്നതും എന്നാൽ ബിസിനസ്സ് നിയമങ്ങൾ ലംഘിക്കുന്നതുമായ മോഡലുകൾ നിർമ്മിച്ചേക്കാം. മോഡൽ നിർദ്ദേശിച്ച ഓരോ ബന്ധത്തിനും, "ഇത് ശരിക്കും ഇതുപോലെയാണോ?" ഒരു ബിസിനസ്സ് ചോദ്യം ചോദിക്കുക. സിസ്റ്റത്തിൻ്റെ അസ്ഥികൂടമാണ് ഡാറ്റ മോഡൽ; അസ്ഥികൂടത്തിലെ ഒടിവ് പിന്നീട് നന്നാക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്.
ചുരുക്കത്തിൽ
സ്ഥാപനങ്ങൾ, ആട്രിബ്യൂട്ടുകൾ, ബന്ധങ്ങൾ എന്നിവ ഉപയോഗിച്ച് ബിസിനസ്സ് വസ്തുതകൾ രൂപപ്പെടുത്തുന്ന പ്രക്രിയയാണ് ഡാറ്റ മോഡലിംഗ്. പ്രാഥമിക, വിദേശ കീകൾ റഫറൻഷ്യൽ സമഗ്രത ഉറപ്പാക്കുന്നു; നോർമലൈസേഷൻ ആവർത്തനത്തെ കുറയ്ക്കുന്നു, എന്നാൽ ഉദ്ദേശ്യത്തെ ആശ്രയിച്ച് ഡീനോർമലൈസേഷനും നിയമാനുസൃതമാണ്. ഡാറ്റാ നിഘണ്ടു ഓർഗനൈസേഷൻ്റെ പൊതുവായ ഭാഷയാണ്. ER ഡ്രാഫ്റ്റുകൾ, ഡാറ്റാ നിഘണ്ടുക്കൾ, നോർമലൈസേഷൻ അവലോകനങ്ങൾ എന്നിവ നിർമ്മിക്കുന്നതിൽ AI ഗണ്യമായ വേഗത നൽകുന്നു; എന്നിരുന്നാലും, റിലേഷൻഷിപ്പ് തരങ്ങൾ, ഡാറ്റ തരങ്ങൾ, ബിസിനസ് സെമാൻ്റിക്സ് എന്നിവ യഥാർത്ഥ ബിസിനസ്സ് നിയമത്തിന് എതിരായി സ്ഥിരീകരിക്കണം. മോഡൽ നല്ലതായി തോന്നുന്നത് കൊണ്ട് അത് ശരിയാണെന്ന് അർത്ഥമാക്കുന്നില്ല.
ആപ്ലിക്കേഷൻ ടാസ്ക്
ഒരു "ലൈബ്രറി ലോൺ സിസ്റ്റം" പരിഗണിക്കുക: അംഗങ്ങൾ, പുസ്തകങ്ങൾ, വായ്പാ രേഖകൾ. (1) ശക്തമായ പ്രോംപ്റ്റ് നിർമ്മിച്ച ഒരു ലോജിക്കൽ മോഡൽ ഡ്രാഫ്റ്റ് ഉണ്ടായിരിക്കുക. (2) മോഡൽ നിർദ്ദേശിക്കുന്ന ഓരോ ബന്ധത്തിൻ്റെയും തരം (പ്രത്യേകിച്ച്, "ഒരേ പുസ്തകത്തിൻ്റെ ഒന്നിലധികം പകർപ്പുകൾ ഒരു അംഗത്തിന് ഉണ്ടാകുമോ?") ഒരു ബിസിനസ്സ് ചോദ്യം ഉപയോഗിച്ച് പരിശോധിക്കുക. (3) കുറഞ്ഞത് ഒരു അനേകം-അനേകം ബന്ധം കണ്ടെത്തി ഒരു ഇൻ്റർമീഡിയറ്റ് പട്ടിക നിർവചിക്കുക. (4) കുറഞ്ഞത് 4 ഫീൽഡുകൾക്കായി ഡാറ്റ നിഘണ്ടു ലൈനുകൾ എഴുതുക (പേര്, തരം, നിർബന്ധിതം, ബിസിനസ്സ് അർത്ഥം). (5) മോഡൽ ഘടിപ്പിച്ചിരിക്കാവുന്ന ഒരു പരിമിതി എടുത്തുകാണിക്കുകയും നിങ്ങൾ അത് എങ്ങനെ സ്ഥിരീകരിക്കുമെന്ന് വിശദീകരിക്കുകയും ചെയ്യുക.
ചെക്ക്ലിസ്റ്റ്
- [] ഓരോ പട്ടികയുടെയും പ്രാഥമിക കീ നിർവചിച്ചിരിക്കുന്നു.
- [ ] ബിസിനസ് ചോദ്യവുമായി ഓരോ ബന്ധത്തിൻ്റെയും തരം ഞാൻ പരിശോധിച്ചു.
- [ ] പലതും പലതും തമ്മിലുള്ള ബന്ധങ്ങൾക്കായി ഞാൻ ഒരു ഇൻ്റർമീഡിയറ്റ് പട്ടിക നിർവചിച്ചു.
- [ ] ഡ്യൂപ്ലിക്കേറ്റ് ഡാറ്റയുടെ ഡീനോർമലൈസേഷൻ ഞാൻ നോർമലൈസ് ചെയ്യുകയോ ന്യായീകരിക്കുകയോ ചെയ്തു.
- നിർണ്ണായക ഫീൽഡുകൾക്കായി ഞാൻ ഒരു ഡാറ്റ നിഘണ്ടു ലൈൻ എഴുതി.
- [ ] AI-യുടെ ഡാറ്റ തരം/നിയന്ത്രണ നിർദ്ദേശങ്ങൾ ബിസിനസ്സ് നിയമത്തിന് എതിരായി ഞാൻ സ്ഥിരീകരിച്ചു.