SAP CAP-ൽ ഡൊമെയ്ൻ മോഡലിംഗ്

അവതാരിക

എന്റിറ്റി-റിലേഷൻഷിപ്പ് മോഡലുകളുടെ അടിസ്ഥാനത്തിൽ ഒരു പ്രശ്ന ഡൊമെയ്‌നിന്റെ സ്റ്റാറ്റിക്, ഡാറ്റയുമായി ബന്ധപ്പെട്ട വശങ്ങൾ വിവരിക്കുന്ന ഒരു മോഡലാണ് SAP CAP-ലെ ഒരു ഡൊമെയ്ൻ മോഡൽ. ഈ ലേഖനത്തിൽ ഞങ്ങൾ SAP CAP-ലെ ഡൊമെയ്ൻ മോഡലിംഗ് വിശദമായി പഠിക്കും.

ഡൊമെയ്ൻ മോഡലിംഗ്

ലളിതമായി പറഞ്ഞാൽ, കീകൾ, ഫീൽഡുകൾ, വ്യാഖ്യാനങ്ങൾ എന്നിവയുടെ അടിസ്ഥാനത്തിൽ ബിസിനസ്സ് പ്രശ്നം നിർവചിക്കുന്ന തരത്തിൽ SAP CAP-ലെ ഒരു CDS ഡൊമെയ്ൻ മോഡൽ നിർമ്മിക്കുന്നു. ഒരു ഡൊമെയ്ൻ മോഡൽ സൃഷ്ടിക്കുന്നതിനുള്ള കോഡ് ഒരു CDS സ്കീമയിൽ (db/schema.cds) എഴുതിയിരിക്കുന്നു. ഈ ഡൊമെയ്ൻ മോഡലുകൾ സേവന നിർവചനങ്ങൾ, പെർസിസ്റ്റൻസ് മോഡലുകൾ, ഡാറ്റാബേസുകൾ എന്നിവയിൽ ഉപയോഗിക്കാം അല്ലെങ്കിൽ മറ്റൊരു ഡൊമെയ്ൻ മോഡലിൽ വീണ്ടും ഉപയോഗിക്കാവുന്നതാണ്.

മാതൃകാ ഉദാഹരണം:

നെയിംസ്പേസ് empInfo; '@sap/cds/common' എന്നതിൽ നിന്ന് {കറൻസി, നിയന്ത്രിക്കുന്നത്} ഉപയോഗിക്കുന്നു; എന്റിറ്റി ജീവനക്കാർ: നിയന്ത്രിക്കുന്നത് {കീ ഐഡി: പൂർണ്ണസംഖ്യ; ആദ്യനാമം: പ്രാദേശികവൽക്കരിച്ച സ്ട്രിംഗ് (111); അവസാന നാമം: പ്രാദേശികവൽക്കരിച്ച സ്ട്രിംഗ് (1111); മാനേജർ: മാനേജർമാർക്കുള്ള അസോസിയേഷൻ; ചേരുന്ന തീയതി: പൂർണ്ണസംഖ്യ; ശമ്പളം: ദശാംശം (9,2); കറൻസി: കറൻസി; }

 

ഈ ഉദാഹരണത്തിൽ ഞങ്ങൾ ഒരു schema.cds ഫയൽ സൃഷ്ടിച്ചു, അവിടെ ഞങ്ങൾ ഒരു ജീവനക്കാരന്റെ അടിസ്ഥാന വിശദാംശങ്ങൾ ഉൾക്കൊള്ളുന്ന എംപ്ലോയീസ് എന്ന എന്റിറ്റി സൃഷ്ടിച്ചു.

ഈ മുഴുവൻ സ്കീമയ്ക്കും ഒരു നെയിംസ്പേസ് നൽകിയിട്ടുണ്ട്, അതായത് empInfo

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

ഒരു മോഡൽ സൃഷ്ടിക്കാൻ ഞങ്ങൾ CDS ഉപയോഗിക്കുന്നു. ആ CDS-ൽ ഞങ്ങൾ ഉപയോഗിക്കുന്നു

  1. അദ്വിതീയ വസ്‌തുക്കളുടെ ഒരു കൂട്ടത്തെ പ്രതിനിധീകരിക്കാനുള്ള എന്റിറ്റികൾ ഉദാ:
    1. ജീവനക്കാരുടെ അടിസ്ഥാന വിവരങ്ങൾ
    2. ജീവനക്കാരുടെ ആശയവിനിമയ വിവരങ്ങൾ
    3. ജീവനക്കാരുടെ ശമ്പള വിവരം
  2. ബന്ധങ്ങൾ നിർവചിക്കുന്നതിനുള്ള അസോസിയേഷനുകൾ
    1. എല്ലാ മാനേജർമാരുടെ ലിസ്റ്റും ഉള്ള മറ്റൊരു എന്റിറ്റി മാനേജറുമായി മാനേജർ അസോസിയേഷൻ

നാമകരണ കൺവെൻഷനും ശുപാർശകളും

  1. സ്ഥാപനത്തിന്റെ പേര് ഒരു വലിയ അക്ഷരത്തിൽ ആരംഭിക്കണം, അത് മനുഷ്യർക്ക് വായിക്കാവുന്നതും സ്വയം വിശദീകരിക്കാവുന്നതുമായിരിക്കണം - ഉദാഹരണത്തിന്, ജീവനക്കാർ
  2. ഒരു ചെറിയ അക്ഷരം ഉപയോഗിച്ച് ഘടകങ്ങൾ ആരംഭിക്കുക - ഉദാഹരണത്തിന്, ആദ്യനാമം
  3. എന്റിറ്റികളുടെ ബഹുവചനം ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു - ഉദാഹരണത്തിന്, ജീവനക്കാർ
  4. തരങ്ങളുടെ ഏകവചനരൂപം ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു - ഉദാഹരണത്തിന്, കറൻസി
  5. സന്ദർഭങ്ങൾ ആവർത്തിക്കരുത് - ഉദാഹരണത്തിന്, Employees.EmployeeName എന്നതിന് പകരം Employees.name
  6. ഒറ്റവാക്കിലുള്ള പേരുകൾ തിരഞ്ഞെടുക്കുക - ഉദാഹരണത്തിന്, ശമ്പളത്തിന് പകരം ശമ്പളം
  7. സാങ്കേതിക പ്രാഥമിക കീകൾക്കായി ഐഡി ഉപയോഗിക്കുക - ഉദാഹരണത്തിന്, എംപ്ലോയി ഐഡിക്കുള്ള ഐഡി
  8. നിങ്ങളുടെ എന്റിറ്റികളെ അദ്വിതീയമാക്കാൻ നിങ്ങൾക്ക് നെയിംസ്പേസ് ഉപയോഗിക്കാം. ഇത് SAP-ലെ ക്ലയന്റ് ആശയം പോലെയാണ്, അവിടെ നിങ്ങൾക്ക് ഡ്യൂപ്ലിക്കേറ്റ് സ്കീമകൾ (cds ഫയലുകൾ) വേർതിരിക്കുന്നതിന് തനതായ നെയിംസ്പേസ് ഉണ്ടായിരിക്കും. നെയിംസ്‌പെയ്‌സുകൾ ഓപ്‌ഷണലാണ്, നിങ്ങളുടെ മോഡലുകൾ മറ്റ് പ്രോജക്റ്റുകളിൽ വീണ്ടും ഉപയോഗിക്കപ്പെടുകയാണെങ്കിൽ നെയിംസ്‌പെയ്‌സ് ഉപയോഗിക്കുക. ദിവസാവസാനം അവ പ്രിഫിക്സുകൾ മാത്രമാണ്, അവ ഒരു ഫയലിലെ പ്രസക്തമായ എല്ലാ പേരുകളിലും സ്വയമേവ പ്രയോഗിക്കുന്നു. - ഉദാഹരണത്തിന്,

നെയിംസ്‌പേസ് ലാപ്‌ടോപ്പ്;എന്റിറ്റി ഡെൽ {}

..… ഇതിന് തുല്യമാണ്:

entity laptop.Dell {}

  1. നെസ്റ്റഡ് നെയിംസ്പേസ് വിഭാഗങ്ങൾക്കായി നിങ്ങൾക്ക് സന്ദർഭങ്ങൾ ഉപയോഗിക്കാം. - ഉദാഹരണത്തിന്,

നെയിംസ്‌പേസ് ലാപ്‌ടോപ്പ്;എന്റിറ്റി ഡെൽ {}           //> laptop.Dellസന്ദർഭം Apple {entity MacBookPro {}       //> laptop.Apple.MacBookPro     എന്റിറ്റി MacBookAir {} }

 

എന്റിറ്റികൾ

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

തരത്തിലുള്ളവ

SAP ABAP-ലെ ഡൊമെയ്‌ൻ പോലെയാണ് തരങ്ങൾ, ടൈപ്പ് ചെയ്‌ത ഡാറ്റ ഘടകങ്ങളെ നിർവചിക്കാൻ ഇത് ഉപയോഗിച്ചു.

വശങ്ങൾ

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

ഉദാഹരണത്തിന്-

  • cds- നിങ്ങളുടെ പ്രധാന ഡൊമെയ്‌ൻ മോഡൽ, വൃത്തിയുള്ളതും ലളിതവും മനസ്സിലാക്കാവുന്നതും സൂക്ഷിച്ചിരിക്കുന്നു
  • audit-model.cds- ഒരു ഫയലിൽ ഓഡിറ്റിങ്ങിന് ആവശ്യമായ അധിക ഫീൽഡുകൾ ചേർക്കുന്നു
  • auth-model.cds- അംഗീകാരത്തിനായി വ്യാഖ്യാനങ്ങൾ ചേർക്കുന്നു.

പ്രാഥമിക കീകൾ

SAP ABAP-ലെ പട്ടികകളും സിഡിഎസുകളും പോലെ, കീവേഡ് ഉപയോഗിച്ച് എന്റിറ്റിക്കായി ഞങ്ങൾ പ്രാഥമിക കീകൾ പരിപാലിക്കുന്നു കീ.

പൊതുവായ നിർവചനങ്ങളുടെ രീതിശാസ്ത്രം ഉപയോഗിച്ച് മോഡലിലുടനീളം ഒരു പ്രാഥമിക കീ വീണ്ടും ഉപയോഗിക്കാനാകും.

എല്ലാ പൊതുവായ നിർവചനങ്ങളും സംഭരിക്കാൻ കഴിയുന്ന ഒരു common.cds മോഡൽ നമുക്ക് സൃഷ്ടിക്കാൻ കഴിയും.

// പൊതുവായ നിർവചനങ്ങൾ

entity StandardEntity {കീ ഐഡി : UUID; } ഇപ്പോൾ ഈ പൊതുവായ നിർവചനങ്ങൾ താഴെപ്പറയുന്ന രീതിയിൽ വീണ്ടും ഉപയോഗിക്കാവുന്നതാണ്: './common'-ൽ നിന്ന് { StandardEntity } ഉപയോഗിക്കുന്നു; entity Employee : StandardEntity {name : String; ... } entity Manager : StandardEntity {name : String; ...}

 

പേരുള്ള ഒരു മുൻ‌നിർവ്വചിച്ച എന്റിറ്റി ഉപയോഗിച്ച് സ്ഥിരസ്ഥിതിയായി പൊതുവായ ഫയൽ ഇതിനകം സൃഷ്‌ടിച്ചതാണ് ക്യൂഡ്.

യുയുഐഡികൾ ഒഡാറ്റയിലേക്ക് മാപ്പുചെയ്യുന്നു

എല്ലാ OData മോഡലുകളിലും സ്ഥിരസ്ഥിതിയായി Edm.Guid-ലേക്ക് UUID-കൾ CDS മാപ്പ് ചെയ്യുന്നു. എന്നിരുന്നാലും, OData സ്റ്റാൻഡേർഡ് Edm.Guid മൂല്യങ്ങൾക്കായി നിയന്ത്രിത നിയമങ്ങൾ സ്ഥാപിക്കുന്നു - ഉദാഹരണത്തിന്, ഹൈഫനേറ്റഡ് സ്ട്രിംഗുകൾ മാത്രമേ അനുവദിക്കൂ - നിലവിലുള്ള ഡാറ്റയുമായി വൈരുദ്ധ്യമുണ്ടാകാം. അതിനാൽ, ഡിഫോൾട്ട് മാപ്പിംഗ് ഇനിപ്പറയുന്ന രീതിയിൽ അസാധുവാക്കാൻ ഞങ്ങൾ അനുവദിക്കുന്നു:

എന്റിറ്റി ബുക്കുകൾ {

കീ ഐഡി: UUID @ഒഡാറ്റ.തരം:'Edm.String';

പങ്ക് € |

}

ആവശ്യമെങ്കിൽ, അനുബന്ധ പ്രോപ്പർട്ടി അസാധുവാക്കാൻ @odata.MaxLength എന്ന വ്യാഖ്യാനവും ചേർക്കാവുന്നതാണ്.

അസോസിയേഷൻ

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

രചനകൾ

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

// അടങ്ങിയിരിക്കുന്ന ഓർഡർ ഇനങ്ങളുള്ള ഓർഡറുകൾ നിർവചിക്കുകഎന്റിറ്റി ഓർഡറുകൾ {കീ ഐഡി : UUID; ഇനങ്ങൾ : Items.parent=$self;}entity Order_Items-ലെ നിരവധി Order_Items-ന്റെ രചന // ഓർഡറുകളിലൂടെ മാത്രമേ ആക്സസ് ചെയ്യപ്പെടുകയുള്ളൂ  പ്രധാന രക്ഷകർത്താവ്: ഓർഡറുകൾക്ക് അസോസിയേഷൻ; കീ ബുക്ക് : അസോസിയേഷൻ ടു ബുക്സ്; അളവ് : പൂർണ്ണസംഖ്യ;}

മികച്ച സമ്പ്രദായങ്ങൾ

  1. മോഡലുകളിൽ സാങ്കേതിക വിശദാംശങ്ങൾ ചേർക്കരുത്, ഞങ്ങൾ ഉപയോഗിക്കുന്നു വശങ്ങൾഅതിനു വേണ്ടി
  2. ഉപയോഗം ചെറിയ പേരുകൾ ഒപ്പം ലളിതമായ ഫ്ലാറ്റ് മോഡലുകൾ
  3. മോഡലുകളിലെ എന്റിറ്റികളെ കൂടുതൽ നോർമലൈസ് ചെയ്യരുത്
  4. ഉയർന്ന ലോഡുകളും വോള്യങ്ങളും നിങ്ങൾ ശരിക്കും കൈകാര്യം ചെയ്യുകയാണെങ്കിൽ പ്രാദേശിക പൂർണ്ണസംഖ്യ ക്രമങ്ങൾ ഉപയോഗിക്കുക. അല്ലെങ്കിൽ, UUID-കൾ തിരഞ്ഞെടുക്കുക

ഇതുവരെ നമ്മൾ പഠിച്ചത്: മോഡലിന്റെ സൃഷ്ടിയും അതിന് മുകളിലുള്ള വശങ്ങളും.

SAP CAP-ൽ ഡൊമെയ്ൻ മോഡലിംഗ്

ഒരു അഭിപ്രായം ഇടൂ

സ്പാം കുറയ്ക്കുന്നതിന് ഈ സൈറ്റ് Akismet ഉപയോഗിക്കുന്നു. നിങ്ങളുടെ അഭിപ്രായ ഡാറ്റ പ്രോസസ്സുചെയ്യുന്നത് എങ്ങനെയെന്നറിയുക.